I am pleased to be able to announce the launch of iSole 3D, a state-of-the-art 3D printer specifically designed for insole production, on our - now publicly available - corporate website.

As lead software developer, I was responsible for developing the advanced software stack, including a user-friendly interface for easy printer management. iSole 3D brings precision, customisation, and efficiency to insole production, allowing you to produce high-quality insoles tailored to specific needs.

Visit our the website at isole3d.com to explore some of the features of iSole 3D and learn how it can improve your insole production process.

Thank you for your support!

Bas Kamer
Lead Software Developer
iSole 3D

When working on multiple projects, I kept running into the same challenge: serving EmberJS SPAs within a NestJS backend. The existing @nestjs/serve-static module didn't quite cut it, so I created nestjs-ember-static.

Why nestjs-ember-static?

Live Reloading:
Keep your development smooth with live reloading, so you see changes instantly.

Config Injection:
Inject configuration directly into the index.html file, allowing dynamic adjustments.

Perfect for Mono Repositories:
Easily manage both front-end and back-end codebases in a single repository.

Easy Setup

Basic Configuration:

import { Module } from '@nestjs/common';
import { join } from 'path';
import { EmberModule } from 'nestjs-ember-static';

@Module({
  imports: [
    EmberModule.forRoot({
      rootPath: join(__dirname, '../frontend/dist'),
    }),
  ],
})
export class AppModule {}

Advanced Configuration:

import { Module } from '@nestjs/common';
import { join } from 'path';
import { EmberModule } from 'nestjs-ember-static';
import { ConfigService } from '@nestjs/config';

@Module({
  imports: [
    EmberModule.forRootAsync({
      useFactory: async (configService: ConfigService) => {
        const env = configService.get('env', { infer: true });
        return {
          rootPath: env['name'] === 'development'
            ? join(env['appRoot'], '../frontend/dist')
            : join(env['appRoot'], 'client'),
        };
      },
      inject: [ConfigService],
    }),
  ],
})
export class AppModule {}

Custom Inject Helpers

Make custom changes to your HTML with inject helpers:

export abstract class AbstractInjectionHelper {
  public abstract process(htmlElement: HTMLElement): void;
}

export class TitleInjectionHelper extends AbstractInjectionHelper {
  constructor(private title: string) {
    super();
  }

  public process(htmlElement: HTMLElement): void {
    htmlElement.querySelector('title')!.textContent = this.title;
  }
}

Conclusion

nestjs-ember-static makes developing with EmberJS and NestJS easier by providing live reloading, config injection, and is perfect for mono repositories. Give it a try to streamline your development process!

Check it out on npm.

In the recent years, I made a significant shift in my deployment strategy by fully adopting Dockerized deployments. Previously, my deployments were automated using Ansible, which was effective and reliable. However, as my application evolved and became fully containerized, I transitioned to using docker-compose up for deployments, a method I was already accustomed to from my development workflow.

Using Docker Compose for deployments initially seemed like a natural progression. It allowed for straightforward service definitions and easy orchestration on a single host. However, as my application grew and I needed to deploy multiple versions—such as production and staging environments—on the same infrastructure, I encountered a significant limitation. Docker Compose does not provide isolated networks for each deployment, leading to port conflicts when running multiple instances of the same service stack. This required me to manage port configurations manually through environment variables (.env files), which became increasingly cumbersome and error-prone.

Recognizing the need for a more robust solution, I decided it was time to move my orchestration to Docker Swarm. Docker Swarm offers several advantages over Docker Compose, particularly in a production environment with multiple service instances. Here are some key benefits and considerations that drove this decision:

Benefits of Docker Swarm

One of the main benefits of moving to Docker Swarm is its automatic handling of network isolation for different service stacks. This feature means that I can deploy multiple environments (production, staging, etc.) without worrying about port conflicts. Each stack operates within its own isolated network, simplifying configuration and reducing the risk of errors. This network isolation is, for me, the primary advantage and a significant improvement over Docker Compose.

Another key benefit is scalability. Swarm mode enables easy scaling of services. I can increase or decrease the number of replicas for each service with a single command, allowing my application to handle varying loads efficiently. This scalability is essential for maintaining performance during peak usage times.

Even for single node deployments, I have found Docker Swarm to be effective because of its other benefits. However, horizontally scaling can be achieved without any configuration changes just by adding some worker nodes. Note that I have found adding nodes for applications using volumes remains challenging, and I have not yet identified a good solution for deploying to Digital Ocean infrastructure, where ideally, you would want block storage mounts to follow containers.

Swarm includes an internal load balancer that distributes traffic evenly across service replicas. This ensures that no single instance becomes a bottleneck, improving the overall responsiveness and reliability of my application.

With Docker Swarm, I can perform rolling updates to my services without downtime. This allows me to deploy new versions of my application gradually, reducing the risk of introducing errors and ensuring a smooth transition for users.

Finally, since Docker Swarm is built into Docker, there is no need to install additional software. I already have Docker installed, which comes with Swarm, and I am familiar with the Docker CLI tools. This familiarity reduces the learning curve and makes the transition smoother.

Transitioning to Docker Swarm

The transition from Docker Compose to Docker Swarm involves several steps, but the process is straightforward:

Motivation: Local vs. Remote Deployment

Before diving into the steps, it's essential to understand the motivation behind transitioning to Docker Swarm, especially when managing local versus remote deployments. Managing deployments locally using Docker Compose is convenient and straightforward, but when it comes to deploying applications to remote servers, the complexity increases. Docker Swarm simplifies this process by allowing seamless management of multiple environments through Docker contexts. This means I can easily switch between local and remote deployments, ensuring that I am deploying to the correct environment without the risk of mistakes. Setting up Docker contexts helps streamline the workflow and provides a more structured approach to handling various deployment environments.

1. Set Up Docker Context

Before deploying, it's advantageous to set up Docker contexts. Docker contexts allow you to easily switch between different Docker environments (e.g., development, staging, production). This step simplifies managing multiple clusters and ensures you are deploying to the correct environment. To create and use Docker contexts, follow these steps:

docker context create <context_name> --description "<description>" --docker "host=ssh://user@hostname"
docker context use <context_name>

After switching to a context, you gain the ability to execute the Docker CLI in a local directory as if it is on a remote server. This is really like magic and very useful.

2. Initialize Swarm Mode

On your manager node, initialize Swarm mode:

docker swarm init

3. Create a Docker Stack File

Convert your docker-compose.yml file to a Swarm stack file (e.g., stack.yml). The syntax is mostly the same, but with some additional Swarm-specific configurations, such as resource limits, deploy strategies, and scaling limits.

4. Deploy the Stack

Deploy your stack using the docker stack deploy command:

docker stack deploy -c stack.yml <stack_name>

5. Manage Services

Use Swarm commands to manage your services, such as scaling and updating:

docker service scale <service_name>=<replica_count>
docker service update --image <new_image> <service_name>

Conclusion

Transitioning from Docker Compose to Docker Swarm for production deployments offers numerous benefits, including network isolation, scalability, single node effectiveness, load balancing, and seamless rolling updates. These features are essential for maintaining a robust and efficient production environment, especially as your application and its deployment needs grow. By leveraging Docker Swarm, I can simplify the deployment process, reduce configuration overhead, and enhance the reliability of my application services.

Embracing Docker Swarm has been a game-changer for my projects, and I highly recommend it for anyone facing similar challenges with Docker Compose in a production setting.

Footnote: While Docker Swarm has lost some traction compared to Kubernetes, it remains a simpler system to manage. Kubernetes has a steep learning curve and is often overkill for smaller projects. I follow the recommendation that for small clusters and teams, Docker Swarm is still a great and cost-effective solution.

Recently version many of prooph's components were updated to a new mayor release. One of its components is the prooph/snapshot-store able to serialize, and persist aggregates so they do not have to be reconstituted from the event stream when they are needed again.

A missing feature was the ability to use a different serializer/deserializer. It turned out to be relatively simple to implement it in such a way with backward compatible. All you have to do to change the following;

Both the PdoSnapshotStore and MongoSnapshotStore are now capable of consuming a Serializer which takes care of serialization/unserialization;

interface Serializer
{
    public function serialize($data): string;
    public function unserialize(string $data);
}

A default Serializer is implemented as CallbackSerializer which will use the build-on serialize/unserialize method of PHP. Simply instantiate it with different callbacks to change it's default behavior.

$connection = new PDO(...);
$tableMap = [];
$tableName = 'snapshots';
$serializer = new CallbackSerializer('igbinary_serialize', 'igbinary_unserialize');

$snapshotStore =  new PdoSnapshotStore(
    $connection,
    $tableMap,
    $tableName,
    $serializer
);

If you prefer to use a psr/container driven application you simply need to create a factory for the Serializer interface;

class SerializerFactory
{
    public function __invoke(ContainerInterface $container): Serializer
    {
        return new CallbackSerializer(function ($data) {
            return gzdeflate(serialize($data), 9);
        }, function ($data) {
            return unserialize(gzinflate($data));
        });
    }
}

the declare a dependency for the factory;

return [
    'dependencies' => [
        'factories' => [
            Serializer::class => SerializerFactory::class,
        ],
    ], 

and add a key to the snapshot configuration;

return [
    'prooph' => [
        'pdo_snapshot_store' => [
            'default' => [
                'connection_service' => 'pdo.connection',
                'serializer' => Serializer::class
            ],
        ],

Do not forget to clear existing snapshots and reset running snapshot projectors.

I finally came around to solve an annoying issue in an EmberJS application that uses websockets to connect to RabbitMQ messaging. The issue is with disconnects after a network error and existing subscription to the channels. I had solved the principal reconnect issue before in a similar fashion as described here.

But as I also use channel subscriptions these active subscriptions should also be restored when the connection is restored...

The idea is that I track those channels subscription, so when an connection error happens I can simply add those a list of pendingSubscriptions.

import Ember from "ember";
import ENV from "../config/environment";
import webstomp from "npm:webstomp-client";

/* global SockJS */

export default Ember.Service.extend({
  account: Ember.inject.service(),
  store: Ember.inject.service(),
  client: null,
  identity: Ember.computed.alias('account.identity'),
  /**
   * Established subscriptions
   * {name: {connection: value, destination: destination} (on which a unsubscribe method is available)
   */
  establishedSubscriptions: {},
  /**
   * Subscriptions that have been requested but are not yet possible because a connection is available yet.
   * {name: destination}
   */
  pendingSubscriptions: {},

  /**
   * Start a connection
   */
  initialize: function () {
    this.connectAndReconnect(`https://${ENV.APP.mq.baseHost}/stomp`, () => {
      Ember.debug('Connected established...');
      this.subscribeToPendingSubscriptions();
    });

    this.requestSubscription('lab-plhw-identity/all', "/exchange/lab-plhw-identity/all");
  },
  subscribeToPendingSubscriptions: function () {
    if (!this.client.connected) {
      setTimeout(() => {
        this.subscribeToPendingSubscriptions();
      }, 1500);

      return;
    }

    let subscriptionName;

    for (subscriptionName in this.pendingSubscriptions) {
      if (this.pendingSubscriptions.hasOwnProperty(subscriptionName)) {
        /**
         * First unsubscribe from destination
         */
        if (!Ember.isNone(this.establishedSubscriptions[subscriptionName])) {
          this.establishedSubscriptions[subscriptionName]['connection'].unsubscribe();
          // remove established
          delete this.establishedSubscriptions[subscriptionName];
        }
        /**
         * Subscribe to destination
         */
        let destination = this.pendingSubscriptions[subscriptionName];
        Ember.debug('Subscribing to: ' + destination);
        this.establishedSubscriptions[subscriptionName] = {
          connection: this.client.subscribe(destination, this.onMessage.bind(this)),
          destination: destination
        };

        // remove pending
        delete this.pendingSubscriptions[subscriptionName];
      }
    }
  },
  requestSubscription(subscriptionName, destination) {
    this.pendingSubscriptions[subscriptionName] = destination;

    Ember.run.scheduleOnce('afterRender', this, this.subscribeToPendingSubscriptions);
  },
  onUserIdChanged: Ember.observer('identity.id', function () {
    this.requestSubscription('lab-plhw-identity/identity', "/exchange/lab-plhw-identity/" + this.get('identity.id'));
  }),

  /**
   * To enable debugging for SockJS execute this in the console and reload "localStorage.debug = '*';"
   *
   * @param socketUrl
   * @param successCallback
   */
  connectAndReconnect: function (socketUrl, successCallback) {
    Ember.debug('Connecting to: ' + socketUrl);

    let sock = new SockJS(socketUrl/*, {transports: ???}*/);

    this.client = webstomp.over(sock, {
      binary: false,
      heartbeat: {outgoing: 0, incoming: 0},
      debug: ENV.environment !== 'production'
    });

    this.client.connect(
      ENV.APP.mq.username,
      ENV.APP.mq.password,
      (frame) => {
        successCallback(frame);
      },
      (error) => {
        /**
         * Connection lost... Make sure that for existing subscriptions new subscriptions are requested
         */
        let subscriptionName;
        for (subscriptionName in this.establishedSubscriptions) {
          if (this.establishedSubscriptions.hasOwnProperty(subscriptionName)) {
            this.requestSubscription(subscriptionName, this.establishedSubscriptions[subscriptionName]['destination']);

            delete this.establishedSubscriptions[subscriptionName];
          }
        }

        Ember.debug('Connection error: ' + error.reason);
        setTimeout(() => {
          this.connectAndReconnect(socketUrl, successCallback);
        }, 1500);
      },
      ENV.APP.mq.vhost
    );
  },
  onMessage: function (message) {
    let payload, store = this.get('store');

    switch (message.headers['content-type']) {
      case 'application/json':
        payload = JSON.parse(message.body);
        break;

      default: // assume 'text/plain'
        payload = message.body;
    }

    Ember.debug('Recieved payload for: ' + message.headers['destination']);

    switch (message.headers['destination']) {
      case '/exchange/lab-plhw-identity/' + this.getWithDefault('identity.id', 'xxx'):
      case '/exchange/lab-plhw-identity/all':
        if (!Ember.isNone(payload.changeset)) {
          if (!Ember.isNone(payload.changeset['entity-insertions'])) {
            Ember.A(payload.changeset['entity-insertions']).forEach(function (mutationPayload) {
              const mutationData = JSON.parse(mutationPayload);
              store.pushPayload(mutationData);
            });
          }
          if (!Ember.isNone(payload.changeset['entity-updates'])) {
            Ember.A(payload.changeset['entity-updates']).forEach(function (mutationPayload) {
              const mutationData = JSON.parse(mutationPayload);
              store.pushPayload(mutationData);
            });
          }
          if (!Ember.isNone(payload.changeset['entity-deletions'])) {
            Ember.A(payload.changeset['entity-deletions']).forEach(function (mutationPayload) {
              const mutationData = JSON.parse(mutationPayload);
              let record = store.peekRecord(mutationData.data.type, mutationData.data.id);
              if (!Ember.isNone(record)) {
                record.unloadRecord();
              }
            });
          }
        }
        break;
      default:
        Ember.debug('payload not for me');
    }
  }
});

Because I have figured this out more than once... I present my notes on how to setup an ember-cli project with sass css.

Additionally I will add the bootstrap framework and a pattern to be able to override it's .scss sources. I focus on the Bootstrap framework but the above should work with any library that have sources in sass.

Finally I describe a tiny pattern I have found useful regarding directories and css.

First we'll init a ember project. You can do this with any existing ember project, but please note that ember-cli only allows to use one styling language.

mkdir new-app
cd new-app
ember init
npm uninstall ember-welcome-page --save-dev

SASS

It is not difficult to switch to SASS support to in ember project. First some dependencies.

npm install broccoli-funnel --save-dev
npm install broccoli-merge-trees --save-dev
bower install bootstrap-sass --save
ember install ember-cli-sass

Then it is necessary must modify the ember-cli-build.js file to be able to generate css from .sass (or .scss) files.

I define the includePaths option of ember-cli-sass to bower_components/bootstrap-sass/assets/stylesheets. This simply makes it possible to do @import 'bootstrap/*'; within our application styles file.

A 'Funnel' is created to be able to use the bootstrap icon fonts.

/*jshint node:true*/
/* global require, module */
var EmberApp = require('ember-cli/lib/broccoli/ember-app');
var Funnel = require('broccoli-funnel');
var MergeTrees = require('broccoli-merge-trees');

module.exports = function (defaults) {
  var app = new EmberApp(defaults, {
    sassOptions: {
      includePaths: [
        'bower_components/bootstrap-sass/assets/stylesheets'
      ]
    }
  });

  // Use `app.import` to add additional libraries to the generated
  // output files.
  //
  // If you need to use different assets in different
  // environments, specify an object as the first parameter. That
  // object's keys should be the environment name and the values
  // should be the asset to use in that environment.
  //
  // If the library that you are including contains AMD or ES6
  // modules that you would like to import into your application
  // please specify an object with the list of modules as keys
  // along with the exports of each module as its value.

  // @see https://ember-cli.com/user-guide/#using-broccoli-funnel
  var bootstrapAssets = new Funnel(app.bowerDirectory + '/bootstrap-sass/assets/fonts/bootstrap', {
    srcDir: '/',
    include: ['**/*.*'],
    destDir: '/fonts/bootstrap'
  });

  return app.toTree(new MergeTrees([bootstrapAssets]));
};

Finally renaming app/styles/app.css to app/styles/app.scss enables us to do something like this @import "bootstrap/normalize"; and have the sass preprocessor find the correct file.

mv app/styles/app.css app/styles/app.scss

A directory pattern for styles

Organizing style segments is kind of hard. I usually start out cleanly but things get muddier as I build my app. Here is a directory structure as a suggestion.

mkdir app/styles/bootstrap
mkdir app/styles/bootstrap/overrides
mkdir app/styles/mixins 
mkdir app/styles/body-classes

And some files

echo '// application variables' > app/styles/variables.scss
echo '@import "variables";' > app/styles/app.scss
echo '@import "bootstrap/bootstrap";' >> app/styles/app.scss
cp ./bower_components/bootstrap-sass/assets/stylesheets/bootstrap/_variables.scss app/styles/bootstrap/overrides/variables.scss

Add the following (as needed) to app/styles/app.scss

@import "variables";
@import "bootstrap/variables";
@import "bootstrap/overrides/variables";

@import "bootstrap/mixins";
// Reset and dependencies
@import "bootstrap/normalize";
@import "bootstrap/print";
@import "bootstrap/glyphicons";

// Core CSS
@import "bootstrap/scaffolding";
@import "bootstrap/type";
@import "bootstrap/code";
@import "bootstrap/grid";
@import "bootstrap/tables";
@import "bootstrap/forms";
@import "bootstrap/buttons";

// Components
@import "bootstrap/component-animations";
@import "bootstrap/dropdowns";
@import "bootstrap/button-groups";
@import "bootstrap/input-groups";
@import "bootstrap/navs";
@import "bootstrap/navbar";
@import "bootstrap/breadcrumbs";
@import "bootstrap/pagination";
@import "bootstrap/pager";
@import "bootstrap/labels";
@import "bootstrap/badges";
@import "bootstrap/jumbotron";
@import "bootstrap/thumbnails";
@import "bootstrap/alerts";
@import "bootstrap/progress-bars";
@import "bootstrap/media";
@import "bootstrap/list-group";
@import "bootstrap/panels";
@import "bootstrap/responsive-embed";
@import "bootstrap/wells";
@import "bootstrap/close";

// Components w/ JavaScript
@import "bootstrap/modals";
@import "bootstrap/tooltip";
@import "bootstrap/popovers";
@import "bootstrap/carousel";

// Utility classes
@import "bootstrap/utilities";
@import "bootstrap/responsive-utilities";
@import "bootstrap/theme";

Copy any bootstrap scss file so you can override properties and css definitions in each of them.

You'll need to import them from app/styles/app.scss. Beware of the order you import them.

Body classes

A pattern that I found useful makes use of routes that upon activation add classes to the body tag.

ember install ember-body-class

All routes have a classNames attribute of type Array. If you wanted to add a body class page-special to your route, it would look like this:

export default Ember.Route.extend({
  classNames: ["page-common", "page-special"]
})

Then I create a file per use body class and import them in app/styles/app.scss.

// app/styles/pages/page-common.scss
body.page-common {
// a things are black
}

// app/styles/pages/page-special.scss
body.page-special {
// special things are red
}

The Ember way to Bootstrap

Since we've now added bootstrap css compilation to our workflow it might be an idea to also add these ember-bootstrap integrations.

ember install ember-bootstrap
ember install ember-bootstrap-cp-validations

To avoid adding ember-bootstrap compiled css modify ember-cli-build.js to instruct it not to include it.

'ember-bootstrap': {
  'importBootstrapCSS': false,
  'importBootstrapTheme': false
},

Vendor CSS Prefixing

Completely free bonus step

Install the ember-cli-autoprefixer addon so you can simply write the css you know and forget about vendor prefixing.

ember install ember-cli-autoprefixer

Then add a list of browsers (per environment target) to your packages.json so the prefixer (and other npm modules) can do its magic.

See browserlist for more information on this subject.

"browserslist": {
  "production": [
    "last 2 version",
    "ie 10"
  ],
  "testing": [
    "last 2 versions"
  ],
  "development": [
    "last 2 versions"
  ]
}

I've been using FQCN as the names of command, queries and events in my prooph application. I felt it was time to change those long and ugly names to something more readable. In various places these names are used in configuration so I wanted to keep the ability to easily refactor and jump into classes.

To change the name of messages we should do two things for different circumstances. For whenever we instantiate messages ourselves we must override the $messageName property in out Message.

direct instantiation of messages

// done in some script, direct instantiation of messages
$this->commandBus->dispatch(new RegisterUser([
    'user_id'           => (string) UserId::generate(),
    'display_name'      => $dataToImport['display_name'],
    'email_address'     => $dataToImport['email_address'],
    'password_hash'     => $dataToImport['password_hash'],
    'registration_date' => $dataToImport['registration_date'],
    'account_status'    => $dataToImport['account_status'],
    'email_status'      => $dataToImport['email_status'],
]));

In my messages adding this protected $messageName = 'identity.registerUser'; would be sufficient but I created a special CommandName class with only constants representing the messages names. My Command therefore looks like this;

final class RegisterUser extends Command implements PayloadConstructable
{
    use PayloadTrait;

    protected $messageName = CommandName::registerUser;

    /**
     * @return UserId
     */
    public function userId(): UserId
    ...

instantiation of messages via factory

For these situations we should create a new message factory that is capable of mapping these names to classes.
I came up with this one where the following should be noted; It is almost a verbatim copy of the FQCNMessageFactory that ships with prooph and that it is still capable of creating messages by FQCN. This is important because you might not have control over every message. (eg the Prooph\Snapshotter\TakeSnapshot Command)

use My\Domain\Identity;

class CustomMessageFactory implements MessageFactory
{
    protected $messageMap = [
        Identity\CommandName::registerUser => Identity\Command\RegisterUser::class,
        ...
    ];

    /**
     * @param string $messageName
     * @param array $messageData
     * @throws \UnexpectedValueException
     * @return CustomMessageFactory
     */
    public function createMessageFromArray($messageName, array $messageData)
    {
        if (isset($this->messageMap[$messageName])) {
            $messageClass = $this->messageMap[$messageName];
        } else {
            $messageClass = $messageName;
        }

        if (! class_exists($messageClass)) {
            throw new \UnexpectedValueException('Given message name is not a valid class: ' . (string) $messageClass);
        }

        if (!is_subclass_of($messageClass, DomainMessage::class)) {
            throw new \UnexpectedValueException(sprintf(
                'Message class %s is not a sub class of %s',
                $messageClass,
                DomainMessage::class
            ));
        }

        if (!isset($messageData['message_name'])) {
            $messageData['message_name'] = $messageName;
        }

        if (!isset($messageData['uuid'])) {
            $messageData['uuid'] = Uuid::uuid4();
        }

        if (!isset($messageData['version'])) {
            $messageData['version'] = 0;
        }

        if (!isset($messageData['created_at'])) {
            $time = (string) microtime(true);
            if (false === strpos($time, '.')) {
                $time .= '.0000';
            }
            $messageData['created_at'] = \DateTimeImmutable::createFromFormat('U.u', $time);
        }

        if (!isset($messageData['metadata'])) {
            $messageData['metadata'] = [];
        }

        return $messageClass::fromArray($messageData);
    }

enable factory

To enable the factory in the prooph middleware we change the appropriate (don't need to do them all at once) message_factory to our newly created factory.

return [
    'prooph' => [
        'middleware'     => [
            'query'   => [
                'message_factory'   => \My\Messaging\CustomMessageFactory::class,
                ...
            ],
            'command' => [
                'message_factory'   => \My\Messaging\CustomMessageFactory::class,
                ...
            ],
            'event'   => [
                'message_factory'   => \My\Messaging\CustomMessageFactory::class,
                ...
            ],
            'message' => [
                'message_factory'   => \My\Messaging\CustomMessageFactory::class,
                ...
            ],
        ],

And finally we can change every occurrence in the application configuration from the My\Domain\Command\RegisterUser::class name to My\Domain\Identity\CommandName::registerUser.

I find this useful because it keeps the configuration files readable. Especially since there are many locations where message names are used in configuration, in routing, busses, rbac in-memory configuration, etc...

Additionally, recorded events names are now independent of the actual used class.

Update: I moved the $messageMap property from the CustomMessageFactory to the various CommandName classes (per bounded context) because now I can change commands in one location.

class CustomMessageFactory implements MessageFactory
{
    /**
     * @var array maps message names to FQCN per bounded context domain
     */
    protected $messageMap = [
        'identity'    => Identity\CommandName::MESSAGE_MAP,
        ...
    ];

    public function createMessageFromArray($messageName, array $messageData)
    {
        $domain = explode('.', '$messageName', 2)[0];

        if (isset($this->messageMap[$domain][$messageName])) {
            $messageClass = $this->messageMap[$domain][$messageName];
        } else {
            $messageClass = $messageName;
        }
        ...

final class CommandName
{
    const MESSAGE_MAP = [
        CommandName::registerUser => Command\RegisterUser::class,
    ];

    const registerUser = 'identity.registerUser';
    ....
}

Recently I encountered a library that requires its logger dependencies to implement the psr-3 standard. A common interface for logging libraries. I wanted to use the zend loggers because they are easy to configure and already used in my application.

General configuration

Zend has a LoggerAbstractServiceFactory which is capable of instanciating multiple loggers configured via configuration files. Simply registering the LoggerAbstractServiceFactory as abstract factory dependency enables it.

// config/autoload/logging.global.php
return [
    'dependencies' => [
        'abstract_factories' => [
            \Zend\Log\LoggerAbstractServiceFactory::class,
        ],
    ],
];

Next we can add a top level log key to the configuration which the LoggerAbstractServiceFactory will reference to create and configure zend loggers.

// config/autoload/logging.global.php
return [
  'log' => [
    'StreamLogger' => [
      'writers' => [
        [
          'name'     => 'stream',
          'priority' => Zend\Log\Logger::DEBUG,
          'options'  => [
            'stream' => 'php://output',
          ],
        ],
      ],
    ],
   'dependencies' => ...
];

At this point you would think I could configure said library to pull this logger from the ServiceManager. Simply give it the service name 'StreamLogger'. However the zend loggers do not implement psr-3 and I would get an error due to incompatible dependencies.

zend-log comes with Zend\Log\PsrLoggerAdapter that is capable of wrapping a zend logger instance and is itself psr-3 compatible.

So I figured I could add a second service called PsrStreamLogger that would do just that and configure said library to use that service name instead.

PsrLoggerAdapter configuration

// config/autoload/logging.global.php
return [
    'dependencies' => [
        'abstract_factories' => [
            \Zend\Log\LoggerAbstractServiceFactory::class,
        ],
        'factories'          => [
            'PsrStreamLogger' => function($container) {
                return new \Zend\Log\PsrLoggerAdapter($container->get('StreamLogger'));
            }
        ],
    ],

    'log' => ...
];

Although this will work another approach is to use a delegator factory. This is a feature of the zend-servicemanager that enables it to decorate services with a different service via a factory. Here's a good article about it.

This is how you need to configure delegators;

// config/autoload/logging.global.php
return [
    'dependencies' => [
        'abstract_factories' => [...
        'delegators'         => [
            'StreamLogger' => [
                \My\Service\Log\PsrLoggerDelegator::class,
            ],
        ]
    ],

    'log' => [...
];

And here is my implementation of \My\Service\Log\PsrLoggerDelegator written in such a way it is backwards compatible with zend-servicemanager 2.

namespace My\Service\Service\Log;

use Interop\Container\ContainerInterface;
use Zend\Log\PsrLoggerAdapter;
use Zend\ServiceManager\DelegatorFactoryInterface;
use Zend\ServiceManager\ServiceLocatorInterface;

class PsrLoggerDelegator implements DelegatorFactoryInterface
{
    /**
     * @param ContainerInterface $container
     * @param                    $requestedName
     * @param callable           $callback
     * @param array|null         $options
     * @return PsrLoggerAdapter
     */
    public function __invoke(ContainerInterface $container, $requestedName, callable $callback, array $options = null)
    {
        return new PsrLoggerAdapter($callback());
    }

    /**
     * SM2 Compatibility
     *
     * @param ServiceLocatorInterface $serviceLocator
     * @param string                  $name
     * @param string                  $requestedName
     * @param callable                $callback
     * @return mixed
     */
    public function createDelegatorWithName(ServiceLocatorInterface $serviceLocator, $name, $requestedName, $callback)
    {
        return $this($serviceLocator, $requestedName, $callback);
    }
}

This approach allows you to continue using the log name you've configured, and just ensures that it is decorated as a PSR-3-compliant logger.

Final note: As you now you will get a zend-log Logger decorated with the PsrLoggerDelegator whenever you pull StreamLogger existing services that currently require Zend\Log\LoggerInterface might now be problematic. Since psr-3 is supposed to improve interoperability you are encouraged to change its dependencies to the psr-3 interfaces.

How do you write your own profile. Not sure, so I'll just start...

I am a loone wolf working as developer slash designer. Although I have a creative education as Interaction Designer and am still doing some design occasionally (user experience these days) I prefer to call myself a developer these days. It's where I feel most comfortable.

When Flash was still a thing, I liked to work with that. Thought that Flex was awesome, don't know how I could think that. Briefly had a startup called zillizi which created components for Flash. I did that with this guy.

Before that I made CD-Roms with Director but I won't try to explain what those are... :-)

These days I have a loose collaboration with these people.

Open Source

I like open source software. It has been a very beneficial to me in an educational sense. The first contributions I did were to a PHP framework called Binarycloud. It embraced OO when it became a thing in PHP and had great architecture. There are still some leftover references here and there.

Later I focussed on using Zend Framework and contributed a bit to Zend Framework 2.

Here are a few libraries I maintain and/or contribute to;

• BsbFlysystem
• SlmQueue, SlmQueueDoctrine
• BsbPostponableJobStrategy
• BsbDoctrineReconnect
• BsbDoctrineReconnect

Current Topic of interests

Domain Driven Design, CQRS and Event Sourcing. PHP and EmberJS

Project and Clients

I've worked on many projects and clients in the past, here are a few old and new...

• Sandalinos (dealer portal)
• Lumasol (360 player) / Lumasol (store)
• JuffrouwJansen (website)
• Roetz Bikes (commandline tool complementing their ODOO website)
• Nederlandse Beroepsvereniging van Film en Televisiemakers (iOS/Android App + backend)
• Podium voor Architectuur (project website)
• ManuManu (website)
• Wieden+Kennedy (website & internal media repository)
• Lammers BV (torenkraan registratie systeem)
• Carhartt (website)
• de Jazzserver (website)
• de Kamervraag (website)

Social

Twitter Github (basz) Github (bushbaby) LinkedIn
Stack Overflow
CoderWall

image attribution

As a freelance developer I work solitair a lot. I like it that way and working like that fits my personality. I probably need it.

However, it can be a bit Remi like at times. Therefore I decided I need to get out more and look for like minded people. I finally started to go to meetups, call those former colleagues and now I decided to restart blogging a bit.

Additionally I need to keep learning. I leech a lot and this might be my way of giving back. Hope it is helpful to someone...

Don't expect deep philosophical insights, those I won't share ;-) , but my intend is to write some random stuff about encountered development related issues. Sort of 'How did I do that again?' type of articles. As my current interests are lying with anything PHP and EmberJS chances are that's were I will go subject wise.

So, I hope you like it, thanks for listening. Or not, that's fine too!

image attribution