Jueves, Octubre 8, 2020

  • Uff, estuvo buenazo el libro Advanced Web Application Architecture. Lo estoy leyendo de nuevo, tomando notas y modificando mi arquitectura.
  • A pesar de mis esfuerzos por conciliar Laravel y Domain-Driven Development, he aceptado que luchar contra el framework es una batalla donde salir victorioso implica perder todas las ventajas del framework. Adoptaré algunos conceptos de DDD (e.g. Value Objects) pero sin pelear con el framework (Value Objects en Eloquent es no no no).
  • Ya no estoy usando Form Requests, no me gusta estar dependiendo de un paquete externo para hacer testing. Estoy manejando la validación de los datos del Request en una clase aparte. Manejaré la autorización con Middlewares, eso es algo que aún no he implementado.
  • Luego de muchas indecisiones sobre el namespace para el “core” de mi aplicación, ayer definí de una buena vez por todas y de manera irrevocable cuál sería. Long story short, es Domain. Ya no habrá más cambios. He dicho.
  • Y a pesar que me gusta el Command Bus, para no desviarme mucho del “standard” de Laravel, estoy usando Services, aunque he adoptado el nombre de Actions como los tíos de Spatie, siendo la razón de peso el diferenciarlos de los Domain Services.

Octubre 1, 2020

Me resulta más fácil escribir a lo Michael Meeks que concentrarme en un solo tema lo suficientemente interesante. Jamie Tanna tiene un estilo similar, publicando por semanas, pero yo estoy queriendo hacerlo más a menudo.

El único “problema” es qué título ponerle a mis posts. Por esta vez le pondré la fecha, como lo hacía aaaaaños atrás.

  • He terminado de migrar la parte pública de mi Journal Comic a Laravel.
  • Para implementar validaciones en un Value Object usé beberlei/assert, pero la API no era como lo recordaba, y la documentación no me era familiar. ¿Una nueva versión con BC break? Esa noche antes de dormir descubrí que la librería que yo había usado antes era webmozart/assert. Fue muy gracioso.
  • Y si tienen problemas como yo para hacer unit testing de Form Requests de Laravel, mohammedmanssour/form-request-tester es un excelente paquete que te alivia la vida. A veces la magia de Laravel complica demasiado las cosas.
  • En realidad, no ando muy convencido del concepto de Form Requests y la validación en general en Laravel. Ugh, necesito mi tech blog para explayarme. :)
  • Estoy leyendo ahora Advanced Web Architecture de Mathias Noback. Hasta ahora está buenazo. Tras leer tantos libros teóricos sobre DDD o que hablan aisladamente de conceptos de DDD, es genial tener un libro super práctico con código y situaciones del mundo real. Aún no lo he acabado, pero está muy, muy bueno.
  • La semana pasada Thalía y yo vimos The Old Guard. ¡Bastante entretenida! Thalía lo disfrutó más que yo porque no sabía nada de la trama, mientras que yo había visto el trailer mientras escogía qué ver.
  • Anoche vimos Enola Holmes. Me gustó mucho, sobre todo el color grading. Varios cuadros parecían pinturas. Cierto, tengo que buscar la bella música del tercer acto.
  • De la nada recordé la escena del tren de Super 8. El diálogo de Alice es genial.
  • Y llegamos a Octubre.

Fira Code, Miramare, Laravel y DDD

Oh, hey, me está gustando escribir a lo Michael Meeks, me hace recordar la vieja época de los blogs y los diarios en Advogato (que ya no existe, gasp!). Espero que algún día tomemos más consciencia sobre los peligros de las redes sociales y regresemos a los blogs y el control de nuestro contenido.

  • Oliver usa Fira Code como font de programación. Lo estoy probando también y me está gustando. No estoy convencido que los ligatures sea buena idea y Vim no los soporta de todos modos. Me gusta todo lo demás del font, especialmente el cero con slash (y no un puntito al centro como otros fonts). La Sinclair ZX81 tenía el cero así, y para mí es el “cero computadora.”
  • Tengo un nuevo colorscheme favorito de Vim, Miramare.
  • Estoy volviendo a leer la serie de blog posts de Brent Roose sobre proyectos grandes con Laravel y contrastándolo con la arquitectura que he armado yo. A diferencia de Brent, mis modelos son intencionalmente anémicos, porque es antinatural implementar un Domain Model usando objetos de Eloquent. He dicho.
  • Hace tiempo estoy queriendo crear un nuevo blog para escribir exclusivamente de cosas técnicas y programación. Como que ya debería darle prioridad, ¿verdad?
  • Y acabo de recordar que tengo en deuda escribir un blog post sobre qué me gusta de Laravel.

Devorando el manual de Laravel

Dediqué mi tiempo de lectura para devorar el manual de Laravel; me lo leí de principio a fin con el fin de tener un entendimiento en anchura (mas no en profundidad) del framework.

Lo leí en mi Kindle Paperwhite usando la versión Mobi de este repositorio: https://github.com/driade/laravel-book que genera ficheros ePub, Mobi y PDF actualizados del manual.

Tengo pendiente escribir acerca de las cosas que me gustan de Laravel, luego de haber escrito lo que no me gustó de Laravel ya tiempo atrás.

Lo que no me gusta de Laravel

He estado leyendo, probando y viendo un poco de cerca Laravel, buscando agilizar los desarrollos que hacemos en Nodos.

Estas son algunas cosas que no me han gustado de Laravel. Quizás en algunas esté equivocado, dado que sólo he construido algo pequeño con el framework para tener un hands-on experience y no tengo un conocimiento a profundidad de éste. Corríjanme si me equivoco.

NOTA: Al momento que escribo esto, la versión más reciente de Laravel es 5.6.

La magia

Este es un código de ejemplo copiado del manual de Laravel acerca de validación:

/**
 * Store a new blog post.
 *
 * @param  Request  $request
 * @return Response
 */
public function store(Request $request)
{
    $validatedData = $request->validate([
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ]);

    // The blog post is valid...
}

Lo que se puede ver es que hay una llamada a $request->validate().

Lo que no se ve es que si validate() encuentra contenido inválido, arroja una Excepción y se redirige automáticamente a la página anterior (con toda otra funcionalidad detrás de cámaras para preparar los errores y la persistencia de los valores antiguos).

Este comportamiento “mágico” no es visible ni intuitivo en el código, violando el Principle of Least Surprise. Solamente alguien con conocimientos de Laravel sabe lo que va a suceder.

Por otro lado, los Exceptions están siendo usados para controlar el flujo de la aplicación, lo cual es una mala práctica. Citando a Philip Brown:

An exception is basically an exceptional circumstance that is often unrecoverable from. This means something went wrong and we can’t proceed with running the application because the program is unable to carry on executing.

For example, I see a lot of code where the developer is using exceptions to control the flow of logic.

Exceptions should only be used in exceptional circumstances and therefore should be used sparingly.

Los famosos “Façades”

Mathias Verraes lo sabe decir mejor:

Laravel’s Facades have global state, which is precisely the thing you *shouldn’t* do. It is bad design and should be deprecated. They are nothing more than an elaborate $_GLOBALS.
(And they are a misnomer, as they are not Facades in the OOP meaning.)

Los formularios

Zend Framework 2 y 3 tienen Forms, que son colecciones de Form Elements con validación. Puedes crear nuevas clases de Form Elements como por ejemplo, “DNI” que incluye validadores, filtros, atributos, etc.
Laravel no tiene un concepto similar, estas funcionalidades están dispersas. Menos que eso, los helpers para renderizar los elementos de formulario fueron retirados del framework. No hay una base sobre la cual crear elementos reutilizables.

Service Container y PSR-11

Debido a requerimientos de clientes, en Nodos seguiremos usando tanto Zend Framework como Laravel. Revisando la interoperabilidad de Laravel en relación a su Service Container, veo que no se ajusta al PSR-11 — tampoco al ahora obsoleto container-interop.

Quizás tengamos que usar zend-servicemanager o algún otro Container PSR-11 para los Layers framework-agnostic.

Coda

Sobre el tema de la magia, cabe mencionar lo obvio: todo framework, por definición, trae consigo cierta medida de magia. Desde Rails, esto viene siendo un debate; y como ex-Rails developer, tengo tolerancia a cierta medida de magia pero ahora estoy gravitando más hacia lo explícito.

Hay “magia buena” (e.g. convention-over-configuration) y “magia mala” (e.g. leaky abstractions). La primera es aceptable, la segunda no.

Es mi sentir (y meramente mi opinión personal) que Laravel sacrifica mucho por darle prioridad al aspecto “beautiful code” y el “developer as an Web Artisan.” Para que Laravel pueda ser más interoperativo y desacoplado tendría que cambiar mucho estructuralmente, pero dudo que formen parte de las metas de Taylor Otwell. Mientras no pretenda convertirse en omakase, estamos bien.

Para equilibrar la balanza, en un próximo post haré una lista de las cosas que me gustan de Laravel.