Hola Amigos del Rigor! Continuamos con la serie sobre Domain Events pero esta vez con un caso práctico de uso muy interesante para marcarse un tanto con negocio. Vamos a enviar los eventos de dominio contra un Elastic para que podamos finalmente agregar un Kibana y tener métricas en tiempo real de lo que ocurre en nuestra aplicación.

En este vídeo, vamos a configurar Kibana para montar gráficos y ver la información de los eventos que hemos enviado a Elastic de una forma que negocio flipe :)

Hola Amigos del Rigor! Continuamos con la serie sobre Domain Events pero esta vez con un caso práctico de uso muy interesante para marcarse un tanto con negocio. Vamos a enviar los eventos de dominio contra un Elastic para que podamos finalmente agregar un Kibana y tener métricas en tiempo real de lo que ocurre en nuestra aplicación.

En este vídeo, vamos a ver la cómo enriquecer el evento de dominio antes de enviarlo a Elastic. Agregaremos información sobre la request, memoria, etc. para traquear si algún servidor está procesando menos eventos de un cierto tipo.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Continuamos con la serie sobre Domain Events pero esta vez con un caso práctico de uso muy interesante para marcarse un tanto con negocio. Vamos a enviar los eventos de dominio contra un Elastic para que podamos finalmente agregar un Kibana y tener métricas en tiempo real de lo que ocurre en nuestra aplicación. En este vídeo, vamos a ver la segunda alternativa para enviar todos los eventos juntos de una vez, después de ejecutar el command handler. Reducimos números de peticiones mejorando el rendimiento.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Continuamos con la serie sobre Domain Events pero esta vez con un caso práctico de uso muy interesante para marcarse un tanto con negocio. Vamos a enviar los eventos de dominio contra un Elastic para que podamos finalmente agregar un Kibana y tener métricas en tiempo real de lo que ocurre en nuestra aplicación. En este vídeo, vamos a ver una de las alternativas para hacer esto, el envío síncrono a Elastic por cada eventos disparado.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Continuamos con la serie sobre Domain Events. En este sexto video de la serie, vamos a distribuir los eventos, que tenemos persistidos en base de datos, hacia un sistema de colas como RabbitMQ. Veremos algunas consideraciones y trucos a tener en cuenta.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Continuamos con la serie sobre Domain Events. En este quinto video de la serie, vamos a empezar a discutir manera de distribuir los eventos. El primer método es quizá menos conocido, REST. Veremos qué beneficios tiene y algunos trucos para implementarlo.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Continuamos con la serie sobre Domain Events. En este cuarto video, vamos a ver cómo implementar la persistencia de Eventos de Dominio, para qué es útil y cuáles son sus beneficios.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Continuamos con la serie sobre Domain Events. En este tercer video, veremos la segunda alternativa para disparar un evento de dominio: un publisher estático. Veremos sus puntos fuertes y flojos.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Continuamos con la serie sobre Domain Events. En este segundo video, veremos la primera alternativa para disparar un evento de dominio: acumularlos en la entidad. Veremos sus puntos fuertes y flojos.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Arrancamos una miniserie de videos sobre Domain Events. En este primer video, veremos cómo modelar un evento de dominio e introduciremos las diferentes manera de dispararlos. En los siguientes, veremos en detalle dichas alternativas, así como su relación con la persistencia y la distribución.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Perdonad por el retraso pero estuve preparando la certificación de AWS Certified Solutions Architect – Associate que al final conseguí la semana pasada.

En este video, vamos a continuar evolucionando los Command Handlers y su contexto de ejecución presentando el Command Bus. Veremos cuáles son sus objetivos y para qué nos resulta útil. Por último, hablaremos sobre Tactician.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Vamos con una entrega más. En esta ocasión, vamos a ver la diferencia entre Application Services y Command Handlers, así como algún truco sobre Command Handlers para decorarlos y facilitar tareas como el Logging o la gestión de Transacciones.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Después de explicar el principio de Tell-Don’t-Ask, continuamos con la serie de los videos de refactoring. En este video, vamos a ver cómo extraer dependencias como Loggers, Servicios para enviar notificaciones o similares usando una primera aproximación sencilla con un EventDispatcher.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Hacemos un parada en la serie de los videos sobre refactoring para explicar el principio de Tell-Don’t-Ask. Lo hemos ido utilizando en los videos anteriores pero no lo había presentado formalmente.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Seguimos con la serie sobre los videos de refactoring. Los Application Services deben coordinar pero no contener lógica de negocio. En este video, veremos varios trucos para mover la lógica de negocio del Application Service hacia Entidades y Repositorios.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Seguimos con la serie sobre los videos de refactoring. En éste, vamos a mejorar la calidad de los tests unitarios acabando de agregar assests que faltaban e introduciendo un Spy. Con esto, nos aseguraremos que aún teniendo 100% de cobertura en los tests, tenemos que esta atentos a invocaciones que no tienen retorno, como logging, notifiers, publishers de eventos, etc.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Seguimos con la serie sobre los videos de refactoring. En éste, vamos a acabar de testear por completo todo el Application Service del video anterior utilizando técnicas que vimos en los videos anteriores como Test Classes o Self-Shunt. En el siguiente video veremos cómo enriquecer nuestro dominio moviendo parte de la lógica a las entidades.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Seguimos con la serie sobre los videos de refactoring. En éste, vamos a testear parte del Application Service que extrajimos en el video anterior. Aprovecharemos para mejorar el código con algunos casos no contemplados en el código original.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Hoy es mi cumpleaños, 34 primaveras. He traído donuts a la oficina, pero como no podéis acceder a ellos :(, aquí os dejo un regalito para vosotros! Arranco una nueva serie de videos sobre Refactoring de código acoplado. En este video, vamos a ver cómo refactorizar código escrito directamente en el controlador web de cualquier framework donde se mezcla lógica de negocio y detalles de infraestructura.

Lo sacaremos a un Application Service, invertiremos todas las dependencias y lo dejaremos listo para poderlo testear.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Unit Testear nuestro código con un 100% de coverage no es suficiente. En este video, vamos a ver cómo aplicar “Mutant Testing” a nuestro código para mejorar la calidad de nuestros tests unitarios.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Continuamos con un video sobre inmutabilidad. Vamos a ver cómo poder hacer que nuestras clases, especialmente aquellas con las que modelamos Value Objects pueden ser inmutables.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Vamos a con el último de los tres videos sobre el patrón de testing “Self-Shunt”. En este video, veremos un truco muy sencillo para poder testear cadenas de invocaciones que incumplen la ley de Demeter.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Vamos a con el tercer de los cuatro videos sobre patrones de “Unit Testing”, especialmente, para código acoplado. En este video, veremos una implementación alternativa del “Self-Shunt” sólo para PHP7 usando clases anónimas.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Vamos a con el segundo de los cuatro videos sobre patrones de “Unit Testing”, especialmente, para código acoplado. En este video, veremos un atajo para implementar “Test Classes” usando un patrón conocido como “Self-Shunt”.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Vamos a arrancar un serie de 4 videos sobre patrones de “Unit Testing”, especialmente, para código acoplado. Aquí os dejo el primero.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Acabamos con la serie sobre “Named Constructors” con el último video de los cuatro. He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Seguimos con la serie sobre “Named Constructors” con el tercer de los cuatro videos. He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Seguimos con la serie sobre “Named Constructors” con el segundo de los cuatro videos. He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Vamos a arrancar un serie de 4 videos sobre “Named Constructors”. También conocidos como “Semantic Constructors” o “Constructor Methods”. Aquí os dejo el primero.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Espero que os guste!

#MayTheRigorBeWithYou

Os dejo por aquí, una de mis charlas impartida en la asignatura “Técnicas para el desarrollo de software en producción” dentro del Máster en Tecnologías Informáticas de la Universidad de La Rioja. Se grabó hace un año (26/11/2015), pero no lo había encontrado hasta hace unas semanas. Espero que sea útil.

Hola Amigos del Rigor! En este video voy a enseñar un ejemplo del concepto de “Self-Encapsulation” y la relación que guarda con las “Guard Clauses” que vimos en la Rigor Talk anterior. He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! En este video voy a enseñar lo que son las cláusulas de guarda y cómo ayudan a tener un código un poco más legible. He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Espero que os guste!

#MayTheRigorBeWithYou

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 ;)

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. 

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):

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?

Today, Keyvan, Christian and me are very happy to announce that “Domain-Driven Design in PHP” book is 100% complete. 380 pages and around 1400 readers so far.

Thanks

Thanks, thanks, thanks.

Thanks to everyone that has supported us in this project.

Thanks to Christian and Keyvan. We don’t need words to understand each other.

Thanks to our families and friends. Love is what you need to keep pushing.

Thanks to Edd Mann for helping at the beginning with the language implementation details ;).

Thanks to Matthias Noback for his suggestions and his foreword.

Thanks to Vaughn Vernon for being pragmatic and inspiring.

Thanks to Ricard Clau, Albert Casademont, Victor Guardiola and Jordi Abad for your contributions.

Thanks to Natalye Childress for non stopping asking about uppercase or lowercase. With your work, the book can be read.

Thanks to everyone that committed fixes, you are great: Jonathan Wondrusch, César Rodríguez, Yannick Voyer, Oriol González, Henry Snoek, Tom Jowitt, Sascha Schimke, Sven Herrmann, Daniel Abad, Luis Rovirosa, Luis Cordova, Raúl Ramos, Juan Maturana, Nil Portugués, Nikolay Zujev, Fernando Pradas, Raúl Araya, Neal Brooks, Hubert Béague, Aleksander Rekść, Sebastian Machuca, Nicolas Oelgart, and Marc Aube.

tl;dr: If you are sending messages to RabbitMQ to communicate one application to another, you are not doing Event Sourcing. You’re just doing messaging ;)

In the last two months, I’ve seen different nice talks using DDD, CQRS or Event Sourcing in the talk title. However, after watching the content, I think there are some general misunderstandings about some of the concepts. The most important one, in my honest opinion, is calling Event Sourcing to sending messaging to other applications using a broker. Event Sourcing is not about that. Let me explain a bit more.

This week, at Atrápalo, we have reviewed our autoloading Composer configuration to use PSR-4 and split production classmap from development classmap to save some space in our Opcache. The result, 500 Kbytes less. Let’s see some details.

With the Domain-Driven Design, Microservices and API explosion, I see more teams working in a base project, such as a Web, and integrating other private packages they develop in a different repository. For example, working on the Web and an API client for a external REST service at the same time.

For example, at @AtrapaloEng, our sales development team (checkout process, purchases, orders, payments, etc.) integrates different payment methods into the web so users, specially Latam ones, can be happier using their preferred payment methods. They create a repository for each of the new payment methods we support as a external package. Sometimes a developer in the team must work with different projects at the same time, the Web and the payment method in development.

In this scenario, one option is work on the payment package, tag, push, go to the base project and update dependencies with Composer. As you can see, it’s a bit slower, how we can improve this process? Composer to the rescue!

On Monday, Badoo blogged about its migration to PHP7 (https://techblog.badoo.com/blog/2016/03/14/how-badoo-saved-one-million-dollars-switching-to-php7/</a>). Those are great results! At @AtrapaloEng, we’re running already tests in production to perform the same step. We could have started some months before, but we’ve been struggling with the php-msgpack extension and its (un)support for PHP7. We hope to deploy PHP7 in all our server during this week but we would like to share with you what we have seen so far. What we have done is adding another FPM node with the same capabilities as the current ones running in production with PHP 5.6. The new node is getting the same amount of traffic as the other ones. No special configurations or tweaks such as Huge Pages, just PHP7 upgrade. Data after more than 24 hours running.

Cuando desarrollamos una aplicación nueva, todo va muy rapidito. Hay poco tráfico, pocas queries y si hay alguna más “dura” usamos alguna cache como Memcached o Redis. Pero a medida que agregamos más funcionalidad a una página, el número de queries a base de datos u otras infraestructuras va creciendo. Hasta que sin saber cómo, haces 300 queries, y no es broma, en la ficha de algún producto.

El problema es que estamos acostumbrados a hacer muchas queries de lectura y muy pocas de escritura en estructuras bastante normalizadas. Eso escala mal en base a nueva funcionalidad. Un buen approach en busca del máximo rendimiento es la consistencia eventual, estructuras desnormalizadas y proyecciones.

Os dejo el video de la formación de @AtrapaloEng sobre cómo el uso de Eventos de Dominio y el uso de conceptos de CQRS nos pueden ayudar enormemente a mejorar el rendimiento de nuestras aplicaciones.

If you’re developing applications in a Domain-Driven Design style and using Doctrine 2.5, you may be struggling with implementing your entities identities, I mean, UserId, ProductId, and so on. Embeddables are cool, but limited. Surrogates are not necessary anymore. Here are some short tips and examples about how to proceed.

Rascando por Youtube, encontré este vídeo de 2014, de una presentación que hice en LaSalle inspirada por otra que hice en Castellón en 2011. La idea es hacer un overview del ecosistema PHP y puntos importantes a la hora de montar un ciclo de desarrollo basado en esta tecnología. Que la disfrutéis.

For a long time, Capifony was, without any doubt, the facto option for deploying Symfony2 applications. Capifony is a ruby gem based in Capistrano v2, an open source tool for running scripts on multiple servers with a deployment flow built-in. It’s primary use is for easily deploying applications. While it was built specifically for deploying Rails apps, it’s pretty simple to customize it to deploy other types of applications. At that time, alternatives were shell scripting or Fabric. Now there’s a better one, Ansistrano.

Cuando trabajamos con aplicaciones DDD-style (aunque para las otras también aplica), una de las preguntas clásicas es como ejecutar tareas relacionadas con infraestructura desde las zonas más internas como Value Object o Entidades, sin violar la dependencias hacia capas superiores e incluso el SRP. Un ejemplo es logar información como acciones de usuario (tipo intento de acceso al sistema, alta de usuario, baja de usuario, etc.). El pasado Viernes, orientamos la formación de @AtrapaloEng sobre este tema. Os dejo el video y los ejercicios. Formación práctica basada en el proyecto de LastWishes con múltiples ejercicios resueltos in live coding.

A raíz del libro “Domain-Driven Design in PHP” y los videos que tengo en Youtube, semanalmente, me van llegando consultas sobre temas de relacionados. Son bastante interesantes y me gustaría compartirlas así como mis respuestas. A los autores de los mails les he pedido permiso para publicar la conversión. Las iré agregando en la medida que pueda. La primera es de Álex sobre Entidades, Identidad y UUIDs.

In the previous post, I talked about how to migrated to Symfony without pain using Apache Dumper. The idea was to generate Symfony routes in an Apache configuration file or .htaccess so it can be included in your virtual host. By including a fallback route to your current framework entry point, you can create new routes in Symfony without touching your previous framework. You can develop normally your new Symfony app, just defining new routes or the same old ones and regenerating the routes file.

This approach has some small pitfalls. Each time a new Symfony route is created, the Apache configuration file with the routes must be regenerated. If you’re creating many routes, this can be annoying. As explained in the previous post, there is another option that fixes this issue and have more features, Stack. Now, it’s like in Atrápalo, let’s see how it’s working.

Atrápalo is a travel e-commerce website founded in 2000. Based in Barcelona, Spain, it sells flights, trips, tickets, booking restaurants, car renting, etc. to 10 different countries. It’s a 9000 world Alexa ranking and it’s running PHP. Since 2014, we are pushing hard in order to evolve technically using best practices, agile methodologies and distributed architectures. One of the key aspects is the framework.

We are currently migrating to Symfony in order to speed up the development process and reduce the maintenance costs. We are doing it progressively, step by step, without rewriting the whole application, no green-field project, without any dedicated team neither. All developers are involved in this process, and by policy, each new feature is developed using Symfony while the old features remain served by the old framework.

I would say this process is going quite smoothly, without pain. Based on some emails and tweets I have received, here are some tricks about how we are doing it. Hope it helps!

It’s almost a year ago since I started working at Atrápalo. The team has done an amazing job learning and applying all the changes in our software development process including the new architecture, testing practices, Scrum changes, branching strategy, releasing process, bugfixing, and so much more. Changing the way ourselves work is probably the most difficult part from a “status quo” change.

I will like to thank everyone in the team that has done the effort to make it possible. I know it’s not easy and sometimes not fun at first. There is still so much to do and 2015 is going to be even so much funnier. Following, there are just some figures about 2014. Thanks to the Atrapalo Team.

On January, 31st, I was in the Barcelona PHP Day. Albert Casademont (@acasademont) was giving his talk about PHP 7. He talked about features, benchmarks and internals. He said that he was subscribed to the PHP Internals mailing list and I thought that more developers should too. However, it’s not so easy to get there.

Siguiendo con la formación de DDD en Atrápalo, os dejo la sesión de formación sobre Code Structure and Application Services. Que la disfrutéis.

Siguiendo con la formación de DDD en Atrápalo, os dejo la sesión de formación sobre Domain Events y BC Integration. Que la disfrutéis.

Os dejo el video de la charla que impartí el pasado 25 de Octubre de 2014 en la Barcelona Software Craftsmanship.

Siguiendo con las formaciones de DDD de Atrápalo, os dejo el video sobre Entities y Value Objects.

En Atrápalo, estamos haciendo formación semanal sobre DDD. Estoy grabando todos los screencast y los iré publicando semana a semana. El primero sobre Strategical no lo pudimos grabar pero gran parte del contenido lo podéis encontrar en la sesión que grabé en la Monthly Talk en Octubre de 2014. A continuación, os dejo la sesión de formación sobre Aggregates, al final hay discusión sobre SOLID, especialmente SRP. Que la disfrutéis.

Os dejo el video sobre DDD Tactical Design que hice en la Monthly Talk de PHPBarcelona. Nos dio tiempo a charlar un poco de estrategia, ver los Value Objects, Entities y algo de Repositories. La charla está basada en el libro que Christian, Keyvan y yo estamos escribiendo en leanpub: “Domain-Driven Design with PHP by Examples”. En los últimos 30 minutos hablo sobre cómo estamos gestionando la Integración Continua en Atrápalo.

This week, the php|architect magazine has published an article of mine about “Hexagonal Architecture with PHP”. Here’s the introduction:

“With the rise of DDD (domain-driven development), architectures promoting domain-centric designs are becoming more popular. This is the case with Hexagonal Architecture, also known as Ports and Adapters, that seems to have been rediscovered recently by PHP developers. Invented in 2005 by Alistair Cockburn, one of the Agile Manifesto authors, the Hexagonal Architecture allows an application to be equally driven by users, programs, automated tests, or batch scripts, while being developed and tested in isolation from its eventual run-time devices and databases. This results in infrastructure-agnostic web applications that are easier to test, write, and maintain. Let’s see how to apply it using real PHP examples.”

I would like to share with you some thought, the cover and the code repository.

(Next: Legacy Code and Teams Series: Composer)

When talking with some friends about how we are improving Atrápalo legacy code and development process, they asked for creating a presentation and give a talk about the steps we are following, hows, whys, and so on. It sound to me interesting so I would like to help sharing my experiences, not just the Atrápalo ones because when working at Emagister we did something quite similar with Christian, Eber, Dario, Lluís, Jordi, Jose Luís and the rest of the team with great results.

Before jumping into a talk, I would like to start a serie of posts about my way dealing with legacy projects. I’m really interested in listening from you and your comments in order to enrich the final result. So, any suggestion or experience is really welcomed.

Last month, in the PHP Barcelona Monthly Talk, I was talking with some mates about the GitHub migration we have recently done at Atrápalo. They were interested in branches, deployments, code reviews and so on. However, they were specially surprised about who we are dealing with pre-commit hooks at Atrápalo. Let’s see if there’s more people out there interested in the subject.

El pasado día 28 de Mayo, participé en Smash Tech como ponente impartiendo una master class de 2 horas sobre el ecosistema PHP y en lo que se debe prestar atención para el 2015. Con los 50 asistentes que pagaron la entrada, repasamos desde Metodologías de desarrollo: Agile, Scrum y Extreme Programming. Sobre ésta última pivotó la gran mayoría de la presentación, viendo cómo se resuelven las dinámicas de TDD, Integración Continua, Coding Standards, etc.

Estos días he estado haciendo entrevistas a muchos perfiles. Por si no lo sabéis, en Atrapalo, tenemos unas 15 posiciones abiertas para incorporar desarrolladores PHP de todos los perfiles, juniors y seniors con muchas ganas de pasárselo bien, aprender y aportar a un equipo que encara una nueva etapa excitante. Durante estas entrevistas, me he encontrado con desarrolladores cuyas circunstancias les han llevado a trabajar sólo en start-ups (“don’t worry be crappy”) o pequeñas empresas (“long live wordpress, drupal y joomla”), este post, con todo el cariño, es para ellos y su futuro.

Something a bit annoying when doing a kata is setting up the environment so you can start. Typically, you need composer, define dependencies, setting up the autoloading policy, creating some folders and so on. All this work is not necessary anymore. I have created a silly but useful project in packagist in order to start with your kata in just one command.

Last week, I was with some friends and we were talking about fluent interfaces and I show them something that they didn’t know. I got surprised about it because it was introduced in PHP 5.4.

If you are not using any PHP opcache accelerator, you should. If you are using APC, you should move to OPCache. If you are already using it, you should use opcache-dashboard also.

When contributing to opensource code at GitHub, I found some mistakes, or improvements when writing code, that are repetead over and over again for newbies and not so newbies developers. I’ll try to write some posts about this, but for not, let’s start with some “if” and “return” statements cases.

I’d like to know how you test your traits and what’s your favourite way to do it. I have found two different approaches that I want to share with you. Please comment if you apply different techniques or have different opinions.

When a project gets bigger, specially when using a framework, it’s mandatory to have some processes that help you in removing code that is not used anymore such as models, classes, template files, etc.

That is not an easy task, however the benefits or removing non used coded are tons (code coverage, development speed, bugs, etc.). But what’s the best approach to detect that a template file is not used anymore in your PHP project?

During the PHP Barcelona Conference 2010, Enrico Zimuel and me prepared a presentation about a demo on the Zend PHP 5.3 Certification with the support of Zend Europe. Today, we are celebrating more than 20.000 views at Slideshare.net. Thanks to everyone!

Packagist is a Composer package repository. It aggregates all sorts of PHP packages that are installable with Composer. You can use Composer to manage your project or libraries’ dependencies. Read more at http://packagist.org</a>.

**

Os dejo un material de hace un tiempo (16 de mayo de 2011) pero todavía bastante válido.

Como me gusta decir, PHP es fácil de aprender y difícil de dominar. Es una de las opciones más rápidas y efectivas para la creación y mantenimiento de aplicaciones web de todo tipo. Su simplicidad es la ventaja tecnológica #1 que tiene sobre sus principales competidores aunque no implica que su uso sea sólo orientado al desarrollo de aplicaciones simples. Con PHP podemos crear sistemas avanzados y potencialmente muy complejos. Para poder garantizar la escalabilidad de estos últimos necesitamos un ciclo de desarrollo y un equipo técnico alineado para hacer más con menos. En esta ponencia, vamos a repasar las características principales de PHP y cómo mejorar nuestro ciclo de desarrollo a través de herramientas y buenas prácticas.