DEV Community: Javier Ledezma

"Controladores delgados, modelos delgados", modelos de Laravel mantenibles.

Javier Ledezma — Fri, 07 May 2021 06:01:09 +0000

¿Alguna vez has escuchado la frase "Modelos delgados, Controladores gordos"?

Hablando en una arquitectura Modelo, vista, controlador (MVC), la frase se refiere a una filosofía cuyo objetivo es delegar mayor responsabilidad a los controladores e intentar dejar los modelos con la menor cantidad de líneas posibles.

Al igual que esta filosofía, también existe su contraparte: "Modelos gordos, Controladores delgados" que como imaginarás, se refiere a la filosofía de delegar mayor carga a los modelos e intentar dejar los controladores con la menor cantidad de líneas de código

Esta última ha sido adoptada por múltiples frameworks populares, ya que la mayoría de ellos cuentan con un ORM (Object-Relational Mapping) que permite explotar de manera muy práctica la base de datos. Un ejemplo de estos frameworks, cuyo ORM es una de las características más fuerte, es Laravel.

Gracias a las características de Laravel, en los modelos solemos mapear la tabla de la base de datos, definir relaciones, colocar accesores, modificadores, eventos, colecciones, alcances, etc... Teniendo al final clases enormes y poco mantenibles.

El objetivo de Laravel no es precisamente que los modelos sean poco mantenibles, simplemente se brindan las herramientas para volverlo muy práctico. Aquí es donde comienza nuestra labor como desarrolladores de software al ejercer las mejores prácticas para no llegar a ese punto.

Primero que nada, debemos entender que "modelo" no es sinónimo de "lógica de negocio". Un modelo es la representación abstracta de un objeto de dominio, toda la lógica de negocio debe ser manejada por otras clases, pudiendo ser "servicios" o "acciones". Entender esto es crucial para poder comenzar a delegar responsabilidades a clases independientes.

La idea en general de mantener modelos mantenibles en Laravel, es mantener el mapeo de la base de datos, definición de relaciones, casteos y accesores simples que no requieran cálculos.

Delegando queries a un QueryBuilder personalizado.

Si requerimos crear fragmentos de query que puedan ser frecuentemente utilizados, también conocidos como "scopes", laravel nos provee una forma de hacerlo en 2 sencillos pasos:

Crear una clase que extienda de Illuminate\Database\Eloquent\Builder en dónde vivirán todos los queries reutilizables necesarios para el proyecto.

    namespace App\QueryBuilders;

    use Illuminate\Database\Eloquent\Builder;

    class UserQueryBuilder extends Builder
    {
        public function whereActive(): self
        {
            return $this->where('status', User::ACTIVE_STATUS)
        }
    }

Indicar en nuestro modelo que utilice el Builder que acabamos de crear.

    namespace App\Models;

    use  App\QueryBuilders\UserQueryBuilder;

    class User extends Model
    {
        public function newEloquentBuilder($builder): UserQueryBuilder
        {
            return new UserQueryBuilder($query);
        }
    }

De esta manera, Laravel sabrá que debe utilizar nuestro Builder personalizados y podremos hacer uso de él cuando sea necesario, ejemplo:

User::whereActive()->get();

Moviendo colecciones a Collection personalizada.

Si la intención es utilizar las colecciones para manipular y/o filtrar datos, Laravel nos provee la facilidad de utilizar colecciones personalizadas, nuevamente en 2 pasos:

Crear una clase que extienda de Illuminate\Database\Eloquent\Collection en el que colocaremos todas las funciones relacionadas a la colección.

    namespace App\Collections;

    use Illuminate\Database\Eloquent\Collection;

    class UserCollection extends Collection
    {
        public function active(): self
        {
            return $this->filter(fn (User $user) => $user->email_verified_at !== null);
        }
    }

Indicar en nuestro modelo que la colección por defecto será la clase que acabamos de crear.

    namespace App\Models;

    use  App\Collections\UserCollection;

    class User extends Model
    {
        public function newCollection(array $models): UserCollection
        {
            return new UserCollection($models);
        }
    }

Nuevamente, al hacer ésto podremos hacer uso de una maner más fluida y sin cargar demasiado nuestros modelos. Ejemplo:

User::all()->active();

Delegando lógica de eventos

Uno de los mecanismos más importantes a la hora de delegar responsabilidades, es utilizar eventos y subscriptores para llevar a cabo aquellos procesos de "efecto secundario". Por default, los modelos de laravel son capaces de emitir eventos genéricos en diversas acciones, como al ser creados, modificados o eliminados. Nosotros podemos tomar ventaja de estos para mantener nuestros procesos aislados.

La manera de lograrlo es a través de 4 pasos:

Crear un evento que funcionará como DTO, regularmente transportará el modelo afectado.

       namespace App\Events;

       use App\Models\User;

       class UserSavingEvent
       {
           public User $user;

           public function __construct(User $user)
           {
               $this->user = $user;
           }
       }

Crear un subscriptor para dicho evento, nótese que la definición de qué evento se escucha se encuentra en el método subscribe:

       namespace App\Subscribers;

       use App\Events\UserSavingEvent;
       use App\Services\NotifyUserCreation;
       use Illuminate\Events\Dispatcher;

       class UserSubscriber
       {
           private NotifyUserCreation $notifyUserCreation;

           public function __construct(NotifyUserCreation $notifyUserCreation)
           {
               $this->notifyUserCreation = $notifyUserCreation;
           }

           public function saving(UserSavingEvent $event): void
           {
               ($this->notifyUserCreation)($event->user);
           }

           public function subscribe(Dispatcher $dispatcher): void
           {
               $dispatcher->listen(
                   InvoiceSavingEvent::class,
                   self::class . '@saving'
               );
           }
       }

Ahora debemos registrar al suscriptor dentro de nuestro EventServiceProvider

       use App\Subscribers\UserSubscriber;

       class EventServiceProvider extends ServiceProvider
       {
           protected $subscribe = [
               UserSubscriber::class,
           ];
       }

Finalmente debemos indicarle a nuestro modelo, en la propiedad $dispatchesEvents aquellos eventos que queremos despachar:

       use App\Events\UserSavingEvent;

       class Invoice extends Model
       {
           protected $dispatchesEvents = [
               'saving' => UserSavingEvent::class,
           ];
       }

Esta solución parece un poco larga, sin embargo, es muy escalable, si en algún momento se requiere quitar o agregar funcionalidad, nuestro Modelo se va a ver afectado en menor escala. Además separaremos toda aquella lógica en Subscribers separados, haciendo piezas más pequeñas y mantenibles.

Conclusión

Aunque realmente no parezca de gran impacto, comenzar a delegar responsabilidades de los modelos a clases con responsabilidades únicas nos va a ayudar a mantener nuestros modelos delgados y nuestro código en general mantenible. Y si seguimos con la idea de encapsular lógica de negocio en "servicios" o "acciones", podemos concluir que lo ideal es tener "controladores delgados y modelos delgados".

En este post hablamos de Laravel en particular, sin embargo, estoy casi seguro de que los frameworks en general tienden a brindar características para que desarrollemos software a toda velocidad, sin embargo, es necesario detenernos a pensar si vale la pena sacrificar practicidad por calidad.

Te invito a que pongas en práctica estas maneras de optimizar tus modelos y si vienes de un lenguaje o framework diferente, compártenos de qué manera solucionar estos problemas.

Hasta la próxima.

¿Es Laravel un aliado de software mantenible de gran escala?

Javier Ledezma — Sun, 14 Mar 2021 20:01:28 +0000

Introducción.

Laravel es un frameworks de desarrollo ágil que te permite desarrollar código a muy buena velocidad y centrado en el requerimiento gracias a las características "out of the box" que provee, desde base de datos, email, eventos, jobs/qeues, testing, entre otros.

En este blog analizaremos que tan buen candidato es Laravel respecto a las buenas prácticas y principios de programación como lo son DDD, arquitectura hexagonal y principios SOLID.

Estado de Laravel en cuanto a arquitectura hexagonal.

La arquitectura hexagonal es una forma de diseñar software por capas, se podría resumir en algo similar a lo siguiente:

Dominio (Lvl 1) <- Aplicación (Lvl 2) <- Infraestructura (Lvl 3)

La capa de dominio hace referencia a una esfera de conocimiento, en otras palabras, esta capa se centra en definir y/o conceptualizar toda la lógica de negocio.

La capa de aplicación, por su parte, concentra la manera de interactuar entre los usuarios y/o clientes con toda la lógica de negocio (dominio).

Finalmente, la capa de infraestructura se refiere a todos los elementos externos que son necesarios para desarrollar software que no están directamente relacionados con el dominio, por ejemplo: servidores, bases de datos, incluso software o librerías de terceros.

La única regla estricta en la arquitectura basada en capas es que las capas menor nivel no pueden utilizar capas de mayo nivel. Esto quiere decir, por ejemplo, que la capa de dominio puede utilizar la capa de dominio, pero no puede saber de la existencia de la capa de aplicación ni de infraestructura.

La capa de aplicación puede utilizar elementos de la capa de aplicación y dominio, pero no puede saber de la existencia de elementos de la capa de infraestructura. El mismo caso para la capa de infraestructura...

Retomando el tema, Laravel sacrifica un poco los principios de la arquitectura en capas para brindar practicidad. El ejemplo más claro que tenemos es Eloquent, el ORM por defecto de Laravel, permite ejecutar operaciones CRUD a una velocidad increíble, sin embargo, la definición del modelo pertenece a la capa de dominio, y la conexión con la base de datos a la capa de infraestructura.

Estado de Laravel respecto principios SOLID.

Laravel, al igual que la mayoría de frameworks vienen con una serie de lineamientos que se consideran buenas prácticas, en este caso, conocido como "the laravel way". Y aunque la misma documentación busca que se implementen buenas prácticas de desarrollo, existen prácticas que podrían mejorar el desarrollo de aplicaciones con Laravel.

Un ejemplo de esto es el caso de los modelos, actualmente los modelos en Laravel se utilizan para mapeo de datos, pero no solo eso, en ellos recaen responsabilidades de serialización, notificaciones, etc...

"The laravel way" recomienda delegar aún más responsabilidades a los modelos con query builders, colecciones, entre otras. Sin embargo, el framework brinda todas las herramientas para abstraer estas funcionalidades en clases concretas con responsabilidades únicas, pueden verse más detalles de cómo mejorar la calidad del código en el libro/curso Laravel Beyound CRUD.

Estado de Laravel respecto a DDD.

Domain Driven Design (DDD) se define como una serie de principios cuyo objetivo es desarrollar software mantenible y agnóstico a frameworks usando como base principios SOLID y arquitectura hexagonal.

Para aplicar principios DDD en Laravel será necesario realizar algunos ajustes en cuanto a las convenciones de escafolding para separar el código en capas y mantenerlo organizado respecto a responsabilidades, pero es totalmente factible.

En este sentido, Laravel actúa a nivel de aplicación e infraestructura, brindando mecanismos sencillos y eficientes respecto a ruteo, middlewares, controllers, comandos, etc. Por lo que debemos centrarnos en abstraer la capa de Dominio con toda la lógica de negocio y de esta manera cumplir el propósito general de DDD.

Conclusión.

Laravel es un framework estupendo, uno de los mejores en cuanto a practicidad y más completo en cuanto a características. Siempre busca que los desarrolladores implementen buenas prácticas, aunque en su núcleo algunas de estas prácticas se sacrifiquen para lograr esta facilidad y agilidad de desarrollo.

Respecto a las herramientas de Laravel que violan algunas reglas de arquitecturas limpias o en capas, pueden ser encapsuladas para evitar este tipo de inconvenientes, sin embargo, será necesario evaluar si es totalmente necesario dependiendo de la magnitud y alcance del proyecto final para no caer en sobre ingeniería.

Lo importante del desarrollo de software es crear código funcional, mantenible y de fácil crecimiento, no es necesario implementar DDD en todos los proyectos incluso, se podría implementar parcialmente dependiendo de la complejidad, pero entre más grande y complejo apegarse a estos principios facilitarán el ciclo de desarrollo del producto.

Recuerda que todo comentario en bienvenido y si consideras que el contenido puede ser mejorado siéntete libre de expresarlo en comentarios.

Hasta la próxima.

Entornos de desarrollo de software con Windows

Javier Ledezma — Sat, 28 Nov 2020 15:53:42 +0000

Si bien es cierto que los sistemas con base UNIX han demostrado ser los sistemas operativos más confiables para desarrollo de software, es muy cierto que Windows ha hecho un gran esfuerzo por posicionarse de buena manera. Y aunque siempre ha existido soporte para desarrollar con la mayoría de las tecnologías, teníamos ciertas desventajas como la dificultad para trabajar proyectos con diferentes versiones de tu lenguaje favorito (ya que cada versión tiende a venir con su propio ejecutable) y en ciertas ocasiones el rendimiento (dependiendo de las alternativas que utilizaramos).

Por ejemplo, una de las opciones a las que solíamos recurrir para solucionar este problema era virtualizar aquellos entornos de desarrollo, como lo son VirtualBox o VMware, sin embargo, solía ser muy costoso en recursos y seguíamos teniendo el problema de rendimiento.

Ante todo esto surgió la tecnología Windows Linux Subsystem (o WSL) quién haciendo uso de Hyper-v logró crear una capa que podía correr aplicaciones para linux de manera nativa, sin embargo, esto no se trataba más que emular un subsistema de linux en nuestro sistema operativo y teníamos ciertas limitantes de compatibilidad y también de rendimiento.

Cuando surgió la segunda versión de WSL estos problemas dejaron de existir, ya que realmente utiliza el núcleo de linux como base, haciendo posible el uso total de las características de shell y mejorando por mucho los temas de rendimiento en cuanto escritura y/o lectura, con la única desventaja de tener que mover todos nuestros archivos al sistema de directorios creado por el propio WSL.

La principal ventaja que trajo WSL2 fue su alta compatibilidad con docker y es que estas herramientas en conjunto resuelven la mayor parte de los problemas que teníamos, nos permiten ejecutar contenedores con las tecnología que necesitemos sin sacrificar el rendimiento.

Lo que es muy cierto es que WSL2 en conjunto con docker puede requerir ajustes adicionales para lograr configurar al 100% tu entorno de desarrollo habitual, algo con lo que yo tuve problemas, fue configurar un debugger y ciertamente hay poca información al respecto, sin embargo, espero que con el tiempo uso de estas tecnologías siga incrementando y con ello el soporte para la comunidad.

Conclusión

Si eres desarrollador y por alguna razón sigues pensando que windows no es una opción, te invito a que pruebes WSL2, no es una experiencia igual a trabajar sobre linux nativo, pero sin duda es una experiencia satisfactoria y te permitirá tener aquellos ejecutables que tristemente no eran compatibles con sistemas linux.

Si ya tuviste experiencia utilizando WSL2 cuéntanos en los comentarios qué te ha parecido, o si tienes algún comentario o sugerencia, siempre son bienvenidos.

¡Hasta pronto!

Domain Driven Design (Parte 1: Dominio)

Javier Ledezma — Sun, 27 Sep 2020 23:18:23 +0000

Dado el increíble crecimiento tecnológico de los últimos años, el desarrollo de software se ha visto forzado a evolucionar muy rápido, con ello, nacieron frameworks y librerías que nos permitían crear aplicaciones a velocidad increíble en en todos los ramos posibles, desde aplicaciones móviles con ambientes híbridos hasta librerías de Machine Learning e inteligencia artificial. El desarrollo web no es la excepción, existen múltiples herramientas que te permiten crear aplicaciones desde frontend (cómo react, vue o svelte), backend (como laravel, spring, rails o django) o aplicaciones fullstack en tiempo real (como metheor o express + socket.io).

Todo parece ser muy bueno hasta que llegamos al punto de mantenibilidad, cuando necesitamos crear un producto cuyo ciclo de vida es para mucho años, en este caso, nos veremos afectados por diversas cuestiones: haciendo énfasis en la parte técnica, nos encontrarnos con actualizaciones del framework, dependencias e inclusive actualizaciones del lenguaje mismo, haciendo que el desarrollo del producto se prolongue demasiado y afectado directamente en los costos del desarrollo.

Para solucionar este tipo de problemas existen arquitecturas que intentan separar lo más posible las dependencias del proyecto de los requerimientos del mismo, tal es caso de Domain Driven Design (o DDD).

Ahora bien, DDD se basa en tres principales capas, Dominio, Aplicación e Infraestructura (Puede haber variantes muy pequeñas). En esta serie de posts intentaré explicar en qué consiste DDD comenzando por la capa de dominio.

Dominio

La capa de dominio es en núcleo de DDD, en ella se contienen todas las clases que "modelan" a los componentes del sistema, por ejemplo, la clase Usuario, Producto, Precio, entre otros y también en la capa de dominio se crean aquellos contratos (interfaces) que deben ser seguidos por los nuestras fuentes de datos (repositorios).

Entidades y objetos de valor

Hablado de las clases base, tenemos 2 posibles variantes, Entidades y Objetos de valor:

Entidades: Representan un objeto clave de nuestra aplicación, como lo puede ser un Usuario, las entidades tienden a mutar a lo largo del tiempo y tienen un grado alto de persistencia en las bases de datos, la principal característica de las entidades, es que tienden a tener un identificador.
Objetos de valor: A diferencia de una entidad, un objeto de valor es inmutable, regularmente se utilizan para crear propiedades de una entidad, por ejemplo, si se tuviera nuevamente la entidad Usuario, cuyo id es único, el id puede ser considerado como un objeto de valor, dado que nunca va a cambiar a lo largo de todo el ciclo de vida del software.

Nota: Es importante mencionar que las clases que representan entidades y objetos de valor, pueden cambiar de postura dependiendo del proyecto y el requerimiento, por ejemplo, en algunos sistemas, las direcciones postales pueden ser una entidad y en otros simplemente una propiedad de una entidad (objeto de valor).

Agregados

Otro concepto muy importante dentro de la capa de dominio son los agregados, un agregado es una referencia a un grupo de objetos de dominio, un ejemplo muy práctico en un e-commerce es una Orden o Pedido, el cual se compone de una serie de Artículos (en dónde un Articulo es una entidad).

El objetivo de un agregado es poder crear transacciones sobre ese grupo en concreto de entidades u objetos de valor, en dónde, regresando al ejemplo del Pedido, podríamos aplicar un descuento sobre el total o sobre ciertos productos si se cumplen ciertas condiciones.

Es importante no confundir un agregado con una colección, los agregados están dirigidos por conceptos clave de dominio, mientras que una colección siempre es genérica.

Repositorios

Un repositorio es un contrato en el cual establecemos aquellos métodos que necesitemos para obtener/persistir los datos de nuestra aplicación.

El objetivo de crear un repositorio dentro de la capa de dominio es mantener el control de todo lo que necesitamos independientemente de la fuente de datos que utilicemos, de esta manera si utilizamos MySQL, Oracle, MongoDB, Firebase o filesystem o incluso todas en conjunto, la aplicación seguirá funcionando, y si en algún futuro necesitamos reemplazar alguna fuente o motor de DB, esto no involucra cambios en la capa de dominio, ni siquiera en la capa de aplicación, solo se creará la nueva implementación en la capa de infraestructura siguiendo contrato y asunto resuelto.

Fábricas (Factories)

Las fábricas son clases que nos permiten crear instancias de nuestras entidades, objetos de valor o agregados basadas en diversos parámetros y condiciones, de este concepto en general existe mucha información, por lo que no haré tanto énfasis.

Evento de dominio

Un evento es una forma de comunicar que alguno de nuestros elementos de dominio ha tenido cierto tipo de interacción, los eventos pueden ser de muchos tipos, desde la creación de una instancia, la persistencia de la misma, la modificación de alguna propiedad, etc. El objetivo de los eventos es notificar a toda la aplicación con el fin de que se propaguen tantas acciones en consecuencia sean necesarias.

Para sacar el máximo provecho de un evento se requiere de escuchadores, estos escuchadores son clases que tienden a realizar acciones adicionales en consecuencia a un evento, por ejemplo, cuando un usuario se crea, se suele enviar un correo de bienvenida; en un ambiente de DDD se ejecutaría el caso de uso de CrearUsuario quien a su vez, lanzará el evento UsuarioCreado.

Por otro lado, tendremos un escuchador EnviarCorreoBienvenida, que se disparará en cuanto el evento UsuarioCreado sea lanzado.

La manera en la cual los escuchadores son notificados, es a través de un bus que está conectado a toda nuestra aplicación, este bus se maneja dentro de la capa de aplicación y se hablará en futuros posts.

Una característica muy importante de los eventos, es que se pueden manejar de manera asíncrona (si así se desea), dejando que la interacción con el usuario se dé de manera muy rápido y creando colas (o queues) que se encarguen de ejecutar dichos eventos en otra ocasión o en paralelo, aumentando los tiempos de respuesta.

Nota: Los eventos, son clases DTO (data transfer objects) u objetos planos que suelen contener información importante del evento en curso, es importante que estas clases utilizan datos primitivos o escalares ya que de ésta manera pueden ser serializados para delegar su ejecución a algún comando con la base de datos o a una cola como rabbitmq

El motivo por el cuál se suelen utilizar eventos en vez de escribir el código como programación lineal, es que en cualquier momento se pueden agregar más eventos y/o eliminarlos si llegase a cambiar el requerimiento, nuevamente, teniendo una afectación mínima en el código de la aplicación.

Conclusión

A pesar de que la capa de dominio es meramente la representación conceptual del sistema y los contratos a seguir, es una de las capas más importantes, ya que define las bases para las siguientes capas. Es importante mencionar que todas aquellas clases que representen algún concepto, como Excepciones personalizadas y DTOs o modelos que no tengan lógica implícita, pueden ser creadas dentro de la capa de dominio.

Recuerda que si tienes alguna duda, sugerencia u observación sobre el contenido, puedes dejarme un comentario, o enviarme un correo a juls0593@gmail.com. Espero que el blog de hoy te haya sido de mucha ayuda.

¡Hasta la próxima!

DDD Objetos de valor como atributos de clase.

Javier Ledezma — Mon, 07 Sep 2020 06:48:53 +0000

DDD Objetos de valor como atributos de clase.

En un poco de contexto, Domain Driven Design (DDD) es una forma de desarrollar software en capas, dando prioridad a la lo lógica del negocio (o dominio), unificando el lenguaje de expertise de negocio con el lenguaje técnico en algo conocido como Ubiquitous Language y utilizando los principios SOLID como el medio para lograr el producto final.

Dentro de la metodología de DDD los términos relacionados con los objetos más básicos del sistema son las entidades y los objetos de valor. Ambos conceptos hacen referencia a una clase representativa de nuestro proyecto, regularmente un sustantivo en un caso de uso, por ejemplo, un usuario, una orden de compra, un artículo de inventario, etc.

La diferencia entre las entidades y los objetos de valor es que estos últimos tienden a ser inmutables y mientras que una entidad es un recurso que puede cambiar de estado, ser persistido y/o posteriormente eliminado.

Mientras estudiaba DDD me encontré con una implementación en la que los atributos de las clases pasaban de ser un tipo primitivo (por ejemplo, string o int) a un objeto de valor.

Para ejemplificarlo en detalle, supongamos que tenemos una clase Usuario que tiene los atributos nombre y edad:

# User.php

class Usuario 
{
  /** @var string */
  private $nombre;

  /** @var int */
  private $edad;

 public function __construct(float $nombre, float $edad)
  {
    $this->nombre = $nombre;
    $this->edad = $edad;
  }
}

Clase con objetos de valor como atributos

Primero que nada, se tenía una clase para representar el tipo de dato string:

# StringValueObject.php

class StringValueObject 
{
  /** @var string */
  protected $value;

  public function __construct(string $value)
  {
    $this->value = $value;
  }

  public function getValue(): string
  {
    return $this->value;
  }

  public function toString(): string
  {
    return $this->getValue();
  }
}

Posteriormente se tenía una clase para representar el atributo name del objeto Usuario:

# NombreUsuario.php

class NombreUsuario extends StringValueObject 
{
  public function __construct(string $value)
  {
    parent:__construct($value);
  }
}

Lo mismo sucedía para la edad, inicialmente una clase para representar el tipo de dato int:

# IntValueObject.php

class IntValueObject 
{
  /** @var int */
  protected $value;

  public function __construct(int $value)
  {
    $this->value = $value;
  }

  public function getValue(): int
  {
    return $this->value;
  }

  public function toString(): string
  {
    return strval($this->getValue());
  }
}

Después de una representación del tipo int, continúa una clase para representar el atributo edad del Usuario:

# EdadUsuario.php

class EdadUsuario extends IntValueObject 
{
  public function __construct(int $value)
  {
    parent:__construct($value);
  }
}

Finalmente se tenía la clase Usuario queda de la siguiente manera:

# Usuario.php

class Usuario 
{
  /** @var NombreUsuario */
  private $nombre;

  /** @var EdadUsuario */
  private $edad;

  public function __construct(NombreUsuario $nombre, EdadUsuario $edad)
  {
      $this->nombre = $nombre;
      $this->edad = $edad;
  }
}

Mi primera reacción fue un notable WFT?

Después de detenerme a analizar el porqué de todo esto, entendí lo siguiente.

Delegar reglas de dominio a los objetos de valor

Primero que nada, al crear una clase para cada atributo, podemos delegar la validación a éstas clases, por ejemplo, en el caso del nombre, nunca aceptaríamos un string vacío, por lo que extenderíamos esa funcionalidad de la siguiente manera:

# NombreUsuario.php

class NombreUsuario extends StringValueObject 
{
  public function __construct(string $value)
  {
    $this->asegurarNombreNoVacio(string $value);
    parent:__construct($value);
  }

  private function asegurarNombreNoVacio(string $value)
  {
    if ('' === $value) {
      throw new \InvalidArgumentException('El nombre no puede estar vacío.');
    }
  }
}

En dónde, si el valor no es vacío en automático arroja una excepción, lo mismo aplica para las validaciones de la clase EdadUsuario, en dónde la edad no puede ser menor a 0, quedando:

# EdadUsuario.php

class EdadUsuario extends IntValueObject 
{
  public function __construct(int $value)
  {
    parent:__construct($value);
  }

  private function asegurarEdadMinimaDe0($value)
  {
    if ($value < 0) {
      throw new \InvalidArgumentException('La edad no puede ser menor a 0.'); 
    }
  }
}

Integridad en nuevas instancias

Al delegar las validaciones a un objeto de valor, cuando nosotros requiramos una instancia de Usuario, no deberemos preocuparnos por la integridad, dado que todos los valores ingresados serían válidos o se detendrá la ejecución mostrando un error.

Código en un solo lugar

A parte de esto, nos brinda la facilidad de crear atributos compartidos entre clases y "módulos" (conocidos como sudominios en DDD), por ejemplo, si el Usuario tuviera alguna relación con alguna otra entidad como lo puede ser Rol, los atributos en formato de objeto de valor utilizarán la misma cla, y por ende no necesitaremos duplicar código en todos aquellos recursos compartidos.

Conclusión

DDD tiene bastantes conceptos interesantes, muchos de ellos parecen hacer el código muy complejo, pero a largo plazo, proporciona una manera muy escalable y mantenible de hacer código, ¿qué te parece la implementación de objetos de valor como atributos de clase?

Sistema de caché para optimizar web PHP

Javier Ledezma — Tue, 01 Sep 2020 14:03:00 +0000

Uno de los factores por los cuales deberíamos preocuparnos en nuestro día a día es tener un buen tiempo de respuesta en nuestras aplicaciones, este se puede ver degradado por varios factores, pero por fortuna para nosotros, existen muchos componentes y procedimientos que nos pueden ayudar a optimizarlo. En este blog te compartiré una serie de pasos relacionados con el caché, que pueden ayudarte a mejorar bastante los tiempos de respuesta.

¿Qué es Caché?

El caché es un componente que nos permite almacenar en memoria datos previamente procesados, regularmente los sistemas de caché funcionan como un Hashmaps o diccionario clave-valor, en dónde la clave es una cadena de texto que funciona como identificador y el valor puede contener casi cualquier cosa.

En general el concepto de caché se traduce a lo siguiente:

En dónde:

El cliente envía una petición al servidor.
Si la petición ya se encuentra en caché, entonces regresa la respuesta guardada.
Si la petición no se encuentra en caché, entonces es enviada a nuestra aplicación para que sea procesada.
La aplicación procesa los datos y crea una respuesta.
La aplicación almacena la respuesta en caché
La respuesta es enviada al cliente.

La memoria caché está limitada a valores computables, sin embargo, existen herramientas y técnicas que nos pueden ayudar a emular un sistema de caché para archivos físicos e inclusive para manejar bytecode, a continuación hablaremos de ellas.

¿Cuándo debería usar caché?

La respuesta a esta pregunta es casi siempre, un sistema de caché mejorará de manera increíble los tiempos de respuesta de tu aplicación, inclusive si tienes contenido generado dinámicamente puedes ahorrar unos milisegundos o segundos dependiendo de la complejidad y configuración que utilices.

¿Cuándo no usar caché?

El único enemigo real del caché son los sistemas real-time, en dónde se tienen actualizaciones por milisegundos, como lo puede ser un sistema de seguimiento de vehículos a través de GPS. De todos modos, se pueden utilizar ciertas técnicas de caché para agilizar parte del proceso completo.

Invalidar caché

Dado que el caché almacena datos/archivos procesados, es importante hacer limpieza de este cada cierto tiempo, haciendo que nuestra aplicación no se quede obsoleta en cuanto información y liberando memoria, el término "invalidar" hace referencia a eliminar los datos que se encuentran en caché.

Existen 3 factores que provocan la invalidación de caché:

Invalidación por tiempos definidos

Cuando almacenamos datos en caché, tenemos la posibilidad de elegir un tiempo que se mantendrá guardado, al pasar este tiempo, el caché será invalidado automáticamente.

El tiempo que debemos mantener los datos en caché dependerá de la concurrencia de la aplicación o fragmento de código, si es un código que regresa siempre la misma salida, por ejemplo, una landing page, podemos establecer un periodo de 30 mins a 2 horas, sin embargo, si el código que queremos cachear está en constante cambio, podemos incluso hacer caché de 3 a 20 segundos, en dónde no parece de mucha ayuda, pero en escenarios concurridos puede mejorar muchísimo los tiempos de respuesta.

Invalidación por elementos poco utilizados

Los elementos de caché que se utilizan en menor frecuencia también puede ser invalidados, en especial si la memoria está por agotarse, es muy probable que el propio sistema de caché invalide estos datos de manera automática.

Invalidación manual

Al igual que tenemos el control sobre lo que se almacena en caché, podemos definir en qué momento invalidar, esto resulta útil cuando, por ejemplo, cambiamos el estado de la base de datos y necesitamos que el caché obtenga las nuevas entradas.

Cacheando variables

Si lo que deseamos es almacenar valores diversos, siendo éstos, variables de sesión, resultados de queries, etc, entonces, necesitaremos de algún motor para manejar el caché, las principales opciones que tenemos en PHP son memcached y redis.

En ambos casos tenemos una API bastante amplia que nos permitirán almacenar valores en caché en una estructura clave-valor, ambos cuentan con la opción de establecer el tiempo que permanecerán los datos en caché.

Dado que ambas herramientas son muy buenas, tienden a tener muy buena integración con frameworks, por lo que muy probablemente ya tengas pre-configurado una librería en la herramienta que utilizas día a día.

La instalación de un servidor para procesar caché no es complicada y brinda muchísimos beneficios.

Cacheando bytecode

A pesar de que php es un lenguaje interpretado, es posible guardar fragmentos de código que siempre regresan la misma salida, haciendo que su ejecución sea mucho más rápida.

Para lograr ésto, existe la extensión OPCache, disponible a partir de php 5.5, su trabajo es análizar todos esos fragmentos de código y de manera automática los irá gestionando.

La configuración de la extensión se hace en el archivo php.ini y se recomienda una configuración inicial como la siguiente:

opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1

En dónde:

memory_consumption:Indica el tamaño de la memoria en MB que puede ser utilizada por OPCache, el valor mínimo permitido es de 8MB.
interned_strings_buffer: Indica la cantidad de memoria en MB para almacenar cadenas de téxto.
max_accelerated_files: Indica el número máximo de scripts que pueden ser almacenados en OPCache.
revalidate_freq: Tiempo en segundos que se mantendrán cacheados los scripts.
fast_shutdown: Permite deshabilitar el sistema de caché de manera rápida, delegando la limpieza de memoria al engine Zend. En versiones de php 7.2 o mayor, esta configuración no es necesaria.
enable_cli: Habilita el caché para la versión CLI de php.

El resto de configuraciones son opcionales, sin embargo, te comparto la documentación oficial de OPCache por si deseas saber más al respecto.

Cacheando archivos

Una técnica muy utilizada especialmente en herramientas que pre-procesan archivos, es mantener una versión cacheada del archivo previamente procesado, siguiendo el mismo concepto inicial, si el archivo ya fue procesado, se regresa como respuesta, de lo contrario, se compila, se guarda físicamente en una carpeta y regresa el archivo.

Una ventaja que tenemos es que podemos combinar partes físicas, con datos previamente guardados en memcached o redis teniendo una mezcla entre contenido estático y dinámico, pero cargado en memoria y con la posibilidad de manejar diferentes tiempos de vida.

Cacheando respuestas

La manera de cachear respuestas para ser servidas a mayor velocidad se da a través de cabeceras en la petición/respuesta, éstas pueden ser gestionadas con ayuda de tu servidor http como apache o nginx y suelen trabajar muy bien con librerías como cache-plugin.

Las cabeceras que suelen ser utilizadas para el control de caché son:

Expires: Tiempo de expiración del caché.
Cache-Control: Directivas que indican el comportamiento del caché.
ETag: Hash del contenido, se utiliza cuando se generan datos dinámicamente.
Last-Modified: Última fecha de modificación.
If-None-Match: Cabecera que indica que el contenido no se encuentra en caché.
If-Modified-Since: Cabecera que indica que el contenido que encuentra en caché ha sido actualizado.

Conclusión:

El caché es el mejor aliado que tenemos para optimizar los tiempos de respuesta de nuestra aplicaciones, es importante que dediquemos un tiempo a comprender y experimentar respecto al uso de caché.

Si es que utilizas algún framework, te invito a que investigues que métodos de cahé implementa y lo compartas en los comentarios o si tienes alguna otra implementación que nos pueda ayudar, sería genial que la compartieras.

Espero que esta guía te haya sido de ayuda.

¡Hasta la próxima!

Una nota para quienes quieren ser parte del mundo de TI

Javier Ledezma — Mon, 24 Aug 2020 03:42:11 +0000

Nota: TI es la abreviatura de "Tecnologías de información", abarca desde desarrollo de software, calidad en software, pruebas automatizadas y manuales, redes, soporte técnico de hardware y software, ciencia de datos, entre otros.

Hace poco empecé a tomar gusto por "asistir" a charlas gratuitas (videoconferencias) hechas por diversas comunidades de TI, charlas en las que se habla de diversos temas, desde lenguajes, nuevos frameworks hasta experiencias o tips que nos pueden servir día a día.

Por la buena experiencia que había tenido, decidí compartir una plática con uno de mis colegas que está muy interesado en sumergirse en el campo de TI, pero, a diferencia de mí, él terminó mucho más desanimado que interesado en ser parte de éste ámbito, y es que en la plática existieron muchos comentarios del tipo:

"Si no sabes inglés no la vas a hacer"
"Las entrevistas de las empresas grandes no sirven"
"No existen programadores full-stack"
"Es imposible que aprendas en poco tiempo"

Me sentí frustrado al escuchar estas frases y le pedí una disculpa a mi colega, entiendo que todos esos comentarios tienen un motivo válido para existir, aunqué no esté totalmente de acuerdo con ello. Si al igual que mi colega, estás interesado en involucrarte en el mundo de TI, voy a compartirte mi opinión al respecto.

1. No necesitas saber inglés para aprender.

Si bien es muy cierto que las carreras relacionadas a TI van de la mano con el idioma inglés, no es necesario que sepas inglés para aprender, existen miles de recursos en línea que te pueden ayudar a dar tus primeros pasos en español, inclusive, me atrevo a decir que vas a aprender inglés sobre la marcha.

No saber inglés vuelve el camino más difícil, pero no imposible. ¡Avientante!

2. ¿Deberías preocuparte por las entrevistas de empresas grandes, cómo Amazon, Facebook, Google, etc?

La respuesta a esta pregunta puede ser ambigua, así que te pondré dos variantes dependiendo de tus intereses:

Siéntete libre de leer solo la respuesta que coincida con tus intereses.

Si no estás interesado en trabajar en una empresa grande.

No, no es necesario que te preocupes por ello, aprende a la tecnología que te guste, a tu ritmo, únete a comunidades que estén interesadas en las mismas tecnologías y participa lo más que puedas.

Si estás interesado en trabajar en una empresa grande.

Si recién estás comenzando con tu carrera en TI y aspiras a llegar a una de éstas empresas, deberías preocuparte por conocer sus procesos de selección y las tecnologías que estás solicitando, pero siempre, priorizando tu proceso de aprendizaje.

Entrar en una empresa grande regularmente toma mucho tiempo, pero no está mal que dediques tu esfuerzo para entrar a alguna empresa, incluso puedes utilizar su career-path para construir tu camino de aprendizaje y orientar tus esfuerzos a ser especialista en aquello que solicitan.

Una vez que te sientas comodo, práctica haciendo código en un pizarrón o una hoja de papel, prepárate en términos de algoritmos y optimización de procesos.

Nota: Si estás interesado en una empresa grande, entonces, el inglés si es un factor obligatorio, pero tampoco necesitas ser un gurú, con que entiendas lo que te piden y sepas explicar tus ideas, es suficiente.

3. Los programadores full-stack si existen.

Para aquellos que no estén muy familiarizados con el término full-stack, se refiere a la capacidad de las personas de hacer aplicaciones completas por sí solas, desde la parte del diseño de las ventanas y la interacción con los usuarios (front-end), hasta el diseño y construcción de todo lo que necesita tu aplicación para funcionar, en términos de base de datos, optimización de recursos, construcción de API's, la arquitectura de tu aplicación (backend) e incluso la manera en la que se lleva a producción (sysadmin).

Si te das cuenta, ser un programador full-stack requiere mucho esfuerzo, pero es totalmente tangible, inclusive, puedes saber hacer todas esas actividades con diversas tecnologías, diversos lenguajes, etc. Estas son cosas que se aprenden con la práctica y que pueden tomarte tiempo, pero siempre es alcanzable.

Nota: No es necesario que lo aprendas todo, al igual que existen personas que tienen conocimientos generales de muchos ámbitos, hay quienes son profesionistas en ciertas áras, por ejemplo, UX/UI, front-end, back-end, DevOps, bases de datos, etc.

Elige la rama que más te guste y trabaja sobre ella, poco a poco irás mejorando tus conocimientos en general sobre todas las áreas.

4. El tiempo de aprendizaje es relativo.

Las personas aprendemos a diferentes ritmos, tomate tu tiempo para estudiar, practicar y preguntar sobre aquello que te guste y no te preocupes si tus colegas avanza más rápido que tu, al contrario, podrías acercarte a él para que te apoye con ciertas dudas y al igual, acércate con personas que vayan más lento que tu y ayudalas.

Una de las ventajas de TI, es que las comunidades son asombrosas y siempre están dispuestas a ayudar.

Conclusión

El mundo de TI es increíble en general, no hay límites para que puedes construir o lograr, te invito a que te animes y le des una oportunidad, inclusive si tu profesión o actividades están muy alejadas, TI es multidisciplinario y seguro podrás construir algo genial para lo que haces en tu día a día.

Si te sientes confundido por no saber cómo iniciar, ponte en contacto conmigo, estoy dispuesto a ayudarte, envíame un correo a juls0593@gmail.com y hablaremos de ello. Igual si tienes algún comentario o duda siéntete libre de colocarlo en los comentarios.

¡Hasta la próxima!

Consejos de CSS que me hubiera gustado saber cuando comencé a programar web

Javier Ledezma — Mon, 17 Aug 2020 06:15:37 +0000

A pesar de que css no es aceptado como un lenguaje de programación por muchos desarrolladores, tengo que confesar que fue una de las herramientas que me causaron más dolor de cabeza a lo largo de mi carrera, y atribuyó esto a que, a diferencia de otros lenguajes de programación, si en CSS escribes mal una regla, simplemente no funciona, no hay
errores que te digan qué estás haciendo mal o si tienes algún error de sintaxis, o peor aún, puede ser que tu regla esté funcionando pero no veas los resultados que esperabas en el navegador, sin explicaciones del por qué se comporta de esa manera.

Para las personas que no están familiarizadas con CSS, css es un la herramienta que hace de las páginas web una obra de arte visual, nos permite modificar la forma en la que se muestran los elementos como el color o tamaño de la letra, el espacio entre párrafos, tamaño de imágenes e inclusive nos permite crear animaciones. La sintaxis de CSS es muy sencilla, se ve similar a lo siguiente:

selector {
  regla: valor;
  regla-multivalor: valor1 valor2 valorN;
}

selector:pseudo-selector {
  regla: valor;
}

selector::pseudo-elemento {
  regla: valor;
}

En dónde:

selector: Es el elemento que al que se le va a aplicar la regla de estilo, existen múltiples selectores, algunos de ellos son, id (#), clase (.), selector universal (*), o selectores de etiqueta (h1, p, div), entre otros.
regla: Las reglas de CSS se utilizan para saber que "propiedad" del elemento se debe modificar, por ejemplo, la regla puede ser sobre el color de la tipografía, sobre los márgenes, o la almohadilla (padding) de los elementos.
valor: Es el valor que se le va a aplicar a cada "propiedad", por ejemplo, si modificamos la regla de color de tipografía, el valor será un color hexadecimal.
pseudo-selector: Considera éstos como modificadores acorde al estado del elemento, por ejemplo, si el usuario coloca el puntero del mouse sobre un elemento, éste cambia su estado a hover y nosotros podemos definir qué reglas necesitamos para cuando el elemento se encuentre en ese estado.
pseudo-elementos: Éstos son elementos que se crean automáticamente por los navegadores y envuelven el contenido del elemento HTML, agregando un bloque antes (before) y un bloque después (after), por lo general, estos elementos son invisibles porque el contenido que se crea está vacío por default, sin embargo, son muy útiles para agregar efectos adicionales como etiquetas flotantes, o un clon de nuestro elemento con estilos diferentes.

Nota: Hay reglas que solo aplican a ciertos elementos, por ejemplo, la regla list-style solo puede ser utilizada un elementos de tipo lista (ol o ul).

Ahora que estamos un poco en contexto, les compartiré algunos tips que me hubiera gustado saber cuando comencé a trabajar con CSS.

Entendiendo la regla "Display"

La propiedad display es una de las propiedades más importantes, nos permite modificar la forma en la que los elementos se muestran en el DOM, permitiéndonos colocar elementos uno tras otro o simplemente modificando propiedades como la altura y el ancho de los elementos.

Los valores más importantes son:

block: Utiliza el 100% del largo del DOM y se expande a lo largo dependiendo del contenido, si no tiene contenido, su altura es 0. Estas propiedades se pueden cambiar con las reglas width y height y sus variantes min y max (min-height, max-height, min-width, max-width).
inline-block: A diferencia de los display: block, en vez de utilizar el 100% del DOM, este crece a los ancho acorde al contenido que tiene dentro. El comportamiento del tamaño vertical es similar.
flex: Una de las reglas que me hubiera gustado conocer cuando incié con CSS, se encarga de "envolver" el contenido del elemento y te permite modificar de qué manera de muestra con ayuda de otras propiedades, te permite cambiar las dimensiones del contenedor, ajustar el contenido al centro, al inicio, al final o simplemente rellenar el contenedor con el contenido que tenga (en ambos sentidos, horizontal y vertical)
grid: Otra regla que me hubiera gustado conocer en mis inicios, te permite colocar el contenido del elemento en formato de tabla, ajustando los hijos como si fueran un sistema de celdas y columnas.

Entendiendo la regla "Position"

Uno de los conceptos que más me costó trabajo entender, fue la regla position, hace referencia a la forma en la que un elemento se posiciona o se dibuja en el DOM. La mayoría del tiempo tendremos que modificar la posición de los elementos para lograr efectos increíbles, sin embargo, mal utilizada puede destruir por completo el layout de nuestra aplicación.

Antes de comenzar tenemos que saber que todos los elementos tienen la posición static que permite el flujo normal de los elementos, a partir de allí viene una nota importante:

la regla position no solo afecta el flujo de posición del elemento actual, sino también de los elementos hijo.

Una vez que se modifica la posición de un elemento, se pueden utilizar las reglas: left, right, top o bottom para ayudar a colocar el elemento en donde sea que se requiera.

Los valores que regularmente encontraremos son:

static: Es el valor por defecto de todos los elementos.
absolute: Permite romper el flujo normal y permite posicionar el elemento utilizando el contenedor padre (o DOM si es que no hay un contenedor padre) como referencia para colocar el elemento.
relative: Permite colocar el elemento en relación directa con el elemento padre.
fixed: Permite que el elemento se quede fijo en una posición, independientemente de que se se utilice scroll.

Prioridad de reglas CSS

La prioridad de las reglas CSS puede salvarte de muchas horas de frustración, existe un juego de prioridades que siempre se van a seguir:

Regla: !important: La regla !important se utiliza para forzar que un elemento tenga un estilo, aunque puede ser útil en algunas ocasiones, es importante evitar el uso de esta regla, ya que tenemos darle mantenimiento en ocasiones futuras puede ser muy difícil. Ejemplo:

   p {
     color: green !important;
   }

Estilos in-line: Los estilos in-line son aquellos que colocan directamente en el elemento html, y tienen prioridad sobre todas las reglas, a excepción de un !important. Ejemplo:

   <p style="color: red;">

Mayor especificidad: La especificidad es un término que se refiere a que tan específico es el selector de una regla css, por ejemplo, teniendo el siguiente html:

   <div class="product-detail">
     <ul class="product-properties">
       <li class="product-property">...</li>
     </ul>
   </div>

Los ejemplos de especificidad:

   /* Especificidad de 3, mayor prioridad */
   .product-detail .product-properties .product-property {}

   /* Especificidad de 2 */
   .product-properties .product-property {}

   /* Especificidad de 1 */
   .product-property {}

Última línea: Las reglas se suelen aplicar de arriba hacia abajo, es decir que la regla que se encuentre más abajo, sobreescribirá las que se encuentren antes, a excepción de que caiga en los puntos anteriormente mencionados. Ejemplo:

   p {
     color: red;
   }

   a {
     color: white;
   }

   p {
     /* Este valor sobreescribe el que se definió en la primera regla. */
     color: green;
   }

Preprocesadores

Los preprocesadores son herramientas que nos permiten escribir reglas css de manera muy sencilla, tienen ciertas funciones que permiten crear css reutilizable y mantenible, un ejemplo de preprocesador de css (y mi favorito) es sass/scss, te permite escribir css con la misma sintaxis, pero con muchas facilidades, como anidar selectores, también te permiten crear variables, funciones con estilos repetitivos, etc.

Las reglas creadas con preprocesadores tienen que ser convertidas a css antes de que puedan ser utilizadas, pero los mismos preprocesadores te dan estas facilidades.

Para hacer una comparación de scss vs css utilizaré el siguiente ejemplo:

<div class="product">
  <ul class="product-properties">
    <li>...</li>
  </ul>
</div>

Suponiendo que quisiéramos crear estilos para cada uno de los elementos del ejemplo, en css tendríamos algo similar a:

.product {
  /* reglas de producto */
  color: #222222;;
}

.product .product-properties {
  /* reglas de las propiedades de producto */
}

.product .product-properties li {
  /* reglas de cada elemento de la lista de propiedades de producto */
}

.product .product-properties li:hover {
  /* reglas de cada elemento de la lista de propiedades de producto hover */
  background-color: #222222;
  color: #ff22ff;
}

.product .product-properties li.active {
  /* reglas de cada elemento de la lista de propiedades de producto activo */
  background-color: #222222;
  color: #ff22ff;
}

Utilizando sass, se vería similar a esto:

$primary-color: #222222;
$text-color: #ff22ff;

.product {
  /* reglas de producto */
  color: $primary-color;

  &-properties {
    /* reglas de las propiedades de producto */

    li {
      /* reglas de cada elemento de la lista de propiedades de producto */

      &:hover,
      &.active {
        background-color: $primary-color;
        color: $text-color;
      }
    }
  }
}

En donde, al ser convertido a css, obtendremos el mismo resultado, pero a nivel sitáxis evitamos repetir selectores y a demás utilizamos variables para definir ciertos atributos que pueden cambiar con el tiempo y sin tener que modificar mucho nuestros archivos css.

Arquitectura de estilos 7-1

Al igual que el backend y las tecnologías de fontend, los estilos también pueden ser manejados por una arquitectura, permitiendo que proyectos medianos y grandes sean mantenibles a lo largo del tiempo, estas arquitecturas se adaptan perfectamente con los preprocesadores y aunque puede haber variantes, me gustaría hablar un poco de la arquitectura 7-1 que me ha funcionado perfectamente.

En resumen, la arquitectura 7-1 es un juego de 7 directorios con responsabilidades definidas y un archivo que se encarga de concentrar todos los estilos de estos directorios, este último será incluido en nuestro archivo HTML o bien será exportado como punto de salida para nuestras aplicaciones.

Consta de construir el siguiente árbol de archivos:

sass
|
|– abstracts/
|   |– _variables.scss    # Sass Variables
|   |– _functions.scss    # Sass Functions
|   |– _mixins.scss       # Sass Mixins
|   |– _placeholders.scss # Sass Placeholders
|
|– base/
|   |– _reset.scss        # Reset/normalize
|   |– _typography.scss   # Typography rules
|   …                     # Etc.
|
|– components/
|   |– _buttons.scss      # Buttons
|   |– _carousel.scss     # Carousel
|   |– _cover.scss        # Cover
|   |– _dropdown.scss     # Dropdown
|   …                     # Etc.
|
|– layout/
|   |– _navigation.scss   # Navigation
|   |– _grid.scss         # Grid system
|   |– _header.scss       # Header
|   |– _footer.scss       # Footer
|   |– _sidebar.scss      # Sidebar
|   |– _forms.scss        # Forms
|   …                     # Etc.
|
|– pages/
|   |– _home.scss         # Home specific styles
|   |– _contact.scss      # Contact specific styles
|   …                     # Etc.
|
|– themes/
|   |– _theme.scss        # Default theme
|   |– _admin.scss        # Admin theme
|   …                     # Etc.
|
|– vendors/
|   |– _bootstrap.scss    # Bootstrap
|   |– _jquery-ui.scss    # jQuery UI
|   …                     # Etc.
|
`– main.scss              # Main Sass file

Si bien, la estructura se explica por sí sola, me gustaría recapitular un poco sobre las responsabilidades de cada directorio:

abstract: Contiene archivos cuya funcionalidad es mantener los elementos reutilizables en términos de estilos, también suele contener clases de utilerías.
base: Contiene los estilos necesarios para dejar nuestra aplicación normalizada ante todos los navegadores, hace mucho énfasis en los márgenes, almohadillas y tipografía.
components: En esta carpeta crearemos cuantos archivos necesitemos, cada archivo contendrá los estilos de un fragmento de código que pudiese ser reutilizado en diversas partes de la aplicación, por ejemplo, una tarjeta, los botones de la aplicación, los mensajes de feedback, entre otros.
layout: En esta carpeta colocaremos aquellos estilos de los elementos centrados en la navegación de la página, como lo son sidebars, header y footer.
pages: En esta carpeta se crean los estilos que deben ser aplicados a una página en concreto, por ejemplo, estilos que lleva la sección de landing page y que no tiene la sección de productos, y viceversa.
themes: En caso de que quieras brindar la posibilidad de cambiar la interfaz de usuario dependiendo del rol o simplemente personalizar los colores, el fondo u otros elementos, puedes crear estos estilos en la carpeta de temas.
vendors: En caso de que tu aplicación utilice librerías externas como bootstrap, materializecss o element-ui puedes importar los estilos de esas librerías en esta carpeta.
main.scss: También llamado app.scss, el archivo no contiene ninguna regla css, su función es importar los archivos que se vayan creando en las subcarpetas mencionadas anteriormente.

Media Queries

Una de las ventajas del desarrollo web, es que puede ser transportado fácilmente a dispositivos móviles con solo modificar estilos, esto permite adaptar el contenido del DOM a cualquier tamaño. Los media-queries son reglas css que nos permiten modificar los estilos cuando el viewport (el tamaño de la pantalla en la que se visualiza el DOM) cumpla con ciertos requisitos, por ejemplo, si el viewport es mayor a 300px de ancho, o si el DOM está siendo visualizado en alguna tablet.

Los media-query tienden a verse similar a esto:

@media (max-width: 600px) {
  .selector {
    display: none;
  }
}

En dónde la función @media puede contener las medidas sobre las cuales aplicará las reglas que se encuentren en el cuerpo de la función.

Es un poco complicado hacer un estudio de todas las posibles variantes de tamaño de dispositivo, pero te puedo recomendar ir a la documentación de librerías o frameworks de fronted, como lo son bootstrap o semantic-ui, ellos tienen una tabla de medias que puedes utilizar de referencia para adaptar tus estilos a computadoras con definición muy grande, regular, tablets y celulares.

Animaciones

Desde el lanzamiento de CSS3, hacer animaciones es muy sencillo, basta con conocer la propiedad transition o bien animation y la función @keyframes, la primera es una forma sencilla en la que CSS esuchará los cambios en las reglas de CSS, haciendo una animación pequeña entre el valor de inicio y valor final del cambio.

Un ejemplo sencillo es:

.card {
  display:block;
  width: 100px;
  height: 150px;
  transition: all .3s ease-out;
}

.card:hover {
  width: 200px;
  height: 250px;
}

En dónde, al posicionar el puntero del mouse sobre los elementos con la clase card, estos aumentaran su tamaño de 100x150 a 200x250, y css aplicará una transición de 300 milisegundos entre estos cambios de tamaño. El atributo ease-out es un alias para el comportamiento de la animación (curva), nos dice que inicie rápido pero que al final la animación sea lenta, existen muchas posibles curvas de comportamiento de animaciones, te invito a darles una revisada aquí.

La segunda forma de hacer animaciones es a través de la función @keyframes y la regla animation. Un @keyframes define una serie de pasos que se tienen que cumplir, esta se define utilizando un rango de 0% a 100%, en donde 0% es el inicio de la animación y 100% es el final. Se pueden crear tantos pasos sean necesarios, los @keyframes se definen de la siguiente manera:

@keyframes nombre-del-keyframe {
  0% { /* css que se va a aplicar */ }
  30% { /* css que se va a aplicar */ }
  68%, 72% { /* css que se va a aplicar */ }
  100% { /* css que se va a aplicar */ }
}

Finalmente, podemos hacer uso de los keyframes con la propiedad animation:

.card {
  animation: nombre-del-keyframe 2s ease-out; 
}

En dónde especificamos que utilizará el @keyframe que se acaba de crear, la duración será de 2 segundos y la curva de animación será con inicio rápido y término lento (ease-out).

Conclusión:

CSS es muy divertido una vez lo entiendes, con él puedes crear páginas fabulosas, en ésta guía te compartí los tips que me hubiera gustado saber cuando inicié a utilizar css con el fin de que tu curva de aprendizaje sea muy suave, que comiences a conocer las herramientas que se utilizan hoy en día (preprocesadores) y también un tip rápido para comiences a animar tus proyectos, esos pequeños detalles le un plus enorme a tu aplicación y una experiencias muy agradable a los usuarios.

Te invito a que me compartas tus experiencias con CSS, y si consideras que se puede mejorar el contenido, tu comentario es muy valioso para mi.

¡Hasta la próxima!.

Controladores livianos y buenas prácticas.

Javier Ledezma — Mon, 03 Aug 2020 15:12:51 +0000

Controladores livianos y buenas prácticas.

Gracias a los frameworks modernos de desarrollo web, crear aplicaciones se vuelve una tarea muy sencilla y basta con entender un poco el funcionamiento del protocolo HTTP y un poco de MVC (o variantes) para darnos cuenta de que todo se reduce a:

Request -> Router -> Controller -> Response

En dónde el cliente envía una petición al servidor, esta es procesada por un sistema de rutas (router), quien lo envía al controlador correspondiente y el controlador se encarga de ejecutar una o varias acciones y construir una respuesta en el formato necesario (por ejemplo un archivo html o una respuesta xml o json) y la envía como respuesta al cliente.

Y siguiendo ese patrón nosotros podemos construir todo tipo de aplicaciones, sin embargo, el mal manejo de controladores puede resultar en una aplicación imposible de mantener y por ende, un software que estará destinado al fracaso.

"El mayor costo en el desarrollo de software no es para crearlo, sino para mantenerlo. "

Una frase del libro Clean Code de Robert C. Martin, el cual hace énfasis en las buenas prácticas de la programación orientada a objetos.

Una de las mejores maneras de crear código mantenible es dejar que los controladores de nuestra aplicación solo se encarguen únicamente de acciones CRUD y utilizar otros patrones de diseño o técnicas para delegar actividades secundarias.

CRUD es un acrónimo de: Create, Read, Update & Delete (Crear, Leer, Actualizar y eliminar).

Un controlador CRUD debería verse similar a:

class Controller {
  // lista un recurso
  public function index() {}

  // muestra formulario de creación (opcional en API's)
  public function create() {}

  // crea un nuevo registro en BD
  public function store()   

  // muestra detalles de un registro
  public function show()   

  // muestra formulario de edición (opcional en API's)
  public function edit() {}

  // actualiza un registro en BD
  public function update() {}

  // elimina un registro en DB
  public function delete() {}
}

Puede llegar a tener variantes dependiendo del lenguaje y el framework utilizado.

Existen un par de escenarios en los que te puede causar ruido el uso de los controladores CRUD, estos son:

Cuando necesitamos manejar recursos relacionados.
Cuando nuestro controlador contiene un sólo método.

1. Manejado recursos relacionados

Si tu controlador requiere trabajar con recursos relacionados, por ejemplo, si tienes un blog, en dónde un artículo puede tener comentarios y para administrar los comentarios necesitas una instancia de artículo, en vez de agregar métodos adicionales al controlador de artículos, crea un controlador que se encargue de manejar esas relaciones, ejemplo:

class ArticleCommentsController
{
  // lista los comentarios de un artículo
  public function index(int $idArticle) {}

  // crea un nuevo comentario para un artículo
  public function store(int $idArticle)   

  // muestra detalles de un comentario relacionado a un artículo
  public function show(int $idArticle)   

  // actualiza un comentario relacionado al artículo
  public function update(int $idArticle) {}

  // elimina un comentario relacionado al artículo
  public function delete(int $idArticle) {}
}

En dónde cada método recibe el id del recurso principal (en este caso articulo) y pero las acciones afectan al recurso comentario.

2. Manejando controladores de un solo método

Cuando tu controlador tiene una función distinta a la de acciones CRUD, por ejemplo, si tenemos una página de inicio para una landing page o un dashboard si estámos trabajando con usuarios administradores. En éstos casos se puede utilizar el método index como la única fuente o si tu framework te lo permite, también puedes utilizar controladores invocables, esto quiere decir que se sobreescribe el método invoke de la clase, ejemplo:

class HomeController
{
  public function __invoke(/* parameters */)
  {
      // Lógica aquí
  } 
}

De ésta manera nos aseguramos que nuestro controlador solo ejecutará una acción.

Quitando carga a los controladores

Todo método o funcionalidad fuera de lo métodos CRUD puede ser extraído a su propia clase, en seguida te comparto algunas herramientas que puedes utilizar para lograr mantener tu controlador libre de código adicional:

Es muy probable que el framework de tu preferencia no cuente algunos de los elementos citados.

Middleware

Un middleware es una capa de software que puede interceptar la petición del cliente o la respuesta generada por nuestra aplicación y regularmente se utilizan para hacer revisar de los datos de sesión, encabezados del navegador, validar datos de la petición del cliente y/o agregar encabezados adicionales a las respuestas.

Eventos

Un evento es una forma de decirle a nuestra aplicación que algo ha ocurrido, dando paso a que la aplicación pueda actuar en consecuencia con una o más acciones (estas acciones también son conocidas como escuchadores o suscriptores).

Uno de los ejemplos más concurridos es disparar un evento cuando un usuario se registra en nuestra aplicación, dejando que el controlador se encargue de persistir al usuario y delegando la lógica de enviar un correo de bienvenida a un escuchador o a algún suscriptor.

Una ventaja de utilizar eventos, es que se pueden ejecutar muchas acciones en consecuencia, cada una con su propia lógica.

Peticiones personalizadas

Gran parte de la lógica de los controladores se basa en validar que los datos ingresados por el usuario sean correctos y que estos no vayan a provocar inconsistencias en nuestra base de datos.

Por fortuna, muchos frameworks cuentan con peticiones personalizadas, estas son clases que “decoran” una petición HTTP común y agregan esa capa de validación necesaria.

En caso de que el framework que utilices no cuente con esta opción, puedes utilizar middlewares para este fin.

Servicios

Un servicio es una clase encarga de hacer algo.

No muy claro, ¿cierto?. Esto se debe a la versatilidad que puede tener un servicio.

Un servicio es un componente que cumple con una función relacionada a regas de negocio de la aplicación. regularmente son fragmentos pequeños de código de responsabilidad única.

Estas clases suelen delegarse al contenedor de la aplicación utilizando inyección de dependencias para instanciarse de manera automática y brindando la posibilidad de que de manera interna puedan utilizar otros servicios en caso de que sea lógica muy compleja.

Los servicios suelen utilizarse cuando un controlador requiere mucha lógica en sus métodos CRUD y/o cuando tenemos fragmentos de código que pueden ser reutilizados en nuestra aplicación.

Repositorios

Un repositorio es una fuente de datos y se traduce a clases encargadas de brindar información de diversas fuentes, por ejemplo, traer un arreglo de una base de datos local o proporcionar datos de una API externa, entre ortro.

Una buena práctica es definir contratos o interfaces que definan los métodos que necesitemos en nuestra aplicación y hacer tantas implementaciones como se requieran. De esta manera, si en algún futuro se llega a cambiar la fuente de datos, entonces, la aplicación no tendrá que modificar todo el código, solo las implementaciones de los contratos.

Ejemplo:

# src/Repositories/UserRepository.php

interface UserRepository
{
  public function findById(): User;
  public function all(): User[];
}

# src/Repositories/Implementations/DbUserRepository.php

class DbUserRepository
{
  /* @var DBAL */
  private $connection;

  // ...

  public function findById(): User {}
  public function all(): User[] {}
}

Utilerías

En ocasiones tenemos código que no está relacionado a las reglas de negocio, pero que puede utilizado en muchas partes de la aplicación, por ejemplo, si necesitamos dar formato a un decimal para mostrarlo en formato de moneda, o si necesitamos hacer conversiones de fechas, en éstos casos se puede crear una clase de utilerías que contenga estas funciones.

Es muy importante que no intentes crear "navajas suizas" en las clases de utilerías, para evitarlo, intenta agrupar las funciones por su tipo, por ejemplo, crea una utilería para manejar strings (class StringUtils), y otra para manejar fechas (class DateUtils).

Conclusión

Utilizar estas técnicas o patrones nos van a ayudar a tener controladores y componentes muy fáciles de mantener a largo plazo. Y aunque en éste post solamente se mencionan de manera muy superficial, es importante que conozcas los conceptos para que puedas comenzar a implementarlos en tus proyectos.

Te invito a que comiences por utilizar lo aprendido en éste post en tus proyectos y si tienes algún consejo adicional o comentario, siempre será bienvenido en los comentarios, ¡gracias por tu tiempo!

¡Hasta la próxima!

Estilo de código en proyectos PHP

Javier Ledezma — Mon, 27 Jul 2020 05:13:23 +0000

Una de las mejores maneras de mantener un código legible a lo largo del tiempo es definir estándares de estilo, con esto me refiero a; por ejemplo:

Definir que las clases se deben declarar utilizando StudlyCaps.
Se deben utilizar 4 espacios para identar el código.
No se deben dejar líneas en blanco después de abrir una llave.
entre otros...

Y aunque parece trivial el hecho de seguir estas convenciones, en ocasiones podemos cometer algún error, ya sea por la velocidad del desarrollo, desconocimiento de los estándares o simplemente por pereza. Por fortuna para nosotros existen herramientas automatizadas que nos permiten "forzar" a que el código siga nuestras convenciones iniciales, tal es el caso de PHP Code Sniffer.

Uso

PHP sniffer es una librería que se encarga de la validación de sintaxis del código (también conocido como estilo de código), la librería está configurada para seguir con los estándares oficiales definidos en https://www.php-fig.org/psr/ (apartados PSR-1 y PSR-12), sin embargo, tiene flexibilidad para que puedas modificar esas reglas y configurarlas de tal manera que se adapte a los estándares de tu proyecto.

Una ventaja de utilizar code sniffer es que a demás de validar la sintaxis, cuenta con una utilidad que puede corregir algunos de los errores detectados por la misma herramienta.

Instalación y configuración

Si estás utilizando composer, bastará con ejecutar la siguiente instrucción en tu terminal, en la raíz de tu proyecto:

composer require --dev friendsofphp/php-cs-fixer

Nota: En caso de no utilizar composer, code sniffer cuenta con ejecutable .phar además de otros métodos de instalación, te recomiendo visitar el repositorio oficial que mantendrá actualizada la guía de instalación para cada caso.

Se utiliza la bandera --dev ya que la validación del estilo de código solamente se realiza durante la etapa de desarrollo.

Una vez instalada la libreŕia, se puede utilizar ejecutando la siguiente línea:

php ./vendor/bin/ {SRC_FOLDER}

En dónde:

SRC_FOLDER: Es el directorio que queremos que se analizado por phpcs.

Al igual que las librerías de complemento del proyecto, se puede crear un archivo para configurar las reglas necesarias, en el caso de phpcs la configuración se realiza en php aunque el archivo de configuración no lleve como tal la extensión php.

Para poder configurarlo podemos crear en el directorio raíz un archivo llamado .php_cs o .php_cs.dist, con algo similar a lo siguiente:

<?php

$finder = PhpCsFixer\Finder::create()
    ->in('DIRECTORIO_DEL_PROYECTO');

return PhpCsFixer\Config::create()
    ->setRules([
        'array_syntax' => ['syntax' => 'short'],
    ])
    ->setFinder($finder);

En dónde:

$finder: Es un objeto en dónde podemos definir los archivoso directorios que queremos que sean analizados por phpcs, se crea utilizando el objeto PhpCsFixer\Finder y en él puedes encadenar los métodos in(DIRECTORY) para establecer el directorio del proyecto, y el método exclude(DIRECTORY) si deseas excluir algunos archivos.

Nota: DIRECTORY, es un string, y por lo regular, el método puede tener como parámetro la constante mágica __DIR__ haciendo referencia al directorio actual.

El archivo debe regresar una instancia del objeto PhpCsFixer\Config el cual contiene todas las reglas que se desean agregar al verificador de estilos. Nuevamente reitero que se siguen las convenciones más recientes, pero eres libre de agregar en el método setRules() todas las reglas que necesites, para que phpcs se adapte a su proyecto.
No encadenar el método setFinder a la instancia de PhpCsFixer\Config , para decírle los directorios que debe analizar y/o excluir.

Ejecución de phpcs

Una vez configurado phpcs con las reglas que deseemos y archivos que deben ser analizados, entonces tenemos un par de comandos que se encargarán de ejecutar la herramienta de phpcs:

Revisión de estilos

Bastará con ejecutar la instrucción:

./vendor/bin/php-cs-fixer fix -v --diff --dry-run

En dónde:

fix: Es la instrucción que se encarga de ejecutar el análisis de los estilos del código.
-v: Le indica a phpcs que muestre la mayor cantidad de información posible respecto a su ejecución.
--diff: Le indica a phpcs que nos muestre las diferencias encontradas en cada archivo.
--dry-run: Le indica a phpcs que el comando debe ejecutarse sin realizar ningún cambio en los archivos analizados.

Al finalizar el proceso, phpcs te entregará una salida en la que cada archivo analizado se puede representar con los valores:

? = Pasó algo inesperado.
I = Sintaxis de php incorrecta, se saltará la revisión.
S = Archivo saltado, por estar vacío o por ya estar en caché.
. = No requiere cambios.
F = Arreglado.
E = Archivo que tiene errores de estilo.

A parte de darte una representación rápida de cada archivo, el comando hará una lista de los errores que se detectaron en cada archivo.

Nota: phpcs utiliza un sistema de caché para no tener que analizar aquellos archivos que ya fueron analizados y que no tienen cambios. Si tu proyecto es muy extenso, es muy probable que éste proceso demore un buen rato.

Corrección de estilos

Parte de la magia de phpcs no es solo asegurarse de que las reglas se cumplan, sino que tiene la capacidad de corregir de manera automática aquellos errores que se detectaron durante el análisis, para ello, se ejecuta el siguiente comando:

./vendor/bin/php-cs-fixer fix -v --diff

Si nos damos cuenta, el comando es muy similar al anterior, pero eliminado la opción --dry-run, de ésta manera phpcs intentaŕa agregar los estilos erróneos que detecte.

Una vez terminado el proceso, obtendremos una salida similar a la del comando anterior.

Creando un alias para ejecutar phpcs (solo composer)

Ahora bien, es muy probable que pienses que los comandos son un poco difíciles de memorizar, por fortuna para nosotros, si es que utilizamos composer, es que podemos crear un script personalizado que haga más fácil la ejecución de cualquier herramienta externa, nosotros crearemos 2, una para revisar el código y otra para corregirlo.

Para ello, basta con abrir el archivo composer.json , y agregar una nueva entrada llamada "scripts", similar a lo siguiente:

"scripts": {
    "phpcs": "php-cs-fixer fix -v --diff --dry-run",
    "phpcs-fix": "php-cs-fixer fix -v --diff"
},

Una vez realizados los cambios, guardamos el archivo y podremos ejecutar los comandos:

composer phpcs para hacer la revisión del código
composer phpcs-fix para intentar solucionar los errores de manera automática.

Conclusión

Una de las principales ventajas de phpcs , a parte de ayudar mantener el código igual a lo largo de todo su desarrollo, es que se presta perfectamente para un proceso de integración continua, por ende, te permite que tu proyecto pueda ser construido por varios programadores y que en caso de no cumplir con las reglas, el código no se podrá integrar al proyecto.

Y a pesar de que phpcs tiene una herramienta que te permite corregir los estilos automáticamente, yo te sugiero que intentes escribir código que no tenga errores de estilo (sin la necesidad de usar la herramienta de corrección). Esto te ayudará a mejorar tu calidad de código en general.

Espero que este post te haya sido de utilidad, recuerda que si tienes alguna duda o comentario que pueda mejorar el contenido, siéntete libre de compartirlo en los comentarios, puedes expresarlo en los comentarios.

¡Hasta la próxima!

¿Eres un buen programador?

Javier Ledezma — Mon, 20 Jul 2020 02:43:26 +0000

Desde que comencé a desarrollar software siempre he temido al hecho de no ser un buen programador, un miedo que se basaba en la curiosidad de comparar mis habilidades con el resto de mis colegas, de saber si seré capaz de completar las tareas que me designen, si mis soluciones serán las correctas, de saber si mi velocidad de desarrollo es la óptima, e inclusive, antes de ser contratado en algúna empresa o comenzar algún proyecto, el hecho de cuestionar si mis conocimientos eran suficientes.

Probablemente a ti te haya pasado algo similar, este proceso de dudar de tus capacidades para llevar a cabo cierta actividad es conocida como síndrome del impostor, en el podcast chile, mole & tech tienen un episodio completo respecto al tema por si te gustaría saber más al respecto.

En éste blog te compartiré un ciclo de actividades que me han hecho superar el síndrome del impostor a lo largo de mi carrera, inclusive si no sufres del síndrome del impostor, podrían ayudarte a mejorar bastante:

Aprende algo nuevo de tu tecnología favorita

Ya sea que tu rama sea backend, frontend, desarrollo móvil, ciencia de datos o cualquier otra, elije un lenguaje y/o un framework y aprende lo más que puedas de esa tecnología, intenta leer su documentación oficial, si se te complica demasiado, busca blogs o videos en youtube e intenta seguir los tutoriales que encuentres.

En internet hay información gratuita de todo lo que necesites, sin embargo, si tienes la posibilidad, intenta invertir en recursos que te ayuden a aprenderlo, por ejemplo un curso de paga, no dudes en invertir en ellos, regularmente son recursos que te ayudan a aprender y a mejorar notablemente.

Si ya conoces las bases del lenguaje o tecnología, ahora céntrate en aprender buenas prácticas, intenta aprender patrónes de diseño y profundiza lo más que puedas respecto al lenguaje.

Mi colega Juan Perdomo, esta escribiendo blogs de patrones de diseño) por si estás interesado en ellos.

Practica

Con cada cosa nueva que aprendas, intenta crear un mini-proyecto en dónde utilices lo que aprendiste, intenta que tu propuesta de proyecto no sea muy complicada, por ejemplo, si aprendiste cómo crear e invocar funciones, entonces plantea un reto en dónde tengas que crear una serie de funciones, con diversos tipos de parámetros, con diversos valores de retorno y asegurate de llamarlas en algún lado.

Si te sientes seguro de lo que sabes hasta ahora, en vez de crear un proyecto, intenta contribuir a algún proyecto open source, ésta es una de las mejores maneras que existen para dejar de lado el síndrome del impostor.

Comparte

Hay una diferencia enorme entre un proyecto que se queda en un ambiente local y uno que es compartido en internet. En internet recibirás críticas de todo tipo, pero estoy seguro de que sabrás interpretarlas para mejorar lo que hiciste.

Si tu mini-proyecto es un script sencillo, no tienes que crear una págna web o un ejecutable perfecto, basta con que subas tu código a un repositorio como GitHub o GitLab.

Para este paso, tendrás que dedicar un poco de tiempo para aprender a los comandos básicos de herramientas de control de versiones como lo es git. Por fortuna, hay muchos recursos gratuitos y de paga en los que te puedes apoyar para aprenderlo, si no encuentras algo, sientete libre de preguntar en los comentarios.

Crear el hábito de subir tu código a un repositorio, además de servirte como respaldo en caso de que algo suceda con tu computadora, te permite medir los avances que has tenido desde que comenzaste, y también podrías utilizar esto como un portafolio para alguna entevista de trabajo.

Por otro lado, no solo puedes compartir código, si conoces alguna manera de hacer las cosas, puedes escribir un blog o crear un apunte y compartirlo en tus redes sociales, esto también te deja mucho aprendizaje.

Retroalimentación

Hazle llegar tu código a tus compañeros de trabajo, amigos programadores o si te sientes con un poco más de confianza, a grupos redes sociales como Facebook o algúna comunidad de la tecnología y pide algún mensaje de mejora, siempre mencionando tu tiempo de conocer la tecnología, esto ayudará a tus colegas a saber que tan duras pueden ser las críticas contigo.

No solo puedes preguntar si tu código esta bien o mal, puedes preguntar que podrías mejorar o de qué manera podría hacer más complicado tu mini-proyecto. Esto te dará ideas para seguir creando retos.

A veces es muy complicado encontrar a alguien que te pueda apoyar dado que las personas tienen otras cosas que hacer, si gustas, pregunta por feedback en los comentarios y con suerte, yo o alguien con mayor experiencia en tu área pueda ayudarte.

Al igual, si tienes más experiencia, tomate un tiempo apra revisar el código de otras personas y brindale los mejores consejos.

Escribe pruebas automatizadas

En general, éste punto es uno de los que yo he aprendido recientemente y, siendo honesto, no es fácil adquirir una cultura de programación de pruebas, sin embargo, tiene muchísimos beneficios. Concéntrate en entender cuál es el propósito de una prueba unitaria, cómo se programan y cómo ejecutarlas.

Intenta agregar pruebas para cada uno de los mini-proyectos que has desarrollado, esto te dará la pauta para comenzar desde cosas sencillas hasta lo más complejo que hayas hecho.

Mejora (Refactoriza)

De vez en cuando, vuelve a alguno de tus proyectos anteriores y con ayuda de las pruebas automatizadas, mejora el código que tenías, ya sea que mejores el performance, mejores la forma en que se hizo o que le des estílo a tu código, este hábito te permitirá medir el progreso que has tenido a lo largo de tu carrera y te dará la confianza necesaria para afrontar nuevos retos.

Conclusión

Este ciclo de actividades es una forma de llegar a tu siguiente versión de programador, en mi caso logré hacer de estas actividades un hábito e implementarlas en proyectos open source ha sido la mejor manera de mejorar la confianza en mi mismo.

Espero que el contenido de este blog te haya sido de mucha ayuda. Recuerda que tus comentarios siempre son bienvenidos, si tienes algo que agregar o necesitas ayuda en un punto específico, con gusto te ayudaré.

¡Hasta la próxima!

¿Cosas deberías saber antes de iniciar en el mundo de DevOps?

Javier Ledezma — Sun, 05 Jul 2020 23:45:07 +0000

Foto de bongkarn thanyakij en Pexels

DevOps es un término que está atrayendo cada vez mas a muchos programadores y administradores de sistemas y tiene mucho sentido, DevOps es una filosofía y conjunto de prácticas que nos permiten crear software escalable, delegando actividades como escuchar cambios en el código, construir nuestra aplicación y llevar nuestros cambios a producción a ciertas herramientas (también conocido como automatizar).

Y realmente nos podemos aventurar en aprender alguna herramienta que nos ayude a lograr dicho cometido, pero antes de comenzar, te recomendaría que te tomes un tiempo para entender ¿por qué necesitas aprender DevOps?.

Entendiendo el proceso de desarrollo de software

Los procesos de desarrollo de software suelen variar por cada proyecto, equipo o empresa, pero regularmente se apegan mucho a lo siguiente:

Creación del entorno de desarrollo.
Desarrollo de software.
Validación de calidad interna del código.
Construcción o empaquetamiento de aplicación.
Despliegue a producción.

Antes de DevOps

Creación del entorno de desarrollo

Todo proyecto de software requiere de un entorno de desarrollo, esto incluye la instalación de aplicaciones y servicios para que tu código pueda ser ejecutado, por ejemplo, motores de bases de datos, apache o nginx, firewalls, etc. En éste paso también se incluye la configuración de estas aplicaciones y servicios.

Para poder determinar qué requiere el entorno de desarrollo podríamos hacer una lista de todo aquello que se necesita instalar/configurar en una computadora recién salida de fabrica para nuestra aplicación pueda ejecutarse.

Desarrollo de software

Una vez que logramos echar a andar nuestra aplicación en nuestro entorno de desarrollo, solemos agregar funcionalidades, mejorar el rendimiento o corregir los errores encontrados en la aplicación.

Validación de calidad interna del código

Cada que un equipo de desarrollo (o desarrollador) completa un fragmento funcional de la aplicación, se realiza una revisión para saber si el código entregado por el equipo de desarrollo cumple con los estándares de calidad del proyecto, si cumple con los requerimientos y si no tiene errores.

Nota: En este paso también nos aseguramos de que la nueva funcionalidad no afecte el código que ya se encuentra funcionando.

Construcción o empaquetamiento de aplicación

En caso de que el código cumpla con todo lo necesario, entonces, una persona se encargaba de ejecutar en su computadora una serie de tareas para construir o empaquetar nuestra aplicación, tareas como instalar las dependencias del proyecto y construir un ejecutable (si es que se requería).

Nota: Cuando hablamos de dependencias del proyecto, nos referimos a las librerías propias del código, por ejemplo, librerías para manejar fechas, librerías para leer archivos CSV, etc.

Despliegue a producción

Finalmente se toma la construcción de nuestra aplicación (o empaquetado) y se realiza un proceso de despliegue, en el que colocamos nuestro producto final a disposición de nuestros clientes, nuevamente, los pasos para hacer despliegue pueden variar dependiendo de la aplicación, lenguaje, etc. Y cada uno de estos pasos era ejecutado por una persona encargada a través de una terminal ssh o mediante archivos de transferencia de archivos (FTP).

Problemas frecuentes

Una vez que conocemos el proceso por cual pasa una simple mejora de código, nos podemos percatar de que se requiere de demasiado esfuerzo, por ello, las empresas o equipos solían hacer despliegue de un grupo de mejoras cada cierto tiempo o cuando se cumplía cierto entregable.

A parte de que las entregas se tornaban lentas, si algo salía mal, se tenía que hechar para atrás todo el grupo de mejoras que se habían lanzado a producción.

Con DevOps

Creación del entorno de desarrollo

En vez de crear un entorno de desarrollo manualmente, se opta por utilizar herramientas como virtualización o contenedores para armar éstos entornos de desarrollo, de ésta manera, solo se crea un servicio para cada aplicación y éste servicio se instancía cada que sea necesario.

Ejemplos de herramientas con las que se logra esto: Docker, VMWare.

Desarrollo de software

Para este punto se suelen utilizar sistemas de versionamiento de archivos, como git o mercurial. Estas herramientas pueden ser configuradas para trabajar en conjunto con otros servicios que se encarguen de realizar automáticamente el despliegue a producción cada que se detecte un cambio.

En este paso se agrega una capa adicional y "obliga" a los desarrolladores a crear pruebas automatizadas para su código, cada que un desarrollador o equipo de desarrollo completa una funcionalidad, el código va acompañado de una serie de pruebas que se encargan de validar que el código cumple con su función.

Ejemplos de herramientas con la que se peude lograr esto: github, gitlab, bitbucket.

Validación de calidad interna del código

En éste paso, se obtienen los últimos cambios registrados en el sistema de versionamiento, y las herramientas se encargan de utilizar instanciar un contenedor o levantar una máquina virtual con el entorno de desarrollo, configurar el proyecto y ejecutar la suite completa de pruebas sobre los cambios detectados. Si algo llegara a salir mal, el proceso de despliegue se detiene aquí, de lo contrario procede a la construcción.

Ejemplos de herramientas con las que se logra esto: Jenkins, TravisCI, CircleCI.

Construcción o empaquetamiento de aplicación

Una vez asegurada la calidad del código se realiza una serie de pasos automatizados que se encargan de construir la aplicación, a través de comandos o de ciertos plugins de la herramienta de integración continua.

Ejemplos de herramientas con las que se logra esto: Jenkins, TravisCI, CircleCI.

Despliegue a producción

Las mismas herramientas de integración continua, nos permiten configurar los pasos necesarios para poder hacer un depliegue a producción, esto conlleva la preparación del entorno productivo, la configuración de las variables de entorno y la copia de archivos necesarios para poder tener nuestra aplicaicón disponible para nuestros usuarios.

Ejemplos de herramientas con las que se logra esto: Jenkins, TravisCI, CircleCI.

Conclusión

DevOps requiere de una configuración muy fuerte al incio para poder automatizar todo el proceso, sin embargo, una vez configurada nos permite realizar despliegues mucho más confiables, haciendo que cada entrega se puede realizar de manera independiente y no requiera de esperar a una fecha para desplegar un grupo de cambios

A demás, en caso de error, solamente se regresaría ese último cambio desplegado.

Nota: Te recomiendo no implementar DevOps si no conoces el proceso completo de desarrollo de tu proyecto, ya que DevOps no es una receta única, se debe crear y configurar acorde a las necesidades de cada proyecto.

Te invito a que analices el proceso actual de desarrollo de tu empresa o tu proyecto siguiendo los pasos que te comenté en éste post.

Si tienes dudas de como iniciar a automatizar con alguna herramienta, deja tu inquietud en un comentario y te pasaré algún recurso de utilidad, al igual si ya tienes experiencia en DevOps cuentanos de ella y finalmente, si tienes algún comentario o sugerencia, siempre serán bienvenidos.

¡Hasta la próxima!