DEV Community: SparkFabrik

Drupal service container deep dive (Part 2): aliases, autowiring, and named arguments

Lusso Luca — Wed, 10 Dec 2025 09:00:00 +0000

In this second part of our deep dive into the Drupal service container, we explore the concepts of aliases, autowiring, and named arguments.

In the first part of this series, we explored the basics of the Drupal service container, including how services are defined and how dependencies are injected. We discussed concepts such as tags, compiler passes, service providers, and autoconfiguration. In this second part, we will delve deeper into more advanced concepts such as aliases, autowiring, and named arguments.

Aliases

An alias in the Drupal service container is a way to create an alternative name for an existing service. This is particularly useful when you want to refer to a service by a different name without changing the original service definition.

request_stack:
  class: Symfony\Component\HttpFoundation\RequestStack
  tags:
    - { name: persist }
Symfony\Component\HttpFoundation\RequestStack: '@request_stack'

In this example, we define a service request_stack and then create an alias Symfony\Component\HttpFoundation\RequestStack that points to the same service. This allows us to refer to the RequestStack service using either name interchangeably. This specific example works because a service name is just a string, and we can use anything that is a valid string as a service name, including class names.

A service name is just a string: config.factory, entity_type.manager, Symfony\Component\HttpFoundation\RequestStack, are all valid service names.

Starting from Drupal 10.1, most of the core services have been aliased with the Fully Qualified Class Name (FQCN) of the service class.

Change record: https://www.drupal.org/node/3323122

Of course, you can create your own aliases in your custom modules to improve code readability and maintainability:

webprofiler.profiler:
 class: Drupal\webprofiler\Profiler\Profiler
 arguments:
   [
     '@webprofiler.file_storage',
     '@logger.channel.webprofiler',
     '@config.factory',
   ]
Drupal\webprofiler\Profiler\Profiler': '@webprofiler.profiler'

When a service name is equal to the service class FQCN, the service container can automatically resolve and inject dependencies simply by matching the requested FQCN.

This feature is called autowiring.

Autowiring

Autowiring is a feature of the Drupal (and Symfony) service container that allows for automatic dependency injection based on type hints. When a service is defined with autowiring enabled, the container will automatically resolve and inject the required dependencies based on the type hints specified in the constructor or method signatures.

The service will be instantiated in exactly the same way as before, but there is no need to explicitly specify which arguments are required; the interfaces/classes that are declared in the service constructor will be used to discover which services should be injected.

Autowire can be enabled at service level, like this:

services:
  _defaults:
    autoconfigure: true

  webprofiler.profiler_listener:
    class: Drupal\webprofiler\EventListener\ProfilerListener
    autowire: true

or globally for all services, like this:

services:
  _defaults:
    autoconfigure: true
    autowire: true

  webprofiler.profiler_listener:
    class: Drupal\webprofiler\EventListener\ProfilerListener

In Symfony, when a single service exists for a given interface or class, the service container automatically creates an alias for it using the FQCN. This means that you can type-hint against the interface or class in your constructor, and the container will automatically inject the correct service. This is not the case in Drupal, where you need to explicitly create the alias as shown above.

Multiple services for the same interface

Usually, a Drupal module extends the logger.channel_base service to build a new logger with the module name, like in this example:

services:
  _defaults:
    autowire: true
    autoconfigure: true

  logger.channel.module_name:
    parent: logger.channel_base
    arguments: ['module_name']

  my_service:
    class: Drupal\module_name\MyService

Both logger.channel_base, logger.channel.module_name, and every logger defined by Core and modules are instances of the same interface: Psr\Log\LoggerInterface. As there are many services in the service container that implement Psr\Log\LoggerInterface, which specific implementation will be injected in a constructor like this?

use Psr\Log\LoggerInterface;

class MyService {

    public function __construct(
      private readonly LoggerInterface $logger,
    ) {
    }
}

In this case, the service container will throw an exception because it cannot determine which specific service to inject:

Some services cannot be autowired, usually because the interface is implemented by multiple different services (like loggers or cache bins in Drupal).
In this case, we must use the #[Autowire] attribute to clearly specify which service to inject, like this:

use Psr\Log\LoggerInterface;
use Symfony\Component\DependencyInjection\Attribute\Autowire;

class MyService {

    public function __construct(
      #[Autowire(service: 'logger.channel.module_name')]
      private readonly LoggerInterface $logger,
    ) {
    }
}

Autowiring in Controllers and Hooks

A controller is not a service and it's not loaded by the service container. When a route is matched, Drupal uses the controller loader service (controller_resolver) to create an instance of the controller class. The controller loader calls the create method on the controller class to instantiate it. The create method receives the entire service container and creates a new instance of the controller class with the required services. This is an implementation of the service locator anti-pattern, as shown in:

class DashboardController extends ControllerBase {

  final public function __construct(
    private readonly Profiler $profiler,
    private readonly TemplateManager $templateManager,
  ) {
  }

  public static function create(ContainerInterface $container): DashboardController {
    return new static(
      $container->get('webprofiler.profiler'),
      $container->get('webprofiler.template_manager'),
    );
  }
}

Starting from Drupal 10.2, ControllerBase (the base class for controllers in Drupal) uses the AutowireTrait, so if the controller constructor uses type hints and the #[Autowire] attribute where necessary, we can take advantage of autowiring in controllers as well.

AutowireTrait uses reflection to read the constructor parameters and their attributes, so it has a performance impact.

use Drupal\Core\DependencyInjection\AutowireTrait;

class DashboardController extends ControllerBase {

  use AutowireTrait;

  final public function __construct(
    private readonly Profiler $profiler,
    private readonly TemplateManager $templateManager,
  ) {
  }
}

As we can see in the previous example, the create method is no longer required. The AutowireTrait can be used for any classes that implement ContainerInjectionInterface (for some reason, FormBase does not use it yet, but you can easily add it to your custom forms).

With the upcoming Drupal 11.3, a similar feature will be available for plugins too: Add create() factory method with autowired parameters to PluginBase.

Starting from Drupal 11.1, hooks can be defined in classes (https://www.drupal.org/node/3442349). All hook classes are automatically registered as autowired services, so you can use autowiring in hook classes as well:

namespace Drupal\file\Hook;

class FileViewsHooks {

  public function __construct(
    protected readonly EntityTypeManagerInterface $entityTypeManager,
    protected readonly EntityFieldManagerInterface $entityFieldManager,
    protected readonly ?FieldViewsDataProvider $fieldViewsDataProvider,
  ) {}

  #[Hook('field_views_data')]
  public function fieldViewsData(FieldStorageConfigInterface $field_storage): array {
    $data = $this->fieldViewsDataProvider->defaultFieldImplementation($field_storage);
  }
}

Autowiring in Services vs Non-Services

It's important to note that while services benefit from autowiring when properly configured, there are cases where you might want to use autowiring but cannot modify the class constructor to fix the type hint or to add the #[Autowire] attribute. This is where named arguments come into play.

Named Arguments

Named arguments provide an alternative way to specify dependencies in the service definition file itself, without requiring changes to the PHP code. This is particularly useful when:

You're working with third-party classes that you cannot modify
You want to keep dependency configuration separate from the code
You need to inject a specific service when multiple implementations of the same interface exist (as an alternative to using the #[Autowire] attribute)

Named arguments allow us to specify which arguments to pass to a service when it is being instantiated, by name rather than by position. The syntax uses the parameter name (with a $ prefix) as the key in the arguments section.

For example, let's say we have a service class with a constructor like this:

namespace Symfony\Component\Messenger\Middleware;

class SendMessageMiddleware {

    public function __construct(
        SendersLocatorInterface $sendersLocator,
        EventDispatcherInterface $eventDispatcher = null,
    ) {
    }
}

Instead of passing arguments by position, we can use named arguments in the service definition:

messenger.middleware.send_message:
  class: Symfony\Component\Messenger\Middleware\SendMessageMiddleware
  arguments:
    $eventDispatcher: '@event_dispatcher'

In this example, we're explicitly specifying that the $eventDispatcher parameter should receive the @event_dispatcher service. This is much clearer than using positional arguments, especially when dealing with optional parameters or when you want to skip some arguments.

Named arguments are particularly powerful when combined with autowiring. The container will:

First try to autowire all type-hinted parameters based on their types
Then override specific parameters with any named arguments you've defined
Use default values for any remaining optional parameters

This means you can let autowiring handle most dependencies automatically while using named arguments only for the specific cases where you need explicit control, such as when multiple services implement the same interface:

services:
  _defaults:
    autowire: true
    autoconfigure: true

  my_custom_service:
    class: Drupal\my_module\MyCustomService
    arguments:
      $logger: '@logger.channel.my_module'

In this example, most dependencies of MyCustomService will be autowired, but we're explicitly specifying which logger to inject using a named argument, solving the ambiguity problem we discussed earlier.

Bringing It All Together

Now that we understand aliases, autowiring, and named arguments, let's see how they work together to simplify service definitions.

Traditional Service Definition

In older Drupal code, a service definition might look like this:

services:
  webprofiler.profiler_listener:
    class: Drupal\webprofiler\EventListener\ProfilerListener
    arguments:
      - '@webprofiler.profiler'
      - '@request_stack'
      - '@webprofiler.matcher.exclude_path'

This approach requires:

Explicitly listing every dependency
Maintaining the correct order of arguments
Updating the YAML file whenever constructor parameters change

Modern Service Definition with Aliases and Autowiring

With the concepts we've covered, we can dramatically simplify this:

services:
  _defaults:
    autoconfigure: true
    autowire: true

  Drupal\webprofiler\EventListener\ProfilerListener: ~

This works because:

Aliases: The service is registered using its FQCN, which serves as both the service name and alias
Autowiring: The container automatically resolves dependencies based on type hints in the constructor
Autoconfiguration: The service is automatically tagged if it implements certain interfaces

In Yaml, ~ symbol (tilde) is equivalent to an empty array or null, meaning no additional configuration is needed. In this case, the tilde can be omitted entirely, but in my opinion, it's clearer to explicitly show that no further configuration is necessary.

Conclusion

In this second part of our deep dive into the Drupal service container, we have explored three powerful concepts that work together to modernize dependency injection in Drupal:

Aliases enable us to reference services by their class names, making code more intuitive and refactoring safer
Autowiring eliminates boilerplate by automatically resolving dependencies based on type hints
Named arguments provide surgical precision when we need explicit control over specific dependencies

Together, these features reduce boilerplate code, improve maintainability, and make service definitions more readable. They represent a significant evolution in how Drupal developers work with the service container.

Stay tuned for the next parts of this series, where we will continue to explore more advanced features of the Drupal service container:

Part 1 covers service tags, compiler passes, service providers, and autoconfiguration, laying the groundwork for understanding how services are defined and managed within the container.
Part 3 will cover service collectors, which aggregate multiple services into a single service for streamlined access.
Part 4 will explore factories, which provide a mechanism for creating services with complex initialization logic.
Part 5 will discuss backend overrides, enabling developers to customize service implementations for specific environments or use cases.
Part 6 will examine advanced features of the Drupal service container, such as service decoration and lazy loading.

Drupal service container deep dive part 1: tags, compiler passes, service providers and autoconfiguration

Lusso Luca — Mon, 03 Nov 2025 09:00:00 +0000

In this first part of our deep dive into the Drupal service container, we explore the concepts of tags, compiler passes, service providers, and autoconfiguration.

The evolution of Drupal core has increasingly embraced modern PHP standards and robust object-oriented programming (OOP) principles, driven largely by its integration of Symfony components. Central to this modernization is the Service Container, which acts as the core registry responsible for service instantiation, dependency resolution, and lifecycle management.

A service is inherently a specialized, reusable, and stateless object designed to perform a single, well-defined task, such as ConfigFactory for configuration access or EntityTypeManager for entity access.

The philosophy underpinning service usage is the promotion of loose coupling and adherence to the Dependency Inversion Principle (DIP). A class using a service should request it from the container rather than manually instantiating it with the new keyword. This arrangement enables developers to swap implementations without altering consuming code.

In this series of articles, we will explore the Drupal service container in depth, focusing on its features, capabilities, and best practices for leveraging it effectively in Drupal module development.

Part 1 will cover service tags, compiler passes, service providers, and autoconfiguration, laying the groundwork for understanding how services are defined and managed within the container.
Part 2 will delve into aliases, autowiring, and name arguments, demonstrating how to resolve and inject dependencies based on type hints, reducing boilerplate code and enhancing maintainability.
Part 3 will cover service collectors, which aggregate multiple services into a single service for streamlined access.
Part 4 will explore factories, which provide a mechanism for creating services with complex initialization logic.
Part 5 will discuss backend overrides, enabling developers to customize service implementations for specific environments or use cases.
Part 6 will examine advanced features of the Drupal service container, such as service decoration and lazy loading.

Anatomy of a Drupal service

A Drupal service is defined within a module's MODULE.services.yml file:

# in modules/contrib/webprofiler/webprofiler.services.yml
services:
    webprofiler.matcher.exclude_path:
        class: Drupal\webprofiler\RequestMatcher\WebprofilerRequestMatcher
        arguments: ['@path.matcher', '@config.factory', 'exclude_paths']

# in core/core.services.yml
services:
    path.matcher:
        class: Drupal\Core\Path\PathMatcher
        arguments: ['@config.factory', '@current_route_match']
    config.factory:
        class: Drupal\Core\Config\ConfigFactory
    current_route_match:
        class: Drupal\Core\Routing\CurrentRouteMatch
        arguments: ['@request_stack']
    request_stack:
        class: Symfony\Component\HttpFoundation\RequestStack

When code asks for the webprofiler.matcher.exclude_path service, the Drupal service container first builds all the required services and finally builds an instance of the WebprofilerRequestMatcher class by injecting all the dependencies in the __construct method:

namespace Drupal\webprofiler\RequestMatcher;

use Drupal\Core\Config\ConfigFactoryInterface;
use Drupal\Core\Path\PathMatcherInterface;
use Symfony\Component\HttpFoundation\RequestMatcherInterface;

class WebprofilerRequestMatcher implements RequestMatcherInterface {

  public function __construct(
    private readonly PathMatcherInterface $pathMatcher,
    private readonly ConfigFactoryInterface $configFactory,
    private readonly string $configuration,
  ) {...}
}

The resolution graph looks like this:

So Drupal first builds the request_stack service, then the current_route_match service (which depends on request_stack), then the config.factory service, then the path.matcher service (which depends on both config.factory and current_route_match), and finally the webprofiler.matcher.exclude_path service (which depends on both path.matcher and config.factory).

Notice that the third argument of the webprofiler.matcher.exclude_path service is a string (exclude_paths). The service container supports injecting scalar values like strings, integers, and booleans as arguments to services:

@ prefix indicates a service reference.
% prefix indicates a parameter reference.
@? indicates an optional service reference.
No prefix indicates a literal value.

parameters:
  param1: 'some string'

services:
  some_service1:
    class: Some\Class\Name1

  some_service2:
    class: Some\Class\Name2
    arguments: ['@some_service1', '%param1%', 42, true, 'another string', '@?some_service3']

and the code for some_service2 would look like this:

namespace Some\Class;

class Name2 {
  public function __construct(
    private readonly Name1 $someService1,
    private readonly string $param1,
    private readonly int $param2,
    private readonly bool $param3,
    private readonly string $param4,
    private readonly ?Name3 $someService3 = null,
  ) {...}
}

Differences between Drupal and Symfony service containers

The Drupal service container is built on top of the Symfony service container, inheriting many of its features and capabilities. However the Drupal modular architecture and specific requirements have led to several changes. On the other hand, Drupal doesn't use the Symfony Config component for service configuration, instead relying on its own YAML-based service definition files.

At the end both YAML loading and service container dumping have been heavily customized in Drupal to fit its architecture and performance needs, resulting in a service container that is optimized for Drupal's unique use cases but not fully equivalent to the standard Symfony service container.

Those differences can lead to some confusion when reading Symfony documentation, as some features may not be available or behave differently in Drupal. This article series aims to clarify those differences and provide a comprehensive understanding of the Drupal service container.

Service Tags

Service tags are metadata annotations that can be applied to service definitions within the Drupal service container. They provide a way to categorize and group services based on their functionality or purpose.

services:
  webprofiler.database:
    class: Drupal\webprofiler\DataCollector\DatabaseDataCollector
    arguments: ['@database', '@config.factory']
    tags:
      - {
          name: data_collector,
          template: '@webprofiler/Collector/database.html.twig',
          id: 'database',
          label: 'Database',
          priority: 750,
        }

A tag has a mandatory name attribute and can have any number of additional attributes. In the example above, the webprofiler.database service is tagged with the data_collector tag, along with several additional attributes such as template, id, label, and priority.

Tags on their own don't actually alter the functionality of a service in any way. They are primarily used to identify services for special processing during the container compilation phase, often through the use of compiler passes.

Compiler Passes

Compiler passes are a mechanism that allows developers to modify the service container during its compilation phase. They provide a way to programmatically alter service definitions, add or remove services, and manipulate tags before the container is fully built and dumped to the cache

Compiler passes are particularly useful for implementing complex service registration logic, such as dynamically adding services based on configuration or other runtime conditions. They are executed in a specific order during the container compilation process, allowing for fine-grained control over the final service definitions.

namespace Drupal\webprofiler\Compiler;

use Symfony\Component\DependencyInjection\Compiler\CompilerPassInterface;
use Symfony\Component\DependencyInjection\ContainerBuilder;

final class ProfilerPass implements CompilerPassInterface {

  public function process(ContainerBuilder $c): void {

    foreach ($c->findTaggedServiceIds('data_collector', TRUE) as $id => $attributes) {
        ...
    }
  }
}

A shown in the example above, the ProfilerPass class implements the CompilerPassInterface and defines a process method that is called during the container compilation phase. Within this method, the findTaggedServiceIds function is used to retrieve all services tagged with data_collector, allowing for custom processing of those services. The process method can modify the service definitions as needed, such as adding additional arguments, changing class names, or even removing services from the container.

A compiler pass must be registered with the container in order to be executed during the compilation phase. This is typically done within a module's service provider class.

Service Providers

Service providers are classes that encapsulate the logic for dynamically registering or altering services within the Drupal service container. Service providers typically extend the ServiceProviderBase class and re-define the register or alter methods to add or modify service definitions.

namespace Drupal\webprofiler;

use Drupal\Core\DependencyInjection\ContainerBuilder;
use Drupal\Core\DependencyInjection\ServiceProviderBase;

class WebprofilerServiceProvider extends ServiceProviderBase {

  public function register(ContainerBuilder $container): void {
    [...]
  }

  public function alter(ContainerBuilder $container): void {
     [...]
  }
}

The name and the namespace of the service provider class must follow a specific convention: it should be named ModuleServiceProvider and be located in the root namespace of the module. For example, the service provider for the webprofiler module is named WebprofilerServiceProvider and is located in the Drupal\webprofiler namespace. If the module name contains underscores, they should be removed and the following letter capitalized (e.g., search_api becomes SearchApiServiceProvider). Core has its own service provider named CoreServiceProvider located in the Drupal\Core namespace.

The register method can be used to add compiler passes to the container:

namespace Drupal\webprofiler;

use Drupal\Core\DependencyInjection\ContainerBuilder;
use Drupal\Core\DependencyInjection\ServiceProviderBase;

class WebprofilerServiceProvider extends ServiceProviderBase {

  public function register(ContainerBuilder $container): void {
    $container->addCompilerPass(new ProfilerPass());
  }
}

If the order of execution of compiler passes matters, you can specify the pass type and priority when adding the compiler pass:

$container->addCompilerPass(
  pass: new ProfilerPass(),
  type: PassConfig::TYPE_BEFORE_OPTIMIZATION,
  priority: 10
);

Values for type can be:

PassConfig::TYPE_BEFORE_OPTIMIZATION
PassConfig::TYPE_OPTIMIZE
PassConfig::TYPE_BEFORE_REMOVING
PassConfig::TYPE_REMOVE
PassConfig::TYPE_AFTER_REMOVING

This diagram that illustrates when compiler passes are executed during the Symfony service container compilation process:

TYPE_BEFORE_OPTIMIZATION (Blue): Where most custom compiler passes (like ProfilerPass) are typically registered. This is where services are analyzed and tagged services are processed.

TYPE_OPTIMIZE (Purple): Internal Symfony optimization passes that inline services and optimize the container structure.

TYPE_BEFORE_REMOVING (Orange): Validation passes that check for circular references and definition validity before cleanup.

TYPE_REMOVE (Red): Cleanup passes that remove unused services and private aliases.

TYPE_AFTER_REMOVING (Green): Final optimization passes after cleanup is complete.

Within each phase, compiler passes are executed in priority order (highest to lowest), allowing for fine-grained control over the execution sequence when multiple passes are registered in the same phase.

Autoconfiguration

Autoconfiguration is a powerful feature of the Drupal service container that allows services to be automatically tagged based on their class definitions.

When a service is defined in the container, the autoconfiguration process analyzes the class and applies the appropriate tags. For example, if a service implements a specific interface or extends a particular base class, the container can automatically apply the relevant tags to the service definition.

namespace Drupal\Core;

class CoreServiceProvider
    implements ServiceProviderInterface, ServiceModifierInterface {

    public function register(ContainerBuilder $container) {
        [...]
        $container
          ->registerForAutoconfiguration(EventSubscriberInterface::class)
          ->addTag('event_subscriber');
    }

    public function alter(ContainerBuilder $container): void {
        [...]
    }
}

In the example above, the CoreServiceProvider class registers an autoconfiguration rule that automatically tags any service implementing the EventSubscriberInterface with the event_subscriber tag. This means that when a service is defined that implements this interface, it will automatically receive the event_subscriber tag without needing to explicitly define it in the service definition.

Autoconfiguration is particularly useful for module developers, as it streamlines the process of registering services and ensures that they are properly configured without requiring extensive boilerplate code.

Since Drupal 10.2.0, several interfaces have been registered for autoconfiguration in CoreServiceProvider. At the time of writing (Drupal 11.3.0), those interfaces, and their corresponding tags, are:

MediaLibraryOpenerInterface (tag: media_library.opener)
EventSubscriberInterface (tag: event_subscriber)
LoggerAwareInterface (tag: logger_aware)
PreWarmableInterface (tag: cache_prewarmable)
ModuleUninstallValidatorInterface (tag: module_install.uninstall_validator)

Of course, custom autoconfiguration rules can be added in any module's service provider class, allowing for tailored service tagging based on specific module requirements:

namespace Drupal\sm;

final class SmServiceProvider implements ServiceProviderInterface {

  public function register(ContainerBuilder $container): void {
    $container->registerForAutoconfiguration(TransportFactoryInterface::class)
      ->addTag('messenger.transport_factory');
    $container->registerForAutoconfiguration(ServiceLocator::class)
      ->addTag('container.service_locator');
    }
}

Unfortunately, autoconfiguration only works for tags that doesn't have attributes.

With all those concepts in place, we can remove some boilerplate from our service definition by going from a service definition like this:

webprofiler.profiler_listener:
  class: Drupal\webprofiler\EventListener\ProfilerListener
  arguments:
    - '@webprofiler.profiler'
    - '@request_stack'
    - '@webprofiler.matcher.exclude_path'
  tags:
    - { name: event_subscriber }

to this:

webprofiler.profiler_listener:
  class: Drupal\webprofiler\EventListener\ProfilerListener
  arguments:
    - '@webprofiler.profiler'
    - '@request_stack'
    - '@webprofiler.matcher.exclude_path'

assuming that the ProfilerListener class implements the EventSubscriberInterface, which is already registered for autoconfiguration in CoreServiceProvider.

In the next part of this series, we will explore aliases, autowiring, and named arguments, demonstrating how to resolve and inject dependencies based on type hints, reducing boilerplate code, enhancing maintainability, and going even further in simplifying service definitions by removing the arguments section entirely:

webprofiler.profiler_listener:
  class: Drupal\webprofiler\EventListener\ProfilerListener

Stay tuned!

Codemotion Milan 2025

Daniela Bonvini — Wed, 22 Oct 2025 09:00:00 +0000

Highlights and reflections from Codemotion Milan 2025, covering key talks on testing strategies, modern CSS, Chrome DevTools, and AI prompt strategies.

Codemotion Milan 2025: Highlights and Reflections

Last week I had the chance to attend Codemotion Milan 2025, and honestly, it was a blast. Picture hundreds of developers, designers, and tech enthusiasts buzzing around packed rooms, debating over coffee, and getting genuinely excited about new ideas. It felt like the perfect mix of community, curiosity, and caffeine.

The schedule was stacked with everything from frontend magic to backend mysteries, and testing strategies to AI, DevOps, and software architecture. After two days of sessions, demos, and hallway chats, a few talks really stuck with me; for their substance, their delivery, and the sparks they set off in my brain.

Your Testing Strategy is Broken: Let’s Fix It! by Luise Freese

Luise Freese is an amazing speaker, funny but insightful (and it doesn't hurt that she likes pink and unicorns). I had the pleasure of seeing her speak last year, so I was really looking forward to her session this time around.
In this talk she took a refreshing look at what’s wrong with how we usually approach testing. Her point was simple but powerful: stop testing everything just for the sake of it. Aiming for 100% coverage sounds good on paper, but often just creates a mountain of useless unit tests that never actually catch the things that break in production.

Luise argued for a smarter, leaner approach — fewer tests, but better ones. Focus on how your system behaves under pressure, on integration points, on what your users will actually notice when things go wrong. As she put it, users don’t care how many tests you’ve written; they care that the software works.

It was one of those talks that make you rethink your day to day habits. I left the room thinking less about coverage reports and more about value.

Baseline Rhapsody: A Tale of Style & Motion by Emiliano Pisu

Emiliano Pisu’s talk was basically a love letter to modern CSS, and heaven knows if we need more CSS love in the developer community. He took us on a journey from the wild days of floats and tables to the sleek, expressive world of container queries, scroll-driven animations, and CSS custom properties. His main message: we’re living in a golden age of frontend styling, and we should start acting like it.

He introduced the new Baseline standard, a sort of “truth table” for web features that tells you what’s safe to use across browsers right now. No more endless guessing games or praying to the compatibility gods.

What I loved most was Emiliano’s mix of technical depth and creative energy. He made CSS feel exciting again, and honestly, I walked out wanting to rebuild half our design system just to play with the new toys.

ChromeDevTools: Are You Confident in Your Expertise? by Luca Del Puppo

This talk was like discovering hidden cheat codes in a game you’ve been playing for years. Luca Del Puppo took something every JavaScript dev uses daily, Chrome DevTools, and showed us just how much more it can do when you dig deep.

He demoed advanced debugging tricks, performance profiling, and how to uncover sneaky issues like layout thrashing and memory leaks. It wasn’t just a feature tour, it was a hands on masterclass in how to actually think with your tools.

What made it memorable was Luca’s energy and real-world examples. You could tell he’s spent countless hours battling tough bugs, and he made us feel like we could take on anything with DevTools as our sidekick. I walked away with a bunch of new debugging tricks and a renewed appreciation for a tool I thought I’d already mastered.

Prompt Strategies: Useful for AI (and Maybe for Everyday Life) by Francesco Sciuti

Right before my train home, I managed to squeeze in part of Francesco Sciuti’s workshop “Prompt Strategies: utile per l'AI e (forse) anche per l'uso quotidiano”, which roughly translates to “Prompt Strategies: useful for AI (and maybe also for everyday life).”

It was less of a formal talk and more of a round table conversation. Francesco walked us through how to write prompts that actually make AI behave, how to get the answers you want, in the format you need, without the weird hallucinations or vague replies we’ve all seen. He shared practical examples, frameworks for structuring prompts clearly, and even a few thoughts on Context Engineering. Basically, how to give an AI the right background to think straight.

Sadly, I had to leave halfway through to catch my train, but what I saw was genuinely enlightening. It wasn’t just about AI — it was about communication, precision, and how phrasing things clearly can make all the difference, whether you’re prompting a model or just talking to your team. Best new term of the year coined by Francesco: Vibe Prototyping, instead of the old Vibe Coding, which better represents how we can approach AI interactions in a more purposeful and cooperative way.

What Made These Talks Stand Out

Looking back, the sessions that I liked more had a few things in common. They were practical, grounded, and a little opinionated, the kind of talks that give you ideas to try the next morning, not just slides to bookmark and forget that are more like someone reading the documentation to you instead of explaining a new concept with their own voice and thoughts. They also had a strong personal touch — you could tell the speakers were passionate about their topics, and that enthusiasm was contagious.

Codemotion Milan 2025 nailed that vibe. It wasn’t about chasing buzzwords or hyping the latest framework. It was about building better software, with intention and creativity.

Overall, the event was a brilliant reminder that learning in tech doesn’t have to be dry or intimidating. It can be lively, surprising, and even a little fun. The mix of talks, workshops, and casual conversations made it clear that the heart of any tech community is curiosity, collaboration, and a willingness to experiment. And Codemotion Milan 2025 had all of that and even more.

The Lord Of The Stores: A Quest For Angular State Mastery

Daniela Bonvini — Thu, 04 Sep 2025 09:00:00 +0000

In the complex world of NgRx state management three powerful stores can guide us: Global Store, vast and unifying; Component Store, swift and precise; Signal Store, reactive and efficient. But wielding them unwisely leads to an unmanageable state. Join this journey through NgRx best practices, avoiding pitfalls, and mastering scalability. Will your app stand strong or fall into disorder? The fate of state management rests in your hands!

The framework has changed. I feel it in the code. I feel it in the builds. I smell it in the tech forums.

It began with the forging of the Great Stores. Three were given to Angular developers—structured, scalable, and reactive above all else.
The Global Store, vast and powerful. The Component Store, lightweight and precise. And the Signal Store, fresh and efficient.

For within these stores was bound the power to manage state, to bring order to applications. Each with its own strengths, each suited for different needs.
Because the world of state management is treacherous, and without guidance, chaos can still arise. For the time will soon come when NgRx will shape the fortunes of all devs.

Obligatory disclaimer: as you may have noticed after this slightly weird intro, in this article I will reference Lord Of The Rings lore, but if you’re not a fan of the movies or books don’t worry, of course it’s not needed to understand the explained concepts. (Although, I strongly suggest you to watch/read it, as it is an amazing saga).

An Unexpected Journey

The idea for this article came to me after I discussed with my team the option to start using a state management library for our application. At the time we used services that mimicked store slices and we wanted to switch them into full-fledged NgRx stores.

Until that moment I had only used the Global Store, heard of the Signal Store and didn’t even know the Component Store existed, until I read the NgRx official documentation (see, someone does RTFM sometimes).

As we didn’t have any specific requests on what to use, we were open to any one of them.

We took some time researching, and I found out that, as far as I know, there are no articles or videos directly comparing the differences between these stores, their use cases, and their pros and cons.

Fast forward a couple of months later and a lot of material revised, and here we are: I hope my findings will help someone in a similar position to mine figure out a little bit easier which store to choose for their own case.

The Global Store – Vilya, The Ring of Air

Let’s start with the Global Store, the most powerful option, associated with Vilya, the ring given to Elrond, symbolizing wisdom and governance.

Likewise, the Global Store manages large state in applications, providing structure and predictability. It is ideal for apps with complex state that multiple components must access and update.

However, this power comes with complexity: it requires a solid understanding of reducers, actions, effects, and RxJS, which adds to the learning curve. It demands boilerplate code and many interconnected parts, which can be overwhelming, especially for smaller apps or simpler state needs.

But this union of actions and effects is the Global Store’s strength, enabling features like time-travel debugging with native Redux DevTools integration. Developers can step backward and forward in the application’s state history, making changes easier to trace and debug.

Having matured over many years, the Global Store also offers an opinionated and structured way of managing state, helping teams organize logic across files and maintain consistency.

Global Store – Pros and Cons

Pros	Cons
Best for large-scale apps with complex state shared across multiple components	High complexity (reducers, actions, effects, selectors) + RxJS
Easier debugging using time-travel with Redux DevTools	Steep learning curve
Mature: opinionated and structured way of managing state	Lots of boilerplate code to interconnect everything
	Too much overhead for smaller applications

Example of use cases: large apps with complex, shared business logic (multi-step forms, shopping carts shared across multiple features) or global data like feature flags, notifications, or permissions.

Nenya – The Ring of Water, The Component Store

Then comes the Component Store, the underdog of the state management world, yet full of potential. I associate it with Nenya, Galadriel’s ring, symbolizing preservation and stability.

The Component Store works seamlessly with the Global Store without conflict, allowing effective state management with minimal changes to your codebase. You can see it like a service managing state with Subjects, but with added clarity and best practices.

It’s a lightweight solution ideal for managing local component or feature module state, promoting modularity and isolation. It supports multiple independent instances of the same component, maintaining clean separation of concerns.

Its API is simpler than that of the Global Store, as it doesn't require actions or reducers, making it easier to learn. However, it lacks developer tool support like time-travel debugging since it doesn't utilize trackable actions.

Trade-offs include scalability challenges: state, updaters, selectors, and effects typically reside in the same file, which can become difficult to manage as logic increases. Also, since state is tied to the component lifecycle, it is removed when the component is destroyed, making it inappropriate for persistent or shared state across components.

In summary, the Component Store offers store-like benefits without the Global Store's complexity.

Now, I must make a small confession: lately the NgRx team has put on the component store page a note saying that they consider the signal store the new default for local state management.

But, I nevertheless wanted to talk about component store as a lot of people may be stuck on older versions of Angular and may not be able to easily upgrade to signals and signal store usage.

As we can see from npm, still hundreds of thousands of people download Angular to versions less than 17 (signal store was released with NgRx version 17). But these same people may still be in need of a smaller store for their state management.

Component Store – Pros and Cons

Pros	Cons
Lightweight solution for local component state	Low scalability as everything is in the same file
Multiple independent instances of the same component allowing separation of concerns	No permanent state, as it is reset on component destruction
Simple syntax and state management (no actions or reducers)	No Redux DevTools time-travel debugging

Example of use cases: managing a form’s input values, validation, and submission state, or controlling the visibility and behavior of a modal within a component.

Narya – The Ring of Fire, The Signal Store

And lastly, the Signal Store, represented by Narya, Gandalf’s ring of courage and action.

It reflects the NgRx team’s bold shift toward simplicity and performance. Built on Angular signals, it provides reactive and efficient state management, removing unnecessary recalculations with a straightforward syntax that you can use right away.

In this store, state properties are signals, allowing components to access them directly without selectors or boilerplate code. Its lightweight design and optional RxJS support make it ideal for modern Angular apps that want to reduce complexity and bundle size.

However, it is still new, so official guidelines are limited. Features like selector composition, route guard integration, and DevTools support are still being developed. The Signal Store also forces you to use signals or convert Observables into signals. This makes it best suited for small to medium-scale features or isolated domains, while large-scale applications may still prefer the Global Store.

One downside is that the Signal Store does not support Redux DevTools yet. This means you lose features like time-travel debugging and state inspection.

There is an unofficial alternative, the Angular Architects NgRx Toolkit browser extension, which offers partial support but does not fully match the Redux DevTools experience.

Signal Store – Pros and Cons

Pros	Cons
State properties as signals (no selectors)	Still new, with limited official guidelines and documentation
Plug and play (simple syntax and small bundle size)	Advanced features are still evolving
Optional RxJS use	Obligatory use of signals
Good for reactive programming	Best suited for small to medium-scale apps; not yet ideal for large-scale or enterprise apps
Extreme composability (you choose which features to use)	No out-of-the-box Redux DevTools

Example of use cases: managing UI-related states like toggles, modals, filters, and tabs where reactive updates are needed but complexity is low.

Choosing the Right Ring and Power

We now have a better understanding of what each store can give us. But we still need to make a choice to understand which one is the right power for us.

Like the Elves wielding their rings wisely, developers must choose the right store for the right situation, as we know that the wrong power in the wrong hands can lead to disastrous consequences.

We must avoid at all costs the temptation of using too much or too little power just because we like one of the stores. Using a Global Store when local state would be better overcomplicates a simple problem. Conversely, sometimes a simple service+subjects/signals is all you need instead of any store at all.

The choice between NgRx stores depends primarily on your project's complexity, team size, and growth expectations. The Global Store excels at enterprise-level applications. The Signal Store offers a simpler alternative for smaller projects. The Component Store provides a balanced approach suitable for medium-sized applications or feature modules.

Consider starting with the simplest solution that meets your needs and scaling up as your application grows.

One Store to Bind All State

But what if you want more power, more control, and you cannot choose between the three rings? Well, you also have the choice to combine them to balance their respective flaws and strengths.

For example, you can use the Global Store for managing global state across the application, employ the Component Store for encapsulating state within specific features, and integrate the Signal Store where reactive and functional updates are most beneficial.

These stores were deliberately made to work well together. The complexity lies not in the implementation but in ensuring your team agrees on conventions and enforces them during reviews. Otherwise, wrongful mixes could lead to painful refactors.

Having said that, I made a little task management dashboard on Stackblitz,
to have a visual reference on how the code works.

This is just a simple app to show how you can intertwine all of the aforementioned stores. Of course using all three is a bit too much, especially for this kind of small project, but this is obviously just an example to show how they can easily work together if the need arises. Usually I would suggest using only two of them together: one for managing global properties and one for managing component properties.
This dashboard has:

A global quest assigner (managed by the Global Store)
A status card specifically for each member (managed by the Component Store)
A reactive search input (managed by the Signal Store)

The Fifth Age: The Age of NgRx State Management

With the information we acquired we now know that these three stores bring order to the Middle Earth of state management, but only if used wisely. No one store rules them all — each has its own purpose.

Additionally, we now know that you can combine what they can do, to be even more powerful. But it is up to you to avoid the temptation of abusing their power.

Now go into the world and use your power wisely, as the fate of Angular state management now rests in your hands.

Public speaking is like eating chillies

Daniela Bonvini — Mon, 01 Jul 2024 09:00:00 +0000

Introduction

This past year, after some soul searching and a lot of nudging from some of the people around me, I finally took the big step and started giving public talks at tech conferences. I started small, first at a local meetup group, then in front of my coworkers via video call, and finally in person in front of real people.

In my clearly clickbait title, I compared this experience to eating chili peppers, which is one of the things I both love and fear most when I accidentally drop way too many chili flakes into a dish I just cooked.
Why a culinary example? Well, for one thing, I like to cook, and for another, I'm Italian, so I guess it's written somewhere in our constitution that it's my civic duty to speak in food metaphors.

I think it's an apt comparison: that first moment when you take that first bite of food, knowing full well that you've put way too much seasoning on it, but you eat it anyway. And after the initial pain of too much spice, you realize that all in all, the dish now has more flavor and more oomph. But more than that, you're secretly proud of yourself for overcoming the fear of the initial discomfort.
Then there is the second time, when you do it again with another dish, where you have once again miscalculated the ingredients. Which is somehow made worse because you already know the initial pain, but at the same time you know the amazing amount of flavor and spiciness that would follow.

Well, this applies perfectly to public speaking, at least for me.

The first bite

At my first local meetup talk, I was so scared that I almost ran away, pretending to be sick. But then I persevered and delivered the talk I had prepared, and in the end I felt proud, both because it went well, but mostly because I did it by pushing through the fear of failure.
Then came another occasion of public speaking and, as in my culinary example from earlier, I was, if possible, even more frightened than before. But I persevered, and once again, overcoming the stage fright, came the satisfaction, both in myself and in what I had done.

I won't sugarcoat it, that initial "pain" never goes away. The majority of public speakers I have talked to say that they always get nervous, regardless of their years of experience. But they go through with it, knowing that the final morsel will be totally worth the initial suffering.

There must be a reason why it is a popular trope that in order to grow you have to get out of your comfort zone.

And believe me, I know it's easier said than done; I'm extremely socially awkward, to the point where I'm afraid to even make phone calls to people or places I don't know, but trying to get over that initial discomfort with public speaking has really helped me get a little more comfortable around new people. I'm still not a party animal, but I'm starting to understand that the more you project a feeling of being relaxed to the outside world, the more your mind is tricked into thinking you're really relaxed.

Lately I have been feeling a little bolder in my everyday life and people around me have been telling me that it shows that I feel more confident and that I am speaking a lot more without being prompted. Another speaker at a conference even said that I was an extrovert and seemed perfectly at ease on stage. Me. Can you believe that?
I spent most of my teenage years being told I needed to talk more, smile more, get out more, so it feels incredible to be told the opposite.

In addition to the increased self-esteem, being a speaker at these kinds of events is a great way to meet other incredibly talented people who you'll most likely see at other conferences later on, thus reducing the subsequent anxiety of not knowing anyone. It's also incredibly good for networking: I've had the opportunity to talk face-to-face with people I would never have had the chance to talk to otherwise, and to ask for advice on various topics, and I've always been treated with the utmost kindness.

The aftertaste

What saddens me is that I see the most fear of speaking at these conferences coming from junior developers, especially female ones. They are convinced that they are not good enough to be at these events because most of the speakers are already well-known or super skilled.

What they never think about is that precisely because they are a part of the tech world that is rarely represented at conferences, the reason to be that person is to become an inspiration to others in a similar position. So those other people can think, "hey, look at that, it's not impossible, I could do that too".

In my personal experience, I would never have started on this path if I hadn't been part of a company that encourages participation in these events, and if I hadn't had some friends and colleagues who have achieved great things just through sheer dedication, doing things that I didn't think were possible for "normal" people (aka not senior developers or not already famous). Or even just for having people with the confidence in me that I lacked at that moment, but needed to embark on this adventure.

I hope that these words will give some of you reading the same kind of support that I have received.
That if you are teetering on the edge of trying, but not finding the courage to send out a call for papers, that my words may inspire you to take the first step on the other side of public speaking.

Conclusion

With my silly cooking example, I want to send a message to all the people who are curious about public speaking but don't think they are extroverted enough, good enough, knowledgeable enough, whatever enough to deserve to do it, to at least try it once. And if after the initial discomfort you can feel the rewarding spiciness that comes afterward, then trust me, you are hooked for life.

And if not, that's okay too, at least you tried, and now you'll certainly have a better understanding of yourself, and you can still be proud that you at least tried, and peacefully know that it wasn't for you, without any regrets.

So go on, take that first spicy bite and get out of your comfort zone.

Drupal Access Policy demystified

Lusso Luca — Mon, 24 Jun 2024 10:35:53 +0000

Access Policy in Core

Drupal 10.3 introduces a new way to assign permissions to users, going beyond the traditional roles and permissions system. This new system is called the Access Policy API, and in this blog post, we'll try to explain how it works and how to use it.

The old way

Until Drupal 10.2, the access control system was based on two main concepts: you were either in a role that granted you a set of permissions or the user with UID 1, and the access checks were bypassed.

For example, you can have this code somewhere:

public function access(AccountInterface $account) {
   return $account->hasPermission('access content');
}

The code for hasPermission simply checks for the two cases mentioned above: if the user is the one with UID 1 or if the user is in a role that grants that permission:

public function hasPermission(string $permission, AccountInterface $account): bool {
   // User #1 has all privileges.
   if ((int) $account->id() === 1) {
      return TRUE;
   }

   return $this->entityTypeManager
      ->getStorage('user_role')
      ->isPermissionInRoles($permission, $account->getRoles());
}

This implementation was quite simple and worked well when a user has a set of permissions that are valid sitewide and that don't change based on some external factors.

If you need to implement use cases like:

deny edit permissions on weekends
allow edit permissions only if the user has 2FA enabled
allow edit permissions only to contents in a group (or in a domain, or in a Commerce store, etc.)

You're probably going to need a lot of custom code (otherwise it's impossible to implement them).

The new way

Drupal 10.3 introduced a new Access Policy API that allows the definition of a set of policies that can be applied based on a context.

If you want to know something about the genesis of this new system, you can read this blog post: Policy-Based Access in Core by Kristiaan Van den Eynde.

The API is quite simple; you define a policy class that extends the \Drupal\Core\Session\AccessPolicyBase and provide, at least, the implementation for the methods:

calculatePermissions(AccountInterface $account, string $scope): RefinableCalculatedPermissionsInterface: Calculates the permissions for an account within a given scope
getPersistentCacheContexts(): array: Gets the initial cache context this policy varies by

A policy is then registered in the service container with the tag access_policy.

Drupal 10.3 mimics the old behavior by providing two default policies:

\Drupal\Core\Session\Access\UserRolesAccessPolicy: Grants permissions based on a user's roles
\Drupal\Core\Session\Access\SuperUserAccessPolicy: Bypass permissions checks for the user with UID equal to 1

The \Drupal\Core\Session\Access\UserRolesAccessPolicy, for example, is implemented as follows:

final class UserRolesAccessPolicy extends AccessPolicyBase {

   public function __construct(protected EntityTypeManagerInterface $entityTypeManager) {}

   public function calculatePermissions(AccountInterface $account, string $scope): RefinableCalculatedPermissionsInterface {
      $calculated_permissions = parent::calculatePermissions($account, $scope);
      $user_roles = $this->entityTypeManager->getStorage('user_role')->loadMultiple($account->getRoles());

      foreach ($user_roles as $user_role) {
         $calculated_permissions
            ->addItem(new CalculatedPermissionsItem($user_role->getPermissions(), $user_role->isAdmin()))
            ->addCacheableDependency($user_role);
      }

      return $calculated_permissions;
   }

   public function getPersistentCacheContexts(): array {
      return ['user.roles'];
   }
}

The previous code retrieves the user's roles and adds a CalculatedPermissionsItem with the permissions granted by each role. Then, it adds a cacheable dependency on the role entity so that if the role's permissions change, the cache is invalidated. Finally, the method getPersistentCacheContexts returns the initial cache context that the policy varies by.

We will discuss the meaning of (Refinable)CalculatedPermissions, scope, and initial cache context shortly.

The critical thing to understand here is that this new system does not aim to grant access to something, like editing a node or viewing a page. It's designed to calculate a user's permissions in a given context. The access check is still done in the old way, which checks if the user has specific permission to perform a task.

An access policy converts a context into a set of permissions

Access policies are services, allowing us to replace or decorate the implementation provided by Core. Indeed, the Core itself allows for the policy for the super user to be disabled to increase site security (https://www.drupal.org/node/2910500). With the super user policy disabled, we may want to define a new one that grants admin permissions based on other user characteristics. For instance, we can specify that the site admins are users with a specific email domain or who have logged in through a particular authentication system.

Now, let's dive into the details of the new system using some examples.

Example 1 (alter permissions provided by Core)

Let's say we want to add a new policy that grants permission to access promotional banners only if the current language is English.

The LanguageAccessPolicy.php class may look like this:

class LanguageAccessPolicy extends AccessPolicyBase {

   public function alterPermissions(
      AccountInterface $account,
      string $scope,
      RefinableCalculatedPermissionsInterface $calculated_permissions
   ): void {
      if (\Drupal::languageManager()->getCurrentLanguage()->getId() == 'en') {
         $calculated_permissions->addItem(
            item: new CalculatedPermissionsItem(
               permissions: ['access promotional banners'],
               isAdmin: FALSE
            ),
            overwrite: FALSE
         );
      }
   }

   public function getPersistentCacheContexts(): array {
      return ['languages'];
   }
}

To register the policy in the service container, you need to add the following to your access_policy_demo.services.yml:

services:
   access_policy_demo.access_policy.language:
      class: Drupal\access_policy_demo\Access\LanguageAccessPolicy
      tags:
         - { name: access_policy }

You can now have this render array sonewhere in your code:

$build['content'] = [
   '#markup' => $this->currentUser()->hasPermission('access promotional banners') ? 'Some promotional banner' : '',
   '#cache' => [
      'contexts' => ['languages'],
   ],
];

The previous code will show the promotional banner only if the current language is English.

Revoke permission is possible by setting the overwrite parameter of the addItem method to TRUE, like this:

$new_permissions = array_diff(
   $calculated_permissions->getItem()->getPermissions(),
   ['view page revisions']
);

$calculated_permissions->addItem(
   item: new CalculatedPermissionsItem(
      permissions: $new_permissions,
      isAdmin: FALSE
   ),
   overwrite: TRUE
);

Altering permissions is possible because, during the access policy calculation, the object that holds the calculated permissions is an instance of the RefinableCalculatedPermissionsInterface that allows the addition or removal of permissions.
When the build and alter phases are complete, the calculated permissions are converted to an immutable object of type CalculatedPermissionsInterface. Using an immutable object guarantees that the computed permissions are not altered after the access policy calculation.

Drupal has moved from an RBAC (Role-Based Access Control) to a PBAC (Policy-Based Access Control) system where permissions are calculated based on a set of policies that are applied in a given context.

Access policies are tagged services, so you can define the priority with which they are applied:

services:
   access_policy_demo.access_policy.language:
      class: Drupal\access_policy_demo\Access\LanguageAccessPolicy
      tags:
         - { name: access_policy, priority: 100 }

The priority is a positive or negative integer that defaults to 0. The higher the number, the earlier the tagged service will be located in the service collection.

Now it's time to talk about scopes.

Example 2 (split the site into sections)

Until now, we have ignored the scope parameter, but look at how the hasPermission() method is implemented in Drupal 10.3:

public function hasPermission(string $permission, AccountInterface $account): bool {
   $item = $this->processor->processAccessPolicies($account)->getItem();
   return $item && $item->hasPermission($permission);
}

The processAccessPolicies() has a second, non-mandatory parameter: the scope.
The getItem() method has two non-mandatory parameters: the scope and the identifier.

Within Core, both scope and identifier default to AccessPolicyInterface::SCOPE_DRUPAL, and you probably don't have to deal with them in most cases.

But what are they used for?

The scope is a string that identifies the context in which the policy is applied, like a group, a domain, a commerce store, etc. The identifier is a string that identifies the specific value within the scope (like the group ID, the domain ID, etc).

The AccessPolicyInterface defines the applies(string $scope): bool method, which determines whether the policy should be applied in a given scope.

Let's try to implement (a very simplified) version of modules like Permissions by Term or Taxonomy Access Control Lite using the new system.

Suppose we have a vocabulary access, which terms represent a group of content that can be accessed only by a specific set of users. Content types and users are tagged with terms of this vocabulary.
The permissions a user has are calculated based on the standard roles mechanism of Drupal. But on nodes tagged with a term of the access vocabulary, if the user is tagged with the same term, the user has the permissions granted by an additional role.

We have the Content editor role that grants standard permissions like Article: Create new content or View own unpublished content, and the Content editor in term role that grants permissions like Article: Edit any content or Article: Delete any content. An editor always has the permissions granted by the Content editor role. Still, on nodes tagged with a term of the access vocabulary, if the user is tagged with the same term, the user has the permissions granted by the Content editor in term role too.

Image: User roles configuration section

The code for the TermAccessPolicy.php class may look like this:

class TermAccessPolicy extends AccessPolicyBase {
   public const SCOPE_TERM = 'term';

   public function applies(string $scope): bool {
      return $scope === self::SCOPE_TERM;
   }

   public function calculatePermissions(AccountInterface $account, string $scope): RefinableCalculatedPermissionsInterface {
      $calculated_permissions = parent::calculatePermissions($account, $scope);

      if ($scope != self::SCOPE_TERM) {
         return $calculated_permissions;
      }

      $user = User::load($account->id());
      $user_terms = $user->get('field_access')->referencedEntities();
      foreach ($user_terms as $user_term) {
         $cacheability = new CacheableMetadata();
         $cacheability->addCacheableDependency($user_term);

         $calculated_permissions
            ->addItem(
               new CalculatedPermissionsItem(
                  permissions: $permissions,
                  isAdmin: FALSE,
                  scope: self::SCOPE_TERM,
                  identifier: $user_term->id()
               )
            )
            ->addCacheableDependency($cacheability);
      }

      return $calculated_permissions;
   }

   private function getPermissions(AccountInterface $account): array {
      $extra_roles = User::load($account->id())
         ->get('field_extra_role')
         ->referencedEntities();

      if (count($extra_roles) === 0) {
         return [];
      }

      $extra_role = reset($extra_roles);

      return $extra_role->getPermissions();
   }

   public function getPersistentCacheContexts(): array {
      return ['user.terms'];
   }
}

In the previous code, we've defined a new scope term and we've implemented the applies method to return TRUE only if the scope is term.
Then, we calculate the permissions based on the terms the user is tagged with. We add a cacheable dependency on the term entity to invalidate the cache if the term changes.

Note that we've passed two more arguments to the addItem method: the scope and the identifier. The scope is the string term, and the identifier is the term ID.

We can register the policy in the service container with the following code:

access_policy_demo.access_policy.term:
   class: Drupal\access_policy_demo\Access\TermAccessPolicy
   tags:
      - { name: access_policy }

The getPersistentCacheContexts() uses a custom cache context, so we've to define it, too:

class UserTermsCacheContext implements CalculatedCacheContextInterface {
   public function __construct(
      protected readonly AccountInterface $account,
   ) {}

   public static function getLabel(): string {
      return t("User's terms");
   }

   public function getContext($term = NULL): string {
      $user = User::load($this->account->id());
      $user_terms = array_map(
         fn($loaded_term) => $loaded_term->id(),
         $user->get('field_access')->referencedEntities()
      );

      if ($term === NULL) {
         return implode(',', $user_terms);
      } else {
         return (in_array($term, $user_terms) ? 'true' : 'false');
      }
   }

   public function getCacheableMetadata($term = NULL): CacheableMetadata {
      return (new CacheableMetadata())->setCacheTags(['user:' . $this->account->id()]);
   }
}

A cache context needs to be registered in the service container, like:

cache_context.user.terms:
   class: Drupal\access_policy_demo\Access\UserTermsCacheContext
   arguments:
      - '@current_user'
   tags:
      - { name: cache.context }

Finally, we can use the new scope to check the permissions:

function access_policy_demo_node_access(NodeInterface $node, $operation, AccountInterface $account): AccessResultInterface {
   $access = FALSE;

   // This node is not under access control.
   if (!$node->hasField('field_access')) {
      return AccessResult::allowed();
   }

   // Always allow access to view the node.
   if ($operation == 'view') {
      return AccessResult::allowed();
   }

   // Check if the user has access to the node.
   $terms = $node->get('field_access')->referencedEntities();
   $type = $node->bundle();
   foreach ($terms as $term) {
      $item = \Drupal::service('access_policy_processor')
         ->processAccessPolicies($account, TermAccessPolicy::SCOPE_TERM)
         ->getItem(TermAccessPolicy::SCOPE_TERM, $term->id());

      if (!$item) {
         continue;
      }

      switch ($operation) {
         case 'update':
            $access = $item->hasPermission('edit any ' . $type . ' content');
            if (!$access && $item->hasPermission('edit own ' . $type . ' content')) {
               $access = $account->id() == $node->getOwnerId();
            }
            break;

         case 'delete':
            $access = $item->hasPermission('delete any ' . $type . ' content');
            if (!$access && $item->hasPermission('delete own ' . $type . ' content')) {
               $access = $account->id() == $node->getOwnerId();
            }
            break;

         default:
            $access = TRUE;
      }

      if ($access) {
         break;
      }
   }

   return $access ? AccessResult::allowed() : AccessResult::forbidden();
}

The previous code is just a rough example. Still, the critical thing to note is that we've used the TermAccessPolicy::SCOPE_TERM and the term ID to retrieve a CalculatedPermissionsItem that contains the permissions granted by the term to the user.

What a long journey! But we're not done yet.

One of the new system's most important features is that access policies are cached by context, but context can be dynamic and change during permission calculation; this is where the initial cache context comes into play.

Variation cache

Access policies usually vary by some context, like the user roles, the time of day, the domain, etc. Drupal has a concept of cache contexts that allows you to vary the cache based on some context, but until Drupal 10.2, this can be used only to add cache contexts to render arrays.

Now, all caches can use cache contexts thanks to the Variation cache.

Variation cache is not a new type of cache but a wrapper around the cache backends that already exist in Drupal. It has two interesting features.
The first one is that it allows varying a cache by context:

cache.access_policy:
   class: Drupal\Core\Cache\CacheBackendInterface
   tags:
      - { name: cache.bin }
   factory: ['@cache_factory', 'get']
   arguments: [access_policy]

variation_cache.access_policy:
   class: Drupal\Core\Cache\VariationCacheInterface
   factory: ['@variation_cache_factory', 'get']
   arguments: [access_policy]

In the previous example, variation_cache.access_policy is a wrapper around cache.access_policy. When I do something like:

$cache = \Drupal::service('variation_cache.access_policy');
$cache->set(['key1', 'key2'], 'value', ['user.roles', 'languages:language_interface'], ['user.roles']);

I'm saving value at the ['key1', 'key2'] of the access_policy cache, and I'm telling the variation cache that the cache will vary by the user.roles and languages:language_interface contexts.

Having not specified anything specific in the tags section of the cache.access_policy service, I get the default cache backend, typically the database one. I could have written:

tags:
   - { name: cache.bin.memory, default_backend: cache.backend.memory.memory }

To have a cache in memory.

Variation cache uses cache contexts to build cache IDs. For example, the cid for the contexts user.roles and languages:language_interface when the user has roles 3 and 4, and the language is English could be something like: key1:key2:[languages:language_interface]=en:[user.roles]=3,4. (Contexts are sorted in alphabetical order by name.)

The second feature comes from the fact that when I save data in the variation cache, I can specify two sets of contexts: the actual ones to vary the cache on (the third argument of the set method) and the "initial" ones (the fourth argument of the set method).

But what are these initial cache contexts? They are the ones that our data varies for sure, but they could not be the only ones. If, during the building of the data to cache, someone else adds one or more specific contexts, the cache system may not be aware of it.

When the set of final cache contexts is more specific than the initial ones, the variation cache stores a cache with an ID built using the initial cache contexts. That cache will not store the data but a redirect that contains the final cache contexts to use to find the actual data. This chain of redirects can span more than one level.

Let's add more complexity to our previous example about the TermAccessPolicy. Suppose that terms in the access vocabulary have a select field named is_restricted, with two values: Weekend and Weekdays. We want to grant the permissions not only if the node is tagged with a term but also based on the day of the week.

Image: Add a restriction to an access term

If no restrictions are set, the permissions are granted as usual. If a restriction is set, the permissions are only granted if the current day matches the restriction.

foreach ($user_terms as $user_term) {
   $cacheability = new CacheableMetadata();
   $cacheability->addCacheableDependency($user_term);

   $restricted = $this->isRestricted($user_term);
   if ($restricted) {
      $cacheability->addCacheContexts(['is_restricted']);
      $permissions = [];
   } else {
      $permissions = $this->getPermissions($account);
   }

   $calculated_permissions
      ->addItem(
         new CalculatedPermissionsItem(
            permissions: $permissions,
            isAdmin: FALSE,
            scope: self::SCOPE_TERM,
            identifier: $user_term->id()
         )
      )
      ->addCacheableDependency($cacheability);
}

return $calculated_permissions;

The isRestricted method can be implemented as follows:

private function isRestricted(TermInterface $user_term): bool {
   $restriction = $user_term->get('field_restriction')->getValue();

   if (count($restriction) == 0 || count($restriction) == 2) {
      return FALSE;
   }

   $field_value = $restriction[0]['value'];

   if ($field_value === 'weekend' && IsWeekendCacheContext::isWeekend()) {
      return FALSE;
   }

   if ($field_value === 'weekdays' && !IsWeekendCacheContext::isWeekend()) {
      return FALSE;
   }

   return TRUE;
}

The RestrictedCacheContext class can be like this:

class RestrictedCacheContext implements CalculatedCacheContextInterface {
   public static function getLabel(): string {
      return t('Is Weekend?');
   }

   public function getContext($parameter = NULL): string {
      $result = static::isWeekend() ? 'weekend' : 'weekday';

      return "is_restricted.{$result}";
   }

   public static function isWeekend(): bool {
      return date('w', time()) % 6 === 0;
   }

   public function getCacheableMetadata($parameter = NULL): CacheableMetadata {
      return (new CacheableMetadata());
   }
}

Now suppose to have two terms:

Section1 (tid=1) with the restriction set to Weekend
Section2 (tid=2) with no restrictions

And two users:

User1 tagged with Section1
User2 tagged with Section2

And we're on Sunday.

When permissions are calculated for User1, the initial cache context will be user.terms, but then we'll add the is_restricted cache context because the Section1 term is restricted.
When permissions are calculated for User2 the initial cache context will be user.terms, and no other cache context will be added.

The cache will be something like:

access_policies:term:[user.terms]=2 => Drupal\Core\Session\RefinableCalculatedPermissions
access_policies:term:[user.terms]=1 => Drupal\Core\Cache\CacheRedirect (cacheContexts: ["user.terms", "is_restricted"])
access_policies:term:[is_restricted]=is_restricted.weekend:[user.terms]=1 => Drupal\Core\Session\RefinableCalculatedPermissions

The Variation cache stores the data for access policies that vary only by user.terms directly.
For the access policies that also vary by is_restricted, it stores a redirect (along with information about the final cache contexts to look for: user.terms and is_restricted).
To access a cache with more final cache contexts than the initial ones, the variation cache will need to follow a chain of redirects.

Conclusion

The new Access Policy API is a powerful tool that allows the implementation of complex access control systems in Drupal.
It's a big step forward from the old system based on only roles and permissions.

In the future, we'll see more and more contrib modules that will use this new system to convert custom logic to the new system. At SparkFabrik, we've already started using it in custom modules for our customers.

Resources:

I've set up a GitHub repository with the code used in this blog post: https://github.com/lussoluca/access_policy_demo. You can clone it and use DDEV to run the code.

This blog post would not have been possible without the help of the following resources:

dxday: A Report

Davide Boncompagni — Tue, 18 Jun 2024 09:00:00 +0000

Introduction

On the 14th of March we were at DxDay, the first conference organised by GrUSP dedicated to the Developer Experience.

It was very cool to see so many different focuses on the same topic, showing how delicate and articulated the DevEx concept is.\
GrUSP will upload the videos of the speeches in the next few months, but if you are already feeling the fear of missing out, we will try to give you the essence of the speeches in this article to give you a taste of what the conference was like.

What is DevEx?

Developer Experience is the study of how people, processes, culture and tools affect the ability of developers to work efficiently. This is a definition provided by Github in one of their blog posts.
As mentioned before, developer experience is a complex and holistic concept, and we need to understand that none of these aspects can overcome the lack of another area, if you want to improve it, you need to work on each topic: technologies, tools, processes, culture and people.

This means that building a good DevEx requires a lot of effort!

It's also a dynamic, evolving concept, and improving it is a continuous process, not a static goal.
But even small steps can contribute, so you should manage the improvement gradually and develop a DevEx improvement process rather than a single big action, dividing the effort required into subtasks.

Why working to improve DevEx

Pleasure in work brings perfection to work.
(Aristotele)

The main reason to improve DevEx is to increase productivity and quality in its broadest sense.

It's not only about increasing revenue, but could potentially lead to it. The goal is to remove most of the friction, reduce cognitive load, automate repetitive tasks, improve communication and processes, create a positive mindset, flesh out the company's vision and mission, and unleash the full potential of human capital.

Striving for quality, creating a trusting environment and being transparent about areas that need improvement could create engagement and a proactive tendency where employees feel they can contribute to improving the overall structures and start to do so.
However, the main output metric of DevEx should be increased developer motivation and perceived satisfaction.

Talks

Ok, with that concept disambiguation out of the way, let's talk about the conference.
First of all, 4 of the 7 talks focused on tools for developers and the other 3 on process management and culture fostering.
The speakers come from very different backgrounds, which might justify the different focuses of their talks

Tools focused talks

Let's start with the tools, Maxim Salnikov, Developer Productivity Lead @ Microsoft showed us the power of GitHub Copilot and its ability to understand the context of your project, a tool that claims to allow developers to request all the boring tasks that keep them in the zone, making it easier to experiment the world famous Mihály Csíkszentmihályi flow state. Such a very ambitious claim and also a very ambitious goal: to offer a pair programming experience without the need for a senior engineer and increase productivity.
If you live in the desert or come from another planet and have never heard of Copilot, take a look at this "magical" looking tool.

Talita Gregory Nunes Freire Engineer @ Spotify and Vincenzo Scamporlino Senior Engineer @ Spotify have demoed Spotify Backstage, a tool that allows you to easily build a developer portal, an interface that could aggregate all your utilities for your microservices, allowing you to have a schematic view of your microservices' dependencies for example, but also much more!

They claim to address issues such as discoverability, system ownership, fragmentation, duplication and context switching. The focus is on reducing cognitive load, improving collaboration and transforming complex software into manageable units. We also use Backstage for some projects at SparkFabrik and its adoption is growing every day, confirming it as the de facto standard tool for complex cloud project management. Oh yeah, I forgot, this tool is completely open source, great!

Lou Bichard, Product Manager @ Gitpod, talked about his groundbreaking and, in such cases, futuristic Gitpod, a cloud development tool that removes the pain of onboarding and transforms your projects into code-ready, globally maintained development environments, removing the abstraction of infrastructure in your environment, what Lou called outer loop removal, a production-like environment. It looks like VSCode but in your browser, a future where you can upgrade hardware resources without changing your PC.

And it's not just Gitpod's product manager who is betting on cloud environments, but also Francesco Corti, Principal Product Manager @ Docker, with his talk on the future of growing DevEx tools, highlighting how companies are increasingly interested in this type of solution. He also tried to foresee the future of AI tools, predicting a future where we will move to a whole team of specialised AI assistants that will help you not only to automate boring tasks, but also to create documentation, debug, deploy, make data entries, get feedback on requirements, respect and test your software, an environment where developers don't usually code, but ask AI to do it for them.

If you have never heard of any of these technologies, look for demos, tutorials and so on, because it takes too much effort to explain all their functionalities in this blog post, the good news is that there are tons of resources about them.

Processes and culture-focused conversations

As I said, it's not just about tools, history has taught us that: the aeolipile was the first steam engine, but it didn't lead to a revolution, probably because the Greek culture didn't need to replace servant work. For DevEx, it is also easier to demonstrate because we work in teams: communities made up of people with social dynamics that affect our ability to perform.

Abiodun Olowode, Senior Engineering Manager @ Factorial, introduced us to Documentation Driven Development, which focuses on process optimisation, and how this could shine a light on team collaboration and knowledge sharing, potentially reducing code churn and introducing a faster feedback loop that could accelerate development.
One thing we've too often forgotten is that developers want to know why something works the way it does, why one implementation was chosen over another, we can understand code but we can't always deduce the reasons behind it and it's not always possible to ask someone for an explanation, we need a more robust and shared tool like documentation.
And also this kind of development could lead to less intolerance about writing docs, because it became part of development, you don't have to pass back your whole implementation process to describe it, the task becomes progressive and manageable. However, it was cool that maintaining and developing a tool together could improve DevEx.

Thomas Khalil, DevEx Head of Platform & Site Reliability Engineering @ Trivago, with his beautiful allegory of the Wizard of Oz, described some of the behavioural patterns that people in the organisation tend to adopt in order to challenge the psychologically complex situations that our jobs require today, and how empathy and awareness could lead people to unleash their true potential.
For Kahil, DevEx is about deeply understanding people's needs, motivations and aspirations, building trust, finding answers behind their defensive behaviours without needing a guru, keeping processes adaptable and choosing metrics wisely, keeping in mind that they are and should be holistic metrics. Even though it wasn't the focus of his talk, I'd like to focus on Kahil's use of surveys to identify areas for improvement and employee perceptions.

Suffering comes from trying to control what is uncontrollable, or from neglecting what is in our power
(Epictetus)

This quote used by Kahil highlights the main problem of the archetypes he describes and reminds us to try to improve what is in our power and to take care of it.

Dulcis in fundo our Paolo Pustorino, Head of HR @ SparkFabrik with his talk focused on the influence of culture on DevEx, alignment of values, sense of community, engagement, commitment, caring, transparency and the importance of psychological safety as a driving engine of developer experience satisfaction. He gave a lot of information about the processes of recruitment, onboarding and also career paths within Sparkfabrik and how the company tries to support you along the way, asking you for feedback on relationships, core values, training needs and perspectives. He gave an insight into the company's goals, such as the pursuit of quality in a broad sense (not only technical quality, but also relationship quality, communication quality, which revolves around the value of transparency, etc.) and the decision to make cultural fit and team fitness the key guiding values required during recruitment in order to preserve the culture and DevEx quality within the company.

"The chef is not the best cook in the kitchen, but he helps everyone to succeed" is probably the most emblematic phrase describing the previous assumptions. He also talked about the so-called Expert's Deception, the bias that innovation is a process driven by exports when their main quality is to offer experience, assumptions based on the past rather than challenging the status quo, and the desire to avoid the Peter Principle with career progression.
He gave us an introduction to the Cynefin framework, which could help you to support line managers in their work, remembering that you need to avoid instilling fear to get people to perform at their best.

I hope that you now have a broader perspective on DevEx and that you understand that a good company culture usually coincides with optimising tool adoption, but no tool adoption can improve your company culture.

Metrics

We didn't talk so much about metrics to measure it, only Kahil did a little bit. We need to specify that we need to separate developer productivity or job performance metrics from DevEx metrics or job satisfaction.
Even if your ultimate goal is to improve productivity, make sure you have improved DevEx first. DevEx metrics could give you insight to better understand productivity metrics and could encourage hidden latent innovation processes.

One of the most popular tools in this area is the SPACE framework, which uses some performance metrics to gain insight into DevEx. It's an acronym that stands for the following concepts:

Satisfaction and Well-being: it measures how healthy and happy developers are, with a focus on psychological safety and satisfaction, worrying about workload and detecting and acting on possible toxic practices such as Compulsory Citizenship Behaviour (CCB) or lack of boundaries with personal life such as calls outside working hours. It also consists of assessments of personal goals and aspirations such as tool adoption and so on.
Performance: difficult to measure because the business outcome doesn't imply a quality outcome. To balance better quality and quantity outcomes, you will better separate the metrics for the two areas, allowing you to understand if you are sacrificing code quality to deliver fast, undermining developer satisfaction and increasing code churn with its associated costs.
Activity: Many activities such as brainstorming, meetings, or supporting a teammate are not usually evaluated by these metrics. Choosing the right metrics in this area could give you insights into quality, such as spending enough time on design decisions, code review, refactoring and identifying bottlenecks.
Communication and Collaboration: focus on information discoverability and dissemination, network metrics, role clarity, awareness, transparency and team member contribution to team fitness. These metrics could influence all other areas of the SPACE framework.
Efficiency and flow: the ability to complete work with minimal interruption or delay, measured by what is known as focus time. For efficiency, we could suggest the famous DORA (DevOps Research and Assessment) metrics: deployment frequency, change lead time, change failure rate and mean time to recovery (MTTR).

All these aspects could be measured individually or for teams, and we also have to mention that maximising one factor could have a negative impact on another, like for example reducing interruptions to improve flow could damage the collaboration of the team, it's not a law but consider that this could happen, so you will better have a holistic approach and also always consider that metrics by themselves are not reliable and could reflect other things, the choice of these metrics itself reflects company or team opinions and is influenced by irrationality processes.

Try to extract insights from metrics rather than using them as a driving force.

Conclusions

Unhappy the land that is in need of heroes.
(Bertolt Brecht)

DevEx focuses on improving the development environment with tools, but also in terms of a social environment that allows people to express their full potential.
A corporate culture less focused on workaholism and control and more on empowerment and trust contribute to DevEx, and in this sense could help the adoption of a transformational leadership style or Hansei framework, or encourage community participation and avoid silo mentality that could lead to a positive sense of identity with the larger organization and its members and could unleash Organizational Citizenship Behaviors (OCB) that consists in spontaneous mentoring, support, conscientiousness and sportsmanship that create virtuous cycles that put people in conditions to express their potential.

I don't know if future tools will move from promoting staying in the zone and achieving flow experiences to leading to Maslow's peak experiences, at least for those working from the Greek concept of Meraki, but as focused on Kahil's talk, the right tool at the wrong time might not be able to improve DevEx, and certainly gurus are not the answer, as Paolo also noted, we need to foster and nurture a psychologically safe environment with transparency, trust, communication, empathy, room for mistakes to avoid spreading fear because innovations arise from failure, so never lose the spark!

Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better.
(Samuel Beckett)

Building a Sustainable Web: a practical exploration of Open Source tools and strategies

Valeria Salis — Thu, 13 Jun 2024 09:00:00 +0000

Introduction

In the past few years I've been deeply concerned about climate change. My journey on web environmental sustainability
started by chance when I stumbled upon the concept of "sustainable web".

I first learned how to create a better User Experience taking in consideration sustainability principles
and strategies, but it wasn't enough. I wanted to go deeper and understand more about the environmental impact of the web.\
In this blog post I will share my journey, the tools and the strategies I've come across and learned and, last but not least, the
role of Open Source and the relevance of its community aspect.

Let's start from the beginning

For me, the Internet has always been my happy place: it made me discover many of my passions and hobbies, it allowed me to learn new things, connect with people, entertain myself with some tv shows or movies and even work.

However, the Internet has various cons, and one of them is that, sadly, it is not very environmentally friendly.

"If the Internet was a country, it would be the 4th largest polluter" - Sustainable Web Manifesto

The sentence above is the opening sentence of the Sustainable Web Manifesto, and it has been the very first sentence I
read about web sustainability.\
It broke down the idea I had of the web being a "place" with only positive aspects and made me realize that, in reality, it
has some responsibilities regarding the environment.

In fact, the Internet is responsible for about 4% of total CO2 emissions, which
may seem like a small percentage, but it's actually double the emissions of the air transport sector ("only" 2%).

UX and Web Sustainability

The "first stop" of my journey was related to User Experience: on the occasion of UX Day 2023,
an Italian conference that took place in Faenza, I had the opportunity to bring my contribution with a talk called “UX and Web Sustainability”.

You can find the recording here.

If you've been following this tech blog for a while, you might have encountered my previous blog post about this specific
topic, but I will summarize the main points here:

sustainability also means speed, performance, usability and accessibility
applying sustainability principles will make our websites load faster and help users navigate them more easily
designing for the environment also means designing for everyone because when the majority of people are able to navigate our websites and applications, the energy required to run them won't be wasted.

Working towards a more environmentally friendly UX will make users happier.

Great starting point, wasn't it? It wasn't enough for me, though.

Cloud Native Sustainability Week

The second stop of this journey took place in October 2023 on the occasion of Cloud Native Sustainability Week, which
is a global event organized by the CNCF (Cloud Native Computing Foundation).

It's a series of local meetups around the topic of sustainability in the cloud native ecosystem: basically
is that time of the year when the local communities involved with the CNCF dedicate time to spread awareness and share content
(blog posts, talks, panels, etc.) about environmental sustainability.

You can find more information about the event here.

I had the opportunity to attend the meetup in Milan and contribute with a lightning talk about "how bad we use the Cloud"
and the consequences of our approach.\
The main takeaway I would like to share here is that we should be more aware of the data we store because approximately 90% of cloud data is used only one time.

We store data and then forget about it, but it's still there, consuming energy and resources.

As a software developer, what else can I do?

By that time, I had learned the importance of applying sustainability principles to the user experience, and the benefits not only for the environment, but also for the users. I had also learned that we need to be more aware of our data, how we use it, and its impact on the environment.

But UX and cloud are just two pieces of the puzzle, and in some ways on opposite sides of our applications.\
There's a lot more between UX and the cloud, so I kept going back to fill in the gaps I had in my head.

Green software for practitioners

One of the first resources I came across was the online course Green software for practitioners created by the Green Software Foundation (GSF) along with The Linux Foundation.

If you're not familiar with the GSF, their mission is to "build a trusted ecosystem of people, standards, tools and best practices for developing
and building green software".

Spoiler: later we will have a look at one of the tools they developed!

Getting back to the subject of this paragraph, if you're a software developer or someone involved in building, deploying, or managing a software application and you want to do so in a greener way, I would recommend the Green Software for Practitioners course as a starting point.

I recommend this course for several reasons, including:

it is an online course and entirely self-paced
it gives you a complete glossary and a proper introduction to the main topics around green software development

Today I will give you a "teaser" of some of the key concepts I've learnt from the course, but I highly recommend you to fully take it.

Main actions to reduce the carbon footprint of software

To reduce the carbon footprint of software, we must consider three main actions:

🍃 Energy efficiency, which consists of consuming the least amount of electricity possible
💻 Hardware efficiency, which consists of using as little embodied carbon as possible
🌱 Carbon awareness, last but not least, the purpose of this action is doing more when the electricity is clean and less when it's dirty (e.g., using demand shifting and/or demand shaping methods);

What you can't measure, you can't improve

The second topic I wanted to share in this blog post is the importance of measuring, which is also one of the main chapters in the course.\
Indeed, in order to improve the environmental sustainability of our software, we need to measure its impact on the environment.

Greenhouse Gases Protocol (GHG)

The Greenhouse Gases Protocol (GHG) is the most widely used and internationally recognized greenhouse gas accounting standard.
It divides emissions into three main scopes:

Scope 1, direct emissions from operations owned or controlled by our organization (or the one we're applying this protocol for)
Scope 2, indirect emissions related to emission generation of purchased energy (for example, electricity)
Scope 3, other indirect emissions from all the activities the organization is engaged in, including the ones from the organization's supply chain

When it comes to software, knowing the scopes your emissions fall into is challenging because it depends on your specific scenario.\
However, you will find some examples in the course.

Software Carbon Intensity (SCI)

The Software Carbon Intensity (SCI) was developed by the GSF and aims to give a score to
a software application in order to understand how it behaves in terms of carbon emissions.\
The SCI specification has recently achieved the ISO standard status: you can find more information in this article.

It's not a replacement for the GHG protocol, but rather an additional metric to more specifically address the characteristics of our software to make more informed decisions. The main difference between GHG and SCI is that the former categorizes emissions into scopes, while the
latter divides them into operational emissions and embodied emissions and, as its name suggests, it's an intensity rather than a total.

The SCI is calculated using the following equation:

SCI = ((E * I) + M) per R

E = energy consumed by a software system (in kWh)
I = location-based marginal carbon emissions (carbon emitted per kWh of energy so gCO2/kWh)
M = embodied emissions of a software system
R = functional unit, it is the core characteristic of the SCI and the reason why it "becomes" an intensity and not a total

What about the community?

The final step of this exploration will be about open source and the community aspect that inevitably contributes in some ways to our journey. For me, it has been a pivotal element related to environmental sustainability and tech.

Environmental Sustainability Technical Advisory Group

The very first community I became part of was the Environmental Sustainability Technical Advisory Group which is part of the CNCF. The TAG Env Sustainability's goal is similar to the GSF's: their mission is to "advocate for, develop, support and help evaluate environmental sustainability initiatives in cloud native technologies."

At the moment, the TAG has two main working groups:

the Green Reviews group (WG Green Reviews), which is more focused on technical issues, metrics and developing tools
the Communications group (WG Comms), which is more focused on spreading awareness and sharing content and the work done by the Green Reviews group

In the TAG, people are involved in different ways depending on their technical skills and/or interests, but the main thing I've had the opportunity to see is that everyone wants to do something, participate, and lend even a small helping hand to the currently active projects and discussions.
Having a community of people with different backgrounds and approaches to rely on, ask questions of, share content with, and discuss with is an excellent way to learn and achieve a more complete result.

This is what open source is all about: sharing, learning, contributing, and growing together.

Conclusion

In this blog post, I've tried to give you an example of a learning path a wannabe-greener-dev could follow, based on my experience and the tools and resources I've come across.

Environmental sustainability is a broad topic, and since there isn't a defined clear and linear path, it can be challenging for someone to get started, especially when we're talking about engineering and software development, since it can be challenging to even understand that our work has an impact on the environment.

Bonus: some other tools and resources

Here's a list of some other open source tools you might find useful in your journey towards a more sustainable web:

Developers page of The Green Web Foundation, in this page you can find some projects and libraries to try out and contribute too, such as C02.js, Grid Intensity CLI, Greencheck API and a lot more
Open Sustainable Technology, a website that collects a list of open source projects and tools environment related
kube-green, a tool that helps you reduce the carbon footprint of your Kubernetes clusters
Ecograder, a tool that helps you understand how sustainable your website is and gives you some tips on how to improve it; it's based on various open source libraries.

Along with the online tools, I would recommend you the following books:

Sustainable Web Design by Tom Greenwood
World Wide Waste by Gerry McGovern
How bad are bananas? by Mike Berners-Lee (yes, Tim Berners-Lee's brother)
Building Green Software - A sustainable approach to software development and operations by Anne Currie, Sarah Hsu and Sara Bergman

Open Source Day: A Report

Davide Boncompagni — Fri, 07 Jun 2024 09:00:00 +0000

Introduction

On the 7th and 8th of March we were at the Open Source Day organised by Schrödinger Hat, and it was a two-day conference full of enthusiasm and innovation in the framework of the innovative Nana Bianca coworker space in Florence, but if you were not there you can at least follow on YouTube their amazing talks https://www.youtube.com/@SchrodingerHat/streams or https://www.youtube.com/@SchrodingerHat/videos and the agenda https://2024.osday.dev/it/agenda.
As you can see there were a lot of amazing ones and I will try to help you decide which talk you should definitely follow.

Technology Trends

There were 2 main trends:

AI tools, especially LLM related ones, how to build LLM RAG based applications using open source tools from Hugging Face and Ollama.
WebAssembly and its wider implications for software development.

And there was also a "shadow trend", not an explicit trend, but an ecosystem of similar technologies, namely:

CDC (change data capture), CRDT (conflict-free replicated data types) and concurrent collaboration or real-time update platforms.

If you don't have experience with these tools, I recommend Stefano Fiorucci's talk on what an LLM application is, how it works, how to implement it, what it is and how to implement Retrieval Augmented Generation applications with Haystack, our Edoardo Dusi with his talk on WebAssembly, how it works and how it could become a new future standard due to its interoperability, versatility and great performance, Wasm component wrappers, integration with Docker and Kubernetes and much more, and Federico Terzi with a technical explanation of CRDT and what challenges you need to face to achieve real-time collaboration utilities.

My favourite technology tool talks

I will briefly report on my favourite talks and start with some lesser known extensions to a very famous tool, Iulia Feroli's talk, Senior Developer Advocate at Elastic, showed us how easy and powerful Elasticseach could become with the use of some specialised clients allowing us to perform sentiment analysis and semantic search for example.

Sentiment analysis is an NLP technique that allows you to identify the positive or negative polarity of a given query, while semantic search is the search or ranking of content based on contextual relevance and intent.
For example, you could analyse a list of customer comments and intercept those that could lead to an escalation, or perform a search without having to know the exact terminology (e.g. a search for 'brave' could also return 'courage' and so on).\
The client used to import LLM into Elasticsearch was Eland, the ELSER NLP model was used to perform semantic searches, she also did a little briefing on how vertex search allowed us to perform semantic searches and remembered that vertex search could also be used to search for similar images for example.

Noam Honig, creator of Remult showed us a new way from backend to frontend, a full-stack CRUD framework that removes all code duplication between frontend and backend like dtos creation, data validation and so on, providing ORM-like database interaction and archiving a Typesafe and DRY architecture. With a live coding session, he showed us how fast it is to build a full-stack application with Remult. It has a lot of features, but the one I find most interesting is the ability to do live queries, long-lived queries that automatically update as results change. It can be integrated with many JavaScript frameworks and many databases.

Give it a try, maybe with fast prototyping, and you will love the philosophy behind this tool with a clear focus on improving the developer experience.

Mario Fiore Vitale, Senior Software Engineer at Red Hat, talked about Debezium, an open source platform that enables Change Data Capture (CDC), the ability to intercept changes in your database and propagate them across different systems, which could be very useful for synchronising multiple linked data sources, data replication, updating or invalidating a cache, updating search indexes, data synchronisation or propagating database changes via Kafka or a WebSocket. CDC enables incremental loading and eliminates the need for bulk updates. Debezium captures database changes by monitoring the database transaction log, so it doesn't impact the database itself.

Other interesting technologies included Nanocl, a Rust alternative to Kubernetes that grew out of a study project, Irine Kokilashvili's talk, Camunda, a tool based on business process modelling (BPM), which is a way to orchestrate and describe complex microservices processes and flows, as shown by Samantha Holstine, LavinMq a very performant message broker described by Christina Dahlén, Scrapoxy the amazing web scraping Swiss knife by Fabien Vauchelles and finally Graziano Casto showed us Rönd, a lightweight Kubernetes sidecar that distributes security policy enforcement throughout your application based on OpenPolicy Agent.

A broad view of the conference

As you can imagine, an open source conference doesn't just focus on tools, but also on high-level analysis and experiences of open source development.

There was a focus on accessibility in a broad sense, not only for people with disabilities, but also for people with neurodivergence or temporary disabilities for example, and how to create an environment that helps them to be productive and satisfied with their work, improve their development experience and develop an inclusive workplace.
Also, although it hurts, I learned that Linux doesn't currently have great accessibility tools, so if you want to start an open source project for Linux, consider that we're trying to fill that gap!

Another topic was what open source is, its different forms, how to monetise or develop a business model for an open source project, how to protect it from being appropriated by big vendors and the differences between FOSS and OSS.

They also talked about the security of the software supply chain and how reliable open source technologies can be, with a presentation on the use of Linux in space missions.

There was also space for ethics, like a UNICEF talk on the challenge of making digital solutions and services accessible and 'profitable' for the most vulnerable, and also a focus on web sustainability, like that of our Valeria Salis, who wasn't able to be present at the event, but which you can watch from this link https://www.youtube.com/watch?v=KWK8Upl9-wU.

I would also like to focus on the talk by Andrey Sitnik, the maintainer of a widely used library such as Post-CSS and so on, who gave us a complete manual on how to manage an open source project, recalling how it is fully linked to relationship management, the need to give quick feedback, to trust contributors and to consider them as the people behind what they are asking for, inviting us to empathise with them, to gain insight into why, for example, your detailed documentation is never read as carefully as you expected, or to understand why some projects that you thought might be more popular are instead ignored despite their potential, to remember how the adoption of a framework or so on depends more on irrational processes than cold analysis.

Why Open Source

What emerged from the talks was enthusiasm and positivity, open source as a tool that could spread values of commitment, collaboration and tolerance, and develop social communities of mutual respect and status quo challenging innovation, a kind of friendly world utopia, a tool to indirectly promote a better world.
As PJ Hagerty's talk points out, don't expect this to always be true, we need to foster good open source citizenship ourselves first.

Nowadays many companies claim that their products are OSS as a marketing strategy, but this is not always completely true (especially for some AI tools) and some big projects started to change their licences to some more restrictive or sometimes closed ones.
However, open source adoption is still very high and it's growing, with more than 90% of developers relying on open source components in their proprietary applications.

But probably in the future, the need to protect large projects from being forked and the business models of the companies behind them, the adoption of open core strategies will change the definition of open source and it will only define projects where the source code is public/available for inspection and there will be a clear distinction between OSS and FOSS where redistribution will be free.
Until then, open source is still a philosophy, and to embrace it, to claim it, is to have a mentality around it.

And speaking of mentality, I want to focus on a term that is rarely quoted, but I think it should be a core concept related to OSS, and that is the autotelic concept.

Autotelic is an adjective that describes activities that exist for their own sake, because experiencing them is the main goal, but also people who do things moved by intrinsic motivation, not by wealth, fame, power research, not by concern for money, status, applause or recognition by others, and it's linked to the ability to experience flow more often and is used to describe some art, sport or play activities.

This perspective overwhelms the idea of contributors being driven by ego, which is relevant in open source development.

Public opinion perceives OSS as a tool that promotes free culture and considers it to be a more transparent system, and therefore a more secure system, without any dark patterns inside.
Can free access to source code be a professional standard in the future, demanded by people in the same way that we demand the components of a medicine in the package leaflet?

We don't know yet, a lot will depend on how events affect public opinion, whether people start to care more about concepts like their privacy and whether they start to trust open source software more than proprietary software.

Will FOSS continue to exist? Probably yes, because libraries or tools for developers focus on usage and if they're free it's easier for them to be adopted, also the development of these tools gives prestige to the people or companies that have worked on them and is also a way to create a process of continuous improvement.

The affirmation of open source lies in the transformation of users into active actors, able to report bugs and sometimes suggest new features, and this is very common in tools for developers, but still a little lacking in general-use tools for the general public.

There are also adoptions of the open source model outside of software development, such as in the arts or education, which probably need more resonance, and we probably need to spread the open source mentality beyond the boundaries of software development.

There are several challenges to overcome, but we hope that open source will be able to flourish, because "a mind is like a parachute. It doesn't work if it's not open" - and that certainly applies to software!

How (and why) to contribute to open source

Edoardo Dusi — Thu, 01 Feb 2024 09:00:00 +0000

Introduction

In the previous post on our blog, Daniela shared her thoughts and experiences on how difficult it can be to contribute to open source. It was hard for me to review this post. I felt like I had failed as a senior developer, as a mentor, and as a long-time member of the open source community. Then I started thinking about the current state of open source, and what Daniela wrote made sense: to a newcomer, everything seems to be driven by the hype, the star count, the likes, the followers, we have tech influencers, we have tech rockstars giving keynotes at conferences, we have recruiters scanning GitHub profiles.

Contributing today is about being visible, not about being helpful. And I think my generation of developers is to blame.

In this post, I will try to respond to Daniela and all the people who struggle to contribute to open source, and most importantly, I will try to talk about the motivations that should drive our contributions.

Contributing to Open Source

First, definitions! Computer scientists have never been good at definitions. We call "artificial intelligence" something that is not intelligent, and we call "cloud" something that is on the ground and sometimes below sea level. We tried with Free Software and we had to specify what we meant by "free", and when we realised we needed a more specific definition we created the Open Source Initiative and we had to specify what we meant by "open".

If we cannot agree on what open source means, we cannot agree on what it means to contribute to open source.

If we stick to the OSI definition, which is derived from Debian's definition of Free Software, we are only talking about how the source code can be accessed, and how the license that governs the distribution of the software should be written.

But when we talk about open source, we're not just talking about code, or at least I thought we were. We are talking about a way of approaching software, of designing it, developing it, distributing it, spreading it, making it something that benefits everyone. So being a developer in this context means thinking of software as a common good, and then contributing means making it better, and if by better we mean more useful, more accessible, more secure, more powerful, more stable, easier to use, then it is clear that we are not just talking about writing code.

It would be pointless to list all the non-coding contributions, I just want to point out participation in groups that create guidelines, documentation and translations, those that try to spread best practices, or all the working groups that deal with standardization. But think about how much valuable discussion is generated in GitHub issues, discussion that leads to better software. None of these activities generate a green square in the contribution grid on your GitHub profile, but each one helps improve the entire ecosystem.

Once we agree on the definition of open source and what it means to contribute, we can move on to the second point in this reflection.

Why contribute

When I started university in Bologna in the early 2000s, the first community I came into contact with was a kind of Linux user group that organized, in a very informal way, so-called "installation parties", i.e. days when some more experienced users would guide us newbies through the first install of a Linux distribution.

In addition to guiding us through the process of installing Gentoo, which was not a random choice, they would suggest what to do when we encountered a problem or noticed something that could be improved. As you may have guessed, this included posting to our newsgroup, starting a discussion on the official Gentoo Forums, and even using the mailing list. This approach made it natural for me and my fellow travelers to think about communicating with senior members of the community whenever the opportunity arose, at first just as generators of trivial questions, then more refined, and finally as proposers of solutions or improvements. I never made a commit to the Gentoo codebase, but I felt useful to the community when I answered a colleague's question about how to fix a compile error by creating a symlink to a library that was in the wrong path.

A few years later I started working with Drupal, still one of the largest and most beautiful free software projects, and interacting with other users on issue trackers, suggesting patches, reporting bugs felt natural to me. Of course, getting the green light from automated tests on an uploaded patch was a good feeling, and when it was merged I felt like I could talk to Dennis Ritchie as an equal, and so I am no stranger to this reward mechanism.

What drove me to contribute, however, was not the reward. It became a necessity, as I was often a few bugs away from delivering a job to a client, and then I felt I had to at least give to others what I had received, so I found myself responding to those who encountered problems I knew how to overcome, or sometimes simply helping by providing my context that might help them understand how to reproduce the bug.

It was therefore, and still is, a business motivation. "Don't reinvent the wheel" has been a mantra, building on what others have already introduced and perfected and then making it better, participating in advocacy groups that shape the future of a technology, and many other aspects of the open source world codified and regulated by organizations such as the OSI, but also the Linux Foundation or the Drupal Association, are all aspects that directly impact our work and thus our business.

Reading Daniela's post presented me with a completely different experience. Talking to her, I realized first of all that she did not find the same conditions in the academic environment that I did, and later that she did not find the communities that I did.

So the social, utilitarian, and "belonging" motivation that drove me, and I think many others around me, was missing, and what was left was rewards. Of course, recognition had always helped to distinguish an active member of a community from others, but it had never generated such strong pressures as to drive someone to contribute for the sole purpose of being visible. I seem to see this problem in the desperate search for a project to contribute to, any project, as long as it is popular and publicly acknowledges contributions, and especially if it is on GitHub, which here becomes the social network where a developer's popularity is measured.
(This also removes Drupal from the list of trendy projects...)

Gamification, badges, likes, they're nice things and we all love them, let's not be hypocritical, but if they're the main reason people contribute today, then we have a problem, and we probably created it ourselves. We've created an environment where it's more important to be visible than to be helpful, and we've given that message to the new generation of developers, but we're telling them today that those motivations are wrong.

So I think it's important to reiterate what it means to do open source.
Let's start from that foundation and try to adjust the focus.

How to contribute - for real

Let's start with a basic concept: you don't have to contribute!

There are amazing programmers out there who have zero commits to public GitHub repos, yet they work with open source projects every day. Sometimes focusing on work or perhaps a busy personal life makes it difficult to find time to contribute, and that's not a problem, it shouldn't make us feel guilty.
Helping a colleague use a technology, making it more accessible by spreading it among your peers, are examples of activities that truly benefit the entire ecosystem but do not entitle you to a badge.

But if, after making all these points, the desire to appear in a project's CHANGELOG remains, because it makes us more desirable in the eyes of a recruiter, or because it makes us feel more important in our community, which are all things I completely understand, then I can try to give some advice on how to contribute.

Start with what you use: You work with libraries or frameworks every day, and by now you know them well; these are the perfect projects to start with. If you need to customize a certain feature to make it more useful for your project, or you find a bug, or you see that some of the documentation could be improved, that's your chance.
There is no such thing as a "stupid contribution": If you think you have a solution to a problem or an idea for improving something, don't be afraid to share it. If you're not sure, ask for feedback, but know that every contribution is valuable, and the worst thing that can happen is that it's rejected.
Don't be afraid to ask: If you don't understand something or aren't sure what to do, ask. There are many channels available, from the official documentation, to the issue tracker, to the community forum, to the chat, to the mailing list. Most (hopefully all) communities are welcoming and eager to help.
Don't overlook the non-code contributions: You can help with translations, documentation, testing (which by the way IS coding...), or even just by spreading the word about a project.
There is more than just GitHub: Many open source projects are not on GitHub, but they still need love. Just ask Drupal.
Join Discussions: Issues and Discussions on GitHub are the most popular, but not the only, way to get started. You can learn a lot about a project from these discussions, commenting increases your visibility and participation in the community, and code contributions can often result.

Conclusion

Open Source is not just code. It's a way of thinking about software, and contributing means making it better.
You don't have to contribute, and I hope that in the future we can create a more welcoming environment for new contributors, and that the reward mechanism will change to reflect effort and dedication, rather than just commits.

Thank you for reading this far, and if you have any questions or comments, please feel free to contact me at Mastodon or LinkedIn.

DruBOM: An SBOM for Drupal

Edoardo Dusi — Mon, 29 Jan 2024 09:00:00 +0000

Introduction

Securing the software supply chain is a hot topic for organizations globally. The recent SolarWinds hack demonstrated that even the most security-conscious organizations can be vulnerable, and as a result, government agencies and security experts worldwide agreed on the need for standards and best practices to achieve a more secure software ecosystem.

One fundamental element is the ability to identify all components of a software project, including dependencies, and their versions. This is called a Software Bill of Materials (SBOM). With this information, organizations can track the components and their versions, and be able to identify and mitigate vulnerabilities.\
There are several initiatives to create standard formats for SBOMs, including CycloneDX, SPDX, and others.

We are working on a Drupal-specific SBOM called DruBOM. In this post, we will explain what DruBOM is, how it works, and how you can use it.

What is DruBOM?

First of all, this is a Drupal module, it needs to be downloaded and installed using Composer, and requires Drupal 9.3 and above or Drupal 10.3 and above.

To generate the SBOM it integrates Anchore Syft, so this needs to be installed on the server. Syft is a CLI tool written in Go that analyzes the contents of a container image or directory on the file system and generates an SBOM in various formats, including CycloneDX and SPDX.

If these requirements are met, DruBOM will generate an SBOM for the Drupal project, including the Drupal core, modules, themes and libraries, as well as PHP and JavaScript dependencies. The default format is CycloneDX, but it can be configured to use other formats supported by Syft.

How does DruBOM work?

The initial version of the module is very simple. It detects the Syft binary and calls it passing the Drupal root directory and the output format as parameters, then saves the output to the key-value store with the drubom.sbom key and the current timestamp.

You can then download the SBOM, or better yet, use it with automated tools to detect vulnerabilities and/or licensing issues.

How to use DruBOM?

The first step is to add the DruBOM module to your Drupal project.\
Run composer require sparkfabrik/drubom and then enable the module with drush or via the Drupal administration interface.

After installing and enabling the module, navigate to Administration » Configuration » System » DruBOM settings and specify the path of the Syft binary. The binary must be executable by the PHP process.

Note: the PHP configuration must allow the use of proc_open(), which is equivalent to exec() in terms of security.

Once the configuration is saved, generate the SBOM by clicking the Generate SBOM button on the settings page or by visiting the /drubom/generate path with a user who has the necessary permissions. The generated list will be saved on the Drupal DB and can be downloaded by clicking the Download SBOM button.

Image: Screenshot of a DruBOM administration page

You can also use the drush drubom:generate command to generate the SBOM from the command line. To download it, use the drush drubom:download command.

What's next?

The scope of the module is very specific, so we don't expect it to grow much in terms of features. During the Drupal Contribution Weekend 2024 we improved the documentation and the administration interface, added an integration with the System Status page in Drupal administration, and started integrating with Grype to also detect vulnerabilities, which is a step forward in terms of security.

We consider this module to be fully stable and ready for production use, so we encourage you to try it out and give us feedback. If you find any problems, please report them to the issue queue.

How (not) to contribute to open source

Daniela Bonvini — Thu, 25 Jan 2024 09:00:00 +0000

Introduction

The idea of contributing to open source projects is often presented as an easy task that anyone can do. However, in reality, it can be a very challenging journey. Despite hearing countless times that contributing to open source is simple, it wasn't until I tried it myself that I realized this was not the case. In this text, I will share my own experience with open source contribution to provide an honest and informative account of what it truly entails.

Act 1: The grand illusion

In the beginning, I started to ask my colleagues for tips on where to start, and they pretty unanimously said to search for issues with for beginners or help wanted tags, maybe in some of the projects I was already using at work. Well, I thought, that's easy. I got a short list of the libraries I was using and/or I was interested in and started digging into their GitHub repositories. I combed dozens of open issues, but either they had no good first issue tag, or the more accessible things got snatched lightning fast.

So I went back to those who had suggested this route and asked for advice again, and this time they told me that I probably couldn't look in the famous libraries, where the competition was too fierce; I had to find my hidden gem in smaller projects.

I restarted my search, feeling slightly disgruntled. While it's nice to offer help, it's even better if that help is given to a prestigious library that you can boast about to other developers. It's natural to want to showcase our accomplishments, especially to those who understand our work. My parents only see value in my ability to fix their phones, so let me have this one thing.

I then perused less-known libraries, confident that I would be lucky this time. But I wasn't.
All I could find were libraries with complicated tasks, even the ones marked for beginners, in which the tag was very much misplaced, as in you had to know the codebase exceptionally well to fix even the minor stuff.
So OF COURSE I rolled up my sleeves, drew upon my inner strength, and found the perfect fix, after which everybody hailed me as the best contributor in the world.

Yes, no, of course not, otherwise we wouldn't be here. I quit. Just like that.

Act 2: Reality check

Let's jump a few months ahead, and the OS itch returned to me. I have a friend who makes videos about OS. He was doing one on Hacktoberfest ¹, saying that there were no physical prizes to discourage issue-taking spammers this year. This was my long-awaited chance, I was certain!

So I went to the Hacktoberfest site and combed the starting section. There, I found a link to a site that collected issues suited for first-timers, grouped by project. If they were included in the most famous site for the most famous OS event of the year, they certainly must be what I was looking for, right?

At first, I tried filtering by language, trying JavaScript, and looking at some of the open issues. Even worse than with my previous attempt months before, I couldn't even find the issues this time: they were snatched so fast that the site wasn't always updated on time, so it listed things already being worked upon or even fixed and merged.
So I narrowed my search and went where only the bravest engineers dare to go: CSS fixes.
But even doing so, I was again faced with the problem of finding only not-really-for-beginners-beginners-tagged issues. So, once more, I gave up.

Third time's the charm, and now I was fixated on having to make at least one OS contribution, so after Hacktoberfest was over, I tried another of the many tips I had been given previously: fix the documentation and find typos or bugs even before an issue is opened.

This was pure coincidence; I was researching Angular's Signals, and I knew that the .mutate() function was taken out of the APIs. (For context, this was just a couple of days from the announcement).
I checked the documentation and, lo and behold, it was still there. I thought this was my chance for glory: a small, not-yet-mainstream documentation fix in a famous project. So I rushed over to the Angular GitHub, and I'm sure you've guessed it: It was already fixed and just waiting to be merged in. And it was snatched just before I checked, so double the annoyance.

Act 3: The Hidden Gem

That was the last straw; cumulatively, I had spent more time looking for something to do than actually doing it. But I really wanted to contribute!
So a few more months went by, until one day I met an Italian open source maintainer and long-time speaker, Giorgio Boa, who by the way was a guest on our podcast Continuous Delivery, and asked him for advice, saying that I wanted to be part of the OS world. He said he was working on a small library of Qwik components and could help me if I wanted. I gladly accepted, and we found an issue that seemed pretty straightforward.
A few days after our conversation, I followed the little README guide to install everything required, and...nothing worked. So, after a few bad words, a lot of doubt about my skills as an engineer, and self pep talks to overcome my shyness about asking for help, I contacted Giorgio again. Even with his help, at first we had some trouble figuring out what was going wrong, but in the end I finally had a working setup.

Eventually, I finally had time to start working on it. It seemed easy; Boa had already given me some tips on how to get started, so I got half the work done in a short time. But then the problems started. After going in circles for about a day, I finally gave in. I did the scariest thing of all: I once again asked for help, admitting that I had no idea what was going wrong. We tried to look at it together, but we couldn't find the problem right away. So I committed the part that I did that worked, and the next day Giorgio fixed the other half and merged my very first PR into the Qwik Storefront.

So, in the end, I finally got what I wanted: a published contribution in a good library, but I couldn't stop wondering if it was all worth it.
I was proud of it, of course, even though I needed some help. But I wanted more out of my work.
In the beginning I felt like a fraud for not contributing to OS, but in the end even contributing, or trying to contribute, made me feel like a fraud for not knowing enough and being more of a burden to a senior contributor than an additional help.

Looking back at it now, I think my biggest mistake was trying to do it for the hype, trying to conform to what everybody else around me said I should be doing and not because I really believed in what I was doing and why.
It doesn't really matter what anyone else says or does, because at the end of the day it's your time that's being spent solving these issues, and that time has to mean something to you if it's being taken away from other parts of your life.

I haven't resolved any other issues since then, and for now that's ok for me. I want to resolve an issue all by myself next time, but I want to be sure to do it for the right reasons this time, to avoid any unnecessary stress.
Knowing that this time, if I do go back and contribute, it won't be for the "glory" or the FOMO (Fear Of Missing Out), but for the kindness I've been shown, and which I hope to one day give back to a fellow developer in need.

Conclusion: The Truth Unveiled

So am I saying you shouldn't contribute to OS? Well, of course not. But I am stressing the importance of doing it because you really want to, or because you think the project you are working with will benefit from your contribution, not because everyone else is doing it and telling you how important it is, or because you really want a free T-shirt. As we've seen, helping in OS is not a walk in the park, so you must engage in it knowing what you're really getting into to avoid unnecessary frustration.

If you enter this world fully aware of what you're up against, you'll find it easier to accept the difficulties that come with trying to start contributing to open source. It will also give you the mental strength to accept failure when the problem you thought was beginner-friendly turns out to be much more treacherous than you thought.
What will be different is your reaction in front of this problem, as you will now know that there's no shame in not being able to close a beginner-tagged issue or even in asking somebody more skilled than you for help. Even though you'd have to ask two, three, or a hundred times. Just know that it is ok to fail and to need support and it doesn't make you any less of a developer.

Post Scriptum

This post offers my personal viewpoint on contributing to open source software, with the awareness that alternative methods of contribution, such as identifying and reporting bugs or translating documentation into other languages, exist but may be less widely known to those who are new to open source communities. Rather than purporting to present the definitive truth, the aim of this post is to provide a different angle on the difficulties that beginners may encounter when trying to make their mark in this world of contribution. The text conveys a thought-provoking perspective while upholding the utmost respect for individuals who consistently contribute to the open-source world.

EDIT: we also wrote a reply to this post that you can find here

Footnotes

Hacktoberfest is an annual worldwide event held during the month of October. The event encourages open source developers to contribute to repositories for the whole month.
Up until 2022, if 4 of your PRs got merged, you would receive a free t-shirt and sometimes other swag, which created utter chaos, with loads of fake or useless pull requests being spammed all over the GitHub universe. ↩