Libro 13 del 2020: Advanced Web Application Architecture por Matthias Noback

Advanced Web Application Architecture es un excelente libro sobre arquitectura de aplicaciones web con PHP (aunque los principios pueden aplicarse en otros lenguajes).

Muchos libros o recursos sobre Domain-Driven Development o arquitectura de software explican conceptos aisladamente, y al ponerlos en práctica no queda claro cómo encaja todo. En este libro, Matthias Noback explica cómo todo funciona en conjunto usando ejemplos reales. Muchas preguntas que tenía encontraron respuesta y descubrí cosas que había entendido mal.

Cuando Matthias escribía sobre Excepciones, me preguntaba: “¿Las Excepciones no deberían ser para situaciones excepcionales?” Dos páginas más adelante, contestó exactamente esa pregunta. Es bien completo, bien escrito y bien organizado. Lo recomiendo bastante.

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.

Diciembre 28, 2010

Me desperté a las 6:50am, leí mi devocional en la cama y luego Dune. Me quedé nuevamente dormido hasta las 8:00am, grr.

Estoy escuchando el nuevo álbum de Gorillaz, The Fall, creado en su mayoría en un iPad. Revolving Doors es pegajosa, ya perdí la cuenta de cuántas veces la vengo repitiendo.

Sigo con el trabajo. Por primera vez he escrito documentación para Deborah, mi librería de abstracción de Base de Datos en PHP. Estuve buscando alguna clase o librería para tener algo más parecido al ActiveRecord de Rails, pero el tiempo nos gana. Al parecer las mejoras al código existente se van a dar lentamente. Tengo que tener pacieeeencia.

No perdamos el enfoque

Este es un extracto modificado y extendido de un, eh, desquite escrito en otro lado que no viene al caso mencionar. Es una lección que he estado aprendiendo últimamente y que estoy viendo repetirse a menudo y me encuentro a mí mismo diciendo la misma frase: “No hay que perder el enfoque.”

Muchas personas dicen entonces que eso no es “el standard de la industria,” o parte de las “mejores prácticas.” Y en repetidas veces esas cosas nos llevan erradamente a perseguir procedimientos o caminos en lugar de concentrarnos en resolver el problema.

“Hay que usar la mejor herramienta para el trabajo,” dice la sugerencia. Pero si tengo un apuro en abrir el case de mi computadora en una emergencia y lo único que tengo a la mano es un cuchillo y no un destornillador estrella, ¿adivinen qué es lo que voy a usar?

No, tonto. Tienes que conseguirte el destornillador estrella. Es el standard. Nos regimos y seguimos reglas sin entender el verdadero significado de por qué han sido definidas y la razón de su existencia.

Un extremo claro son los hospitales donde no te pueden atender a menos que llenes antes un formulario, porque “ese es el procedimiento.” Procedimientos, primero — el ser humano después. Se pierde el enfoque y la claridez de lo que se está haciendo, el objetivo que se quiere lograr; en el caso de un hospital, brindar atención médica a las personas.

Por supuesto, es otro gigantesco error irnos al otro extremo y decir que las reglas y procedimientos no sirven para nada e ignorarlos olímpicamente. Se llaman “mejores prácticas” por un motivo válido. Se establecen procedimientos por ciertas razones. Lo importante es entender y discernir el propósito de cada procedimiento y hacer lo correcto en cada caso.

Cuando perdemos el enfoque todo se viene abajo. Pensamos que el numerito obtenido de un examen determina la proficiencia de una persona en dicho curso y no es así. Pensamos equivocadamente que se puede representar la aptitud o inteligencia de una persona con un solo número y es una tontería.
Alabamos una buena nota y castigamos una mala nota sin discernir que es una mera figura, una representación pálida. Alguien con una plagia o una memoria fotográfica puede transcribir, palabra por palabra, lo que tiene y obtener una buena nota. Alguien que ha estudiado duro, pero que al final se llenó de nervios por la importancia que tiene pasar este curso obtiene al final una mala nota. No rindió al 100% de sus habilidades, no por su conocimiento, sino por un factor externo. Y no podemos decir “No sabe, no estudió, la nota baja lo demuestra,” porque es un estúpido escalar que no representa nada.

Y entonces aparecen los que se van al otro extremo y puntillean, ¿Significa eso que debemos de eliminar todas las notas? ¿Que el sistema no sirve y que no debemos basarnos en ello? Que no, carambas. Es necesario tener un punto de referencia, una manera de medir el aprendizaje — pero tomémoslo como tal, como una referencia.
“Veo que sus notas de colegio, estimado entrevistado, son deficientes. Es usted, pues, un bruto y no lo necesitamos en nuestra empresa.”
Ajá. El divorcio de mis padres durante esa época no tuvo nada que ver. ¿Qué tal si me hace un par de preguntas o me toma un examen de aptitud y vemos si, en la práctica, soy realmente útil para su empresa? ¿O si mira los proyectos que he estado haciendo?

Oh no, papelito manda.

El año pasado cuando entrevisté a personas buscando un programador me importó un comino o dos si venían vestidos en terno o en chancletas, si habían estudiado en La Católica o con su primo Juancito. A todos les hice las mismas preguntas y ninguno, NINGUNO, pudo completarme una tarea de programación. Mi elección se hizo en base a la forma cómo intentaron razonar para salir del apuro, porque lo que buscaba es alguien que sepa razonar, no que tenga las siglas “Ing.” delante de su nombre, sino alguien con aptitud, alguien con potencial y capacidad. No alguien que sepa “Java” y “PHP” porque nuestra industria se mueve tan rápido que “Java” y “PHP” van a ser obsoletos o desplazados de todas maneras.

Debemos de detenernos un momento a pensar y observar si estamos siguiendo reglas ciegamente o estamos usando la razón. Hace años atrás renuncié a un buen trabajo en Lima por la sencilla razón que ese trabajo se convirtió en todo y llegué al límite de querer abandonar por completo a mi Señor.
La incomprensión de personas no creyentes no me sorprendió — lo que me sorprendió fue la incomprensión de creyentes que consideraron “tonta” y absurda mi decisión. “¿Por qué un creyente no puede ser rico?” preguntó una creyente y es como si no hubiese entendido nada en toda su vida.
Su patrón de éxito estaba marcado por lo que el mundo dice y no por lo que Dios dice. Nuestra mira y nuestra meta es otra. Es tan desorientado como decir que lo más importante en el colegio es haber llenado la mayor cantidad de álbumes de figuritas que todos los demás en la historia del colegio. “¿Y por qué un alumno no puede tener la mayor cantidad posible de álbumes?”

Mi conclusión es: no debemos perder el enfoque del por qué de las cosas, del motivo y razón detrás de cada standard, cada regla, costumbre o procedimiento. No obedezcamos ciegamente las cosas porque “así son,” “siempre han sido así” y “los demás también lo hacen” sino usemos el razonamiento y la sabiduría para hacer siempre lo Correcto.

(Y lo Correcto en reiteradas ocasiones rompe las reglas.)