#MayTheRigorBeWithYou: Presentamos las “Rigor Talks”


Amigos del rigor! Hola! Siguiendo la senda de los más grandes como CleanCoders.com o CodelyTV a.k.a. #cosaMuyFina, tengo el placer de presentaros las “Rigor Talks”. Videos cortos de entre 5 y 10 minutos, en Español, que iré publicando de forma periódica con aquellos trucos sobre desarrollo de software que veo que se repiten en las consultorías que hago por esos mundos. Los videos están hechos con todo el cariño y amor para que os resulten útiles en vuestro día a día.

A fecha de hoy, tengo 12 ya grabados que iré publicando en YouTube y en el blog de forma regular. Para muestra de los primeros videos que iremos publicando (Guard Clauses, Self-Encapsulation, Named Constructors, Test Class, Self-Shunt, Inmutabilidad y Mutant Testing). Os dejo una imagencilla ;) Continue reading

Firing Domain Events in the __constructor


After my post about “Good ORMs do not call __construct a.k.a. where to fire my Domain Events”, nice discussions (and trolling) are happening in the Barcelona Engineering Slack Channel. Thanks to everyone for the feedback, ideas and concerns. You are more than welcome! The main concerns are:

  1. How do I fetch an Entity from ElasticSearch, using new and without firing the Event?
  2. How do I create stubs on the Entity that is firing the Domain Event?
  3. What are pros and cons of firing the Domain Event in the __constructor or in the named constructor?

So, I’ll take the original code as a starting point, and I’ll suggest different strategies to answer those questions.  Continue reading

Good ORMs do not call __construct a.k.a. where to fire my Domain Events


tl;dr: Entity constructor should be called once in its entire life. That’s why good ORMs don’t use constructor to reconstitute objects from the database. Good ORMs use reflection, deserialization or proxies. So, fire your Domain Events in the constructor.

Last week, I saw a presentation about going from coupled-to-framework code to a Domain-Driven Design approach in a sample application. It was a good talk. However, in my honest opinion, there were some mistakes that are important to address. In order not to troll, I have checked with the speakers to write this post ;).

One of the mistakes, that I would like to point is where a Domain Event about “a new product was created” should be trigger specifically inside the Product Entity.

Speakers were showing a “Video” Entity with a named constructor called “create”. They were calling new inside the named constructor and then firing the event. I mean, the Domain Event was not fired inside of the real constructor. Let’s see the code we’re talking about (the whole repository can be found here): Continue reading

Awesome two days helping @Lowpost_es team


I have recently visited Valencia in order to help my friends at Lowpost. It was great and I had a lot of fun! I would like to tell you a bit about how it was.

Who is Lowpost?

Lowpost is a cool start-up that are focused in Content Marketing. Lowpost connects companies that need interesting content with authors that can write about such topics. Authors bet for the open jobs and then they deliver the content to the final customer. Everything around such process is managed by the Lowpost platform.

As a start-up, they have grown quite fast, so their code. They started with Drupal, as many start-ups, and then they added a Silex application. You know that testing is difficult, however, doing unit testing for Drupal is a challenge.

What we did?

Continue reading

Accessing securely production services with SSH port forwarding


We’ve already talked about how to deploy your public SSH keys into your server using Ansible and GitHub. This time, I just want to share a simple approach to have access to your production services (MySQL, Elastic, RabbitMQ, etc.) without exposing publicly your services. You have different alternatives, probably the most common are using a VPN or use SSH port forwarding. Let’s see an example of the last one.

Continue reading