Eventually, I acquired the Glove80, which is some kind of 80% keyboard. And the difference is abysmal. The first experience with the Keychron was great, but IMHO, currently it feels overpriced. There still are good keyboards.

But Glove80 and other ergo keyboards are in a different category, not only in price but in a more important field: ergonomics. Using a Keychron without a palm rest is (at least for me) impossible. But the feeling of split keyboards is another thing. These are the main characteristics that made the Glove80 one of the best:

• Mechanical: Great for longevity and reliability.
• Split: The best setup for ergonomics—be gentle with your wrists. Palm rest is included.
• Low profile: This, alongside red switches or similar, reduces the fatigue of long writing sessions.
• Concave key wells and columnar layout reduces the effort of fingers to reach distant keys.
• Tenting: Adding some degree of tenting reduces pronation, improving the comfort of forearms and wrists.
• ZMK firmware: Use whatever layout you want, including different layers, modifiers, etc. No more Karabiner configs for me.

A side effect of using the Glove80 is that I had to learn touch typing. I learned to type in an empiric manner; this leads me to have several vices. Using a split columnar keyboard makes these problems even more apparent. It’s funny how this design enforces you to press a key with the correct finger. It somehow forces you to type correctly. This, in turn, improved my typing speed.

I’m far from the big numbers like 100 wpm, but I think ~70 wpm it’s a pretty decent number.

Finally, it is much less noisy than regular mechanical keyboards.

This marks a turning point in my experience with keyboards. I will definitely not go back to conventional keyboards. These are expensive keyboards, but they are investments. In comfort and health. Much cheaper in the long run.

If you are curious about my layout config, here is: Glove80 ZMK layout config.s

La mentalidad sobre las pruebas automatizadas

No soy capaz de recordar una sola mención sobre pruebas automatizadas durante mi paso por la universidad. No fue, sino la búsqueda de información sobre “buenas prácticas” lo que me llevo a conocer sobre este tema.

A pesar de leer sobre sus beneficios y creer en ellos, no era capaz de materializarlo en código. Tenía una desconexión entre la teoría y la practica. Además de una carencia fundamental de entendimiento, acepte lo que otros decían sobre los beneficios del testing sin realmente comprender e interiorizar dichos beneficios, era una creencia mecánica.

Durante mis primeras experiencias profesionales trabajé en proyectos y empresas donde escribir pruebas no era parte del trabajo, por lo que ningún miembro del equipo escribió una sola prueba. Incluyéndome por supuesto. Introducir el mismo error múltiples veces era algo común.

Eventualmente, llegué a una compañía donde era necesario escribir pruebas. Si bien “creía” en los beneficios de escribir pruebas, era una simple repetición de algún argumento que leí en algún lugar. Realmente no entendía por qué eran importantes. No había experimentado sus beneficios.

Así que, las primeras semanas o quizás meses, escribir pruebas se sentía como hacer el trabajo dos veces. Ya terminé mi funcionalidad y “funciona” en mi computadora. ¿Por qué debería escribir más código para algo que ya sé que funciona?

Hasta que un día, realizando un cambio aparentemente sencillo, y a modo de simple comprobación, ejecute la suite de pruebas con total convencimiento de que nada cambiaria. Había realizado un trabajo perfecto.

Pero una de las pruebas dijo lo contrario. Una prueba estaba fallando, en una funcionalidad que ni siquiera estaba modificando. ¿Cómo es posible que una prueba de una funcionalidad “no relacionada” este fallando?

Una rápida inspección de la prueba fallida, y del módulo que estaba probando me dio la respuesta. Había codigo que se reutilizaba en ambos módulos y yo había cambiado su comportamiento.

Me tomo menos de un minuto hacer el cambio necesario para que funcionara en ambos lugares. Las pruebas automatizadas me salvaron de introducir un error de manera inadvertida, en un cambio que yo consideraba trivial.

Fue en ese momento, que mi mentalidad cambio. Y de pronto escribir pruebas, nunca más se sintió como trabajar dos veces, se volvió parte natural del ciclo de desarrollo. Escribir una nueva funcionalidad y las respectivas pruebas ahora son partes de la misma actividad.

Sin mencionar que el tiempo que me toma desarrollar algo nuevo no cambio, a pesar de que la intuición nos lleva a pensar que al implicar trabajo extra, implica, por lo tanto, tiempo extra. Sin embargo, al menos en mi experiencia, este trabajo extra se ve compensado por el hecho de que mantener una batería de pruebas saludable ayuda a mantener la velocidad de desarrollo conforme el proyecto se vuelve más grande, los requerimientos cambian y se introducen nuevas funcionalidades.

Aunque es cierto que en proyectos legacy, tratar de incluir pruebas es mucho mas dificil debido a la complejidad y deuda tecnica acumulada. Suele dar mejores resultados utilizar tecnicas para trabajar con codigo legado y agregar pruebas al codigo nuevo, desplazando poco a poco el codigo anterior mas dificil de probar.

Pirámide de pruebas

La pirámide de pruebas¹ es un concepto muy debatido. Habla sobre los distintos niveles de pruebas que podemos incluir, desde las pruebas unitarias hasta las pruebas e2e (end to end). Con un número increíble de tipos de pruebas entre estos dos niveles.

Uno de los puntos de debate es que tantas pruebas de cada tipo necesitamos, al mismo tiempo que buscamos mantener una batería de pruebas rápida y confiable.

Mientras que las pruebas unitarias son rápidas de escribir y ejecutar, no suelen proveer retroalimentación de como el usuario usa nuestro software. Aunque claro, se puede hablar horas sobre que tan unitario es lo unitario².

En cambio, las pruebas e2e, si bien prueban flujos completos tal cual lo haría un usuario, son muy caras de escribir y ejecutar. Sobre todo en los tiempos de Microservicios o aplicaciones separadas para el backed y el frontend. Al grado que algunas empresas han decidido abandonar este tipo de pruebas. ³

Lo importante, como menciona Kent Beck ⁴ es escribir el menor número de pruebas necesarias, para alcanzar el nivel de confianza requerido en nuestro proyecto.

La confianza de que al realizar un cambio y mis pruebas estén en verde todo se sigue comportando como se espera o, por el contrario, si alguna prueba está en rojo, algo cambio.

Esta confianza, ademas, nos ayuda a integrar cambios más rápido. Lo que a su vez nos permite reducir el riesgo de cada cambio y cada nueva funcionalidad introducida.

Nos da la confianza para entregar software lo más rápido posible.

En general encuentro que las pruebas de integración y las pruebas unitarias sociables hacen un gran trabajo brindando esa confianza que buscamos. Por lo que suelo escribirlas más, incluyendo aquellas que atacan a una base de datos de pruebas. Prefiriendolas sobre pruebas unitarias solitarias que aíslan completamente los colaboradores y otros subsistemas como la base de datos.

Si bien atacar directamente a una base de datos real puede ralentizar la ejecución de nuestras pruebas. Hoy en día bases de datos como Postgres soportan la ejecución concurrente de pruebas ⁵ y hay servidores de CI sofisticados capaces de paralelizar la ejecución de una masiva bateria de pruenas⁶. De otra forma, no podríamos verificar el esquema o las restricciones en nuestra base de datos.

Sin embargo, esto puede enfrentarse a sus límites (aunque cada vez mas lejanos) en sistemas muy grandes y complejos. Hay proyectos que pueden tomar horas en correr en el pipeline de CI por la gran cantidad de pruebas que tienen.

Un caso especial son los sistemas de terceros, como una API REST externa. En cuyo caso suelo recurrir al uso de mocks y stubs.

Mocks

WIP

Refactorización

WIP

Confianza

WIP

TDD

Test Driven Development es de esas cosas de las que se lee mucho, pero se ve poco en la practica, o al menos en mi experiencia personal. Seguramente hay empresas y lugares donde es una practica comun, pero no he podido verlo de primera mano.

Al inicio, escribir una prueba antes de saber si quiera como se va a llamar nuestra clase o modulo puede parecer carente de sentido. Aun no sabemos como va a lucir ese código, como podria comenzar escribiendo una prueba? Es algo contraintuitivo.

Pero es precisamente este ejercicio, el que nos empuja a pensar en el diseño del codigo y su interfaz, por adelantado en lugar de hacerlo reaccionando a nuestro intento inicial.

Eh encontrado que es mas facil iniciar con TDD al resolver un bug. Cuando se reporta un bug, primero se escribe una prueba que reproduzca el error, entonces debugueas y corrijes el error. Si la prueba pasa efectivamente se corrijio el error. Ademas esto garantiza que no se vuelva a introducir el mismo error en el futuro.

De esta forma es mas sencillo adoptar el pensamiento de escribir primero la prueba. Un cambio de pensamiento que es incomodo al principio, porque implica dejar de hacer las cosas de la forma en la que estamos acostumbrados.

Lo relaciono al tipo de incomodidad que se experimenta la primera vez que trabajas con un lenguaje funcional si vienes de lenguajes orientados a objetos. Cuando comienzas a experimentar caracteristicas como la inmutabilidad, es extraño, no es “intuitivo”. Eso no significa que sea malo, o mas dificil. Pero es diferente y hay que acostumbrarse y adapar nuestra forma de pensar.

Cuando comenzamos a hacer algo nuevo siempre es dificil al principio. Solo se supera practicando. Como dicen: La frecuencia reduce la dificultad ⁷.

Otro uso util de TDD y las pruebas en general es que ayudan al diseño del código. Al menos de manera indirecta. No es que te digan como diseñar tu código, pero escribir una prueba hace emerger los smell codes del diseño en forma de un setup complejo, o dificultad para probar el comportamiento buscado.

Si una prueba es dificil de escribir, significa que el código es dificil de probar. Si es dificil de probar probablemente es porque hace demasiadas cosas o tiene demasiadas dependencias o alguno de los tantos code smells existentes. Es decir, podemos mejorar el diseño de ese código.

Como con cualquier práctica hay promotores y detractores. Aunque soy un promotor, lo trato como cualquier regla o principio:

“Every rule has its exceptions, and every principle has its limits”

Esta frase del libro A Philosophy of Software Design siempre me recuerda que hay que desarrollar criterio para aplicar cualquier herramienta o pieza de conocimiento. Tanto para tener cautela, como para desafiar el “estatus quo”.

Integración continua

WIP

ReplicaSet

El objeto de un ReplicaSet es el de mantener un conjunto estable de réplicas de Pods ejecutándose en todo momento. Así, se usa en numerosas ocasiones para garantizar la disponibilidad de un número específico de Pods idénticos.

Como vemos, los objetos ReplicaSet nos permiten realizar escalamiento horizontal de nuestros pods. Dicho esto, lo más común es no manejar directamente nuestros ReplicaSets, si no hacerlo mediante un Deployment Controller, ya que esto nos da varias conveniencias.

Deployment

Un controlador de Deployment proporciona actualizaciones declarativas para los Pods y los ReplicaSets.

Cuando describes el estado deseado en un objeto Deployment, el controlador del Deployment se encarga de cambiar el estado actual al estado deseado de forma controlada. Puedes definir Deployments para crear nuevos ReplicaSets, o eliminar Deployments existentes y adoptar todos sus recursos con nuevos Deployments.

Definiendo un Deployment

Ahora veamos como definir un deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Una particularidad que tenemos en este caso respecto a los ejemplos previos es el uso de template. Esto es debido a que un objeto puede definir a su vez otros objetos.

En este ejemplo, primero definimos un objeto de tipo Deployment, pero también debemos definir el ReplicaSet, que a su vez debe definir el Pod. Todo debe ir en la jerarquía correcta.

Veamos los pasos del deplyment.yml:

• Primero definimos un objeto de tipo Deployment con el nombre nginx-deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx

• Definimos el numero de replicas mediante replicas,
• El campo selector.matchLabels.app identifica los pods que debe gestionar. Por lo que debe coincidir con el label del pod.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx

• Finalmente definimos el pod mediante el campo template. Utilizando el label nginx
• Con el campo spec definimos el contenedor que ejecutara el pod, el nombre y la imagen.
• Ademas abrimos el puesto 80

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Ahora creamos nuestro deployment:

▶ kubectl apply -f deployment.yml
deployment.apps/nginx-deployment created

Si obtenemos los pods de nuestro cluster, veremos que ya 3 ejecutandose al mismo tiempo:

▶ kubectl get pods
NAME                               READY   STATUS    RESTARTS   AGE
nginx-deployment-d556bf558-bq846   1/1     Running   0          58s
nginx-deployment-d556bf558-h4qc5   1/1     Running   0          58s
nginx-deployment-d556bf558-pw87w   1/1     Running   0          58s

ConfigMaps

Un ConfigMap es un objeto que se utiliza para almacenar datos no confidenciales en pares clave-valor. Los pods pueden utilizar ConfigMaps como variables de entorno, argumentos de línea de comandos o como archivos de configuración en un volumen.¹

De esta forma no es necesario depender de archivos .env o similares para inyectar variables de entorno a nuestra aplicación.

Dado que los ConfigMaps no proveen ningún tipo de cifrado, no deben ser utilizados para almacenar información sensible como tokens, passwords, etc.

Secrets

Un secreto es un objeto que contiene una pequeña cantidad de datos confidenciales, como una contraseña, un token o una clave. De lo contrario, dicha información podría incluirse en una especificación de pod o en una imagen de contenedor. El uso de un secreto significa que no necesita incluir datos confidenciales en el código de su aplicación.²

Creando un objeto ConfigMap

Para esto, vamos a crear un nuevo archivo configmap.yml para crear nuestro objeto de tipo ConfigMap.

apiVersion: v1
kind: ConfigMap
metadata:
  name: myconfigmap
data:
  APP_NAME: myapp
  APP_ENV: development

Como vemos, a diferencia del yml para crear nuestro pod, usamos la llave data, para definir nuestros valores.

Y procedemos a crear el objeto:

▶ kubectl apply -f configmap.yml
configmap/myconfigmap created

Ahora, para poder usarlo en nuestros pods, debemos hacer referencia a el y recrear el pod.

apiversión: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    envFrom:
    - configMapRef:
        name: myconfigmap

Primero eliminamos el pod existente y posteriormente lo creamos nuevamente:

▶ kubectl delete -f pod.yml
pod "mypod" deleted

▶ kubectl apply -f pod.yml
pod/mypod created

Ahora, podemos entrar a nuestro pod mediante su nombre y verificar que podemos leer las variables de entorno:

▶ kubectl exec -it mypod -- bash
root@mypod:/# echo $APP_NAME
myapp
root@mypod:/# echo $APP_ENV
development
root@mypod:/#

Creando un objeto Secret

Para gestionar secrets es muy parecido, pero son un tipo distinto de objeto, por lo que ahora crearemos un archivo secrets.yml:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4K # admin
  password: cGFzc3dvcmQK # password

Una peculiaridad es que en lugar de ir en texto plano, deben estar en base64.

Ahora modificamos nuestro pod.yml:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    envFrom:
    - configMapRef:
        name: myconfigmap
    env:
    - name: USERNAME
      valueFrom:
        secretKeyRef:
          name: mysecret
          key: username
    - name: PASSWORD
      valueFrom:
        secretKeyRef:
          name: mysecret
          key: password

Agregamos al spec la llave env. Donde por cada secret definimos:

• name: Con este name podremos acceder al secret como variable de entorno en nuestro pod
• valueFrom.name: el nombre que le dimos a nuestro objeto Secret (mysecret)
• valueFrom.name.key: la llave que usamos en secrets.yml para definir el secret, en este caso username y password

Ahora realizamos el mismo proceso, eliminar y crear nuevamente nuestro pod:

▶ kubectl delete -f pod.yml
pod "mypod" deleted

▶ kubectl apply -f pod.yml
pod/mypod created

Finalmente, entramos nuevamente a nuestro pod y podremos acceder a nuestros secrets como variables de entorno:

▶ kubectl exec -it mypod -- bash
root@mypod:/# echo $USERNAME
admin
root@mypod:/# echo $PASSWORD
password
root@mypod:/#

Es decir, si tienes una plataforma que requiere confiabilidad y escalabilidad (entre otras) y que se empaqueta como imágenes de Docker. Kubernetes te permite administrar tu plataforma mediante diversas herramientas.

Componentes

Tenemos tres grandes conceptos: los clusters, el Control Plane y los nodos ¹

El control plane se encarga de gestionar las tareas relacionadas al cluster, como guardar metadatos sobre los nodos, decidir en que nodo crear los nuevos pods, verificar la salud de los nodos, etc.

Generalmente, dado que se suelen usar servicios administrados como EKS, solemos interactuar poco de manera directa con el Control Plane

En los nodos tenemos el runtime de los contenedores (como containerd), kubelete que verifica y notifica al control plane mediante el kube-apiserver la salud de los pods, etc.

Finalmente los pods que se ejecutan dentro de los nodos donde cada nodo puede tener múltiples pods corriendo al mismo tiempo.

Objetos

Los objetos son entidades persistentes. Son utilizadas para representar el estado del clúster ². Estos son los pods, los deployments, los controllers, etc. Los objetos y los nodos son los elementos con los que más solemos interacturar.

Por otro lado, tenemos dos formas de gestionar los objetos: la primera es mediante la CLI kubectl (imperativa) y mediante archivos de configuración YML (declarativa).

Creando nuestro primer cluster

Para propósitos de aprendizaje vamos a utilizar la herramienta kind³, que nos permite crear clusters de manera local. Aunque hay otras como minikube⁴ o el mismo Docker Desktop⁵. Al igual que necesitamos instalar la herramienta kubectl⁶.

Ademas debemos tener instalado Docker⁶.

MacOS:

# kind
brew install kind

# kubectl
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl"

Ubuntu:

# kind
#!/bin/bash

# For AMD64 / x86_64
[ $(uname -m) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.20.0/kind-linux-amd64
chmod +x ./kind
sudo cp ./kind /usr/local/bin/kind
rm -rf kind

# kubectl
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

Ahora podemos ejecutar el siguiente comando, lo que creara nuestro primer cluster con el nombre kind:

▶ kind create cluster
Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.31.2) 🖼
 ✓ Preparing nodes 📦
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹️
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
Set kubectl context to "kind-kind"
You can now use your cluster with:

kubectl cluster-info --context kind-kind

Have a question, bug, or feature request? Let us know! https://kind.sigs.k8s.io/#community 🙂

Si revisamos los contenedores que se están ejecutando veremos uno para el control plane del cluster, y cuando tengamos nodos veremos un contenedor por cada nodo o worker.

▶ docker ps | grep "kind"
695e351dd59d   kindest/node:v1.31.2    "/usr/local/bin/entr…"   About a minute ago   Up About a minute      127.0.0.1:58969->6443/tcp                                                kind-control-plane

Ahora podemos definir un objeto pod, mediante el enfoque declarativo en un archivo pod.yml:

apiversión: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: nginx
    image: nginx:latest

Aquí tenemos la versión mínima para definir nuestro objeto pod:

• La versión del api
• kind para definir el tipo de objeto
• metadata donde definimos el nombre de nuestro pod
• spec donde definimos cosas como los contenedores que se van a ejecutar, si definimos volúmenes, etc.

Ahora aplicamos los cambios con kubectl:

▶ kubectl apply -f pod.yml
pod/mypod created

Por lo que si ahora obtenemos los pods de nuestro cluster veremos el nuevo pod creandose:

▶ kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
mypod   1/1     Running   0          14s

Por el momento no acceder al nginx del pod ya que no esta expuesto, para propósitos de debug podemos hacer port-forward a un puerto en nuestra maquina local para poder verificar que efectivamente hay un nginx ejecutandose:

▶ kubectl port-forward pod/mypod 8888:80
Forwarding from 127.0.0.1:8888 -> 80
Forwarding from [::1]:8888 -> 80

Ahora podemos visitar localhost:8080 y ver el mensaje de bienvenida de Nginx

▶ curl http://localhost:8888
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Con esto vimos algunos conceptos básicos y creamos nuestro primer pod :D.

Para esto los pipelines con verificaciones de calidad y conformidad ejecutados por un servidor de integración continua se volvieron una parte fundamental. Al permitirnos verificar, al menos hasta cierto punto que los cambios que estamos integrando cumplen con los criterios establecidos.

Elixir tiene lo propio y hoy en día contamos con diversas herramientas que nos permiten automatizar diversos aspectos de nuestro código, ponerlos en un pipeline y ejecutarlos automáticamente en cada confirmación.

Por otro lado, me gustaría aprovechar la oportunidad para poner todo este pipeline en un solo script, de forma que podamos utilizarlo fácilmente tanto en desarrollo como en el servidor de CI.

Lo primero es configurar la opción preferred_envs en nuestro archivo mix.exs para no tener que incluir MIX_ENV=test en cada tarea.

def cli do
  [
    preferred_envs: [ci: :test]
  ]
end

Ademas de incluir un alias en el mismo archivo mix.exs para ejecutar nuestra tarea mediante mix ci.

defp aliases do
  [
    # ... otros aliases
    ci: ["CI"]
  ]
end

Ahora creamos nuestro archivo lib/mix/tasks/ci.ex y comenzamos a escribir nuestra tarea.

defmodule Mix.Tasks.CI do
  @moduledoc """
  Run all the checks and tests for the project
  """
  use Mix.Task

  @preferred_cli_env :test

  @impl Mix.Task
  def run(_args) do
   ...
  end
end

Verificaciones de las dependencias

El primer paso de nuestro pipeline es obtener las dependencias.

Podemos verificar nuestro archivo mix.exs por dependencias que han sido retiradas utilizando la tarea mix hex.audit, de forma que podamos reemplazarlas.

Despues, por defecto, contamos con la tarea deps.unlock --check-unused que verifica que no incluyamos dependencias en nuestro archivo mix.exs que no estén siendo utilizadas.

Además, la dependencia mix_audit nos permite escanear las dependencias en busca de vulnerabilidades reportadas con la tarea mix deps.audit.

De forma que podemos incluirlas en nuestro archivo de CI:

defmodule Mix.Tasks.CI do
  @moduledoc """
  Run all the checks and tests for the project
  """
  use Mix.Task

  @preferred_cli_env :test

  @impl Mix.Task
  def run(_args) do
    Mix.Task.run("deps.get")

    Mix.Task.run("cmd", ["MIX_ENV=dev", "mix hex.audit"])

    Mix.Task.run("deps.unlock", ["--check-unused"])

    Mix.Task.run("deps.audit", ["--format", "human"])
  end
end

Verificaciones del compilador

Elixir incluye un argumento muy útil llamado --warnings-as-errors. Lo que nos permite tratar las advertencias del compilador como errores, por lo que no nos permitirá avanzar hasta que sean resueltas.

Aunque personalmente me gusta activar esta opción dentro del archivo mix.exs, haciendo que esto funcione todo el tiempo. Algunas personas consideran esta opción algo intrusiva¹, ya que suele crear fricción durante el desarrollo al detener el flujo, por ejemplo por olvidar un _ en una variable que no usamos en ese momento.

Aunque existe una incomodidad inicial, encuentro que esta fricción desaparece después de un corto periodo de adaptación, volviéndonos más disciplinados al escribir código. Sin embargo, considero indispensable que esta opción esté activa (al menos) en el servidor de CI.

De otra forma, nuestra consola estará plagada de advertencias que dificultan la lectura de lo que es realmente importante.

defmodule Mix.Tasks.CI do
  @moduledoc """
  Run all the checks and tests for the project
  """
  use Mix.Task

  @preferred_cli_env :test

  @impl Mix.Task
  def run(_args) do
    Mix.Task.run("deps.get")

    Mix.Task.run("cmd", ["MIX_ENV=dev", "mix hex.audit"])

    Mix.Task.run("deps.unlock", ["--check-unused"])

    Mix.Task.run("deps.audit", ["--format", "human"])

    Mix.Task.run("compile", ["--warnings-as-errors"])
  end
end

Verificaciones de formato

Elixir cuenta con una herramienta mix format que nos permite formatear nuestro código de forma automática. Sin embargo, no es raro que se nos olvide formatear nuestro código antes de confirmar, por lo que podemos incluirlo en nuestro script.

Por otro lado, también podemos incluir Credo, una herramienta de análisis estático que nos permite verificar la calidad de nuestro código. Cuenta con muchas reglas que podemos configurar o desactivar, incluso podemos crear nuestras propias reglas. Aunque no todas vienen activadas por defecto, por lo que vale mucho la pena revisar al documentación a fondo.

Ademas credo cuanta con un modo estricto que podemos activar con la opción --strict que nos permite ver todas las reglas sin importar su prioridad.

defmodule Mix.Tasks.CI do
  @moduledoc """
  Run all the checks and tests for the project
  """
  use Mix.Task

  @preferred_cli_env :test

  @impl Mix.Task
  def run(_args) do
    Mix.Task.run("deps.get")

    Mix.Task.run("cmd", ["MIX_ENV=dev", "mix hex.audit"])

    Mix.Task.run("deps.unlock", ["--check-unused"])

    Mix.Task.run("deps.audit", ["--format", "human"])

    Mix.Task.run("compile", ["--warnings-as-errors"])

    Mix.Task.run("format", ["--check-formatted"])

    Mix.Task.run("credo", ["--strict"])
  end
end

Verificaciones de tipado

Elixir es un lenguaje de tipado dinámico, por lo que si bien tenemos opciones como las anotaciones de tipos y las especificaciones de tipos, estas no son verificadas por el compilador. Sin embargo, podemos utilizar dialyxir o alguna de sus alternativas² para verificar el tipado de nuestro código.

defmodule Mix.Tasks.CI do
  @moduledoc """
  Run all the checks and tests for the project
  """
  use Mix.Task

  @preferred_cli_env :test

  @impl Mix.Task
  def run(_args) do
    Mix.Task.run("deps.get")

    Mix.Task.run("cmd", ["MIX_ENV=dev", "mix hex.audit"])

    Mix.Task.run("deps.unlock", ["--check-unused"])

    Mix.Task.run("deps.audit", ["--format", "human"])

    Mix.Task.run("compile", ["--warnings-as-errors"]

    Mix.Task.run("format", ["--check-formatted"])

    Mix.Task.run("credo", ["--strict"])

    Mix.Task.run("dialyzer")
  end
end

Verificaciones de migraciones

La biblioteca excellent_migrations nos permite revisar las migraciones en busca de operaciones que puedan ser problemáticas. Creo que es una herramienta muy útil para evitar problemas en producción.

Otra verificación útil que podemos agregar es que las migraciones sean reversibles. Como menciona Saša Jurić³

defmodule Mix.Tasks.CI do
  @moduledoc """
  Run all the checks and tests for the project
  """
  use Mix.Task

  @preferred_cli_env :test

  @impl Mix.Task
  def run(_args) do
    Mix.Task.run("deps.get")

    Mix.Task.run("cmd", ["MIX_ENV=dev", "mix hex.audit"])

    Mix.Task.run("deps.unlock", ["--check-unused"])

    Mix.Task.run("deps.audit", ["--format", "human"])

    Mix.Task.run("compile", ["--warnings-as-errors"])

    Mix.Task.run("format", ["--check-formatted"])

    Mix.Task.run("credo", ["--strict"])

    Mix.Task.run("dialyzer")

    Mix.Task.run("ecto.create")

    Mix.Task.run("excellent_migrations.migrate")

    Mix.Task.run("ecto.rollback", ["--all"])
  end
end

Verificaciones de pruebas

Después de las verificaciones anteriores, ahora podemos ejecutar nuestras pruebas. Adicionalmente, podemos incluir la opción --cover para verificar la cobertura de nuestras pruebas y la opción --warnings-as-errors para tratar las advertencias como errores.

defmodule Mix.Tasks.CI do
  @moduledoc """
  Run all the checks and tests for the project
  """
  use Mix.Task

  @preferred_cli_env :test

  require Logger

  @impl Mix.Task
  def run(_args) do
    Mix.Task.run("deps.get")

    Mix.Task.run("cmd", ["MIX_ENV=dev", "mix hex.audit"])

    Mix.Task.run("deps.unlock", ["--check-unused"])

    Mix.Task.run("deps.audit", ["--format", "human"])

    Mix.Task.run("compile", ["--warnings-as-errors"])

    Mix.Task.run("format", ["--check-formatted"])

    Mix.Task.run("credo", ["--strict"])

    Mix.Task.run("dialyzer")

    Mix.Task.run("ecto.create")

    Mix.Task.run("excellent_migrations.migrate")

    Mix.Task.run("ecto.rollback", ["--all"])

    Mix.Task.run("test", ["--cover", "--warnings-as-errors"])
  end
end

También podemos incluir algunos mensajes para proveer algo de información sobre lo que está sucediendo.

defmodule Mix.Tasks.CI do
  @moduledoc """
  Run all the checks and tests for the project
  """

  @preferred_cli_env :test

  use Mix.Task

  require Logger

  @impl Mix.Task
  def run(_args) do
    Logger.info("Getting dependencies", ansi_color: :cyan)

    Mix.Task.run("deps.get")

     Logger.info("Checking for retired dependencies", ansi_color: :cyan)

    Mix.Task.run("cmd", ["MIX_ENV=dev", "mix hex.audit"])

    Logger.info("Checking unused dependencies", ansi_color: :cyan)

    Mix.Task.run("deps.unlock", ["--check-unused"])

    Logger.info("Checking for reported vulnerabilities", ansi_color: :cyan)

    Mix.Task.run("deps.audit", ["--format", "human"])

    Logger.info("Compiling code", ansi_color: :cyan)

    Mix.Task.run("compile", ["--warnings-as-errors"])

    Logger.info("checking formatting", ansi_color: :cyan)

    Mix.Task.run("format", ["--check-formatted"])

    Logger.info("Running credo", ansi_color: :cyan)

    Mix.Task.run("credo", ["--strict"])

    Logger.info("Running dialyzer", ansi_color: :cyan)
    
    Mix.Task.run("dialyzer")

    Logger.info("Creating test database", ansi_color: :cyan)

    Mix.Task.run("ecto.create")

    Logger.info("Checking for migrations", ansi_color: :cyan)

    Mix.Task.run("excellent_migrations.migrate")

    Logger.info("Checking for reversibility of migrations", ansi_color: :cyan)

    Mix.Task.run("ecto.rollback", ["--all"])

    Logger.info("Running tests", ansi_color: :cyan)

    Mix.Task.run("test", ["--cover", "--warnings-as-errors"])
end

Esta tarea es una referencia, dependiendo del proyecto o el equipo podemos agregar o eliminar verificaciones. Otro aspecto es que probablemente llegue un punto en el que ejecutar todo el pipeline en local sea demasiado lento, por lo que podemos crear una tarea destinada a ser ejecutada en local con las verificaciones más importantes y dejar el pipeline completo para el servidor de CI.

• Infraestructura: Lo que conecta nuestra capa de aplicación con la entrada y salida de información: base de datos, HTTP, message’s queues, etc.
• Aplicación: Donde residen nuestros casos de uso
• Dominio: Aquí encontramos cosas como nuestras entidades

Por que puertos y adaptadores?

Podemos decir que los puertos son las interfaces de entrada y salida de nuestra aplicación. Una API JSON, un consumidor de un Message Queue, etc.

Por su parte, los adaptadores conectan nuestra lógica de negocio para que pueda ser consumida o ejecutada por otros actores (usuarios o sistemas).

Digamos que un controlador es un adaptador.

¿Cómo se reflejan estas capas en una aplicación típica de Phoenix?

Nuestros schemas como el de user son parte del dominio.

Mientras que los context modules como el de accounts podríamos decir que forman parte de la capa de aplicación.

Finalmente, lo que está contenido en app_web/ formaría parte de la capa de infraestructura, al igual que el modulo repo y el mailer.

Capa de dominio

¿Cómo modelamos la capa de dominio?

Respuesta corta: Usamos Domain-Driven Design (DDD) para descubrir los subdominios del negocio y diseñar bounded contexts. Chris McCord abordo este tema en su keynote en la ElixirConf 2017¹:

app/
├─ ecommerce/
│  ├─ accounts/
│  │  ├─ schemas/
│  │  │  ├─ user.ex
│  │  │  ├─ user_token.ex
│  │  ├─ accounts.ex
│  ├─ catalog/
│  │  ├─ schemas/
│  │  │  ├─ category
│  │  │  ├─ product.ex
│  │  ├─ catalog.ex
│  ├─ shopping_cart/
│  │  ├─ schemas/
│  │  │  ├─ cart.ex
│  │  │  ├─ cart_item.ex
│  │  ├─ shopping_cart.ex
├─ backoffice/
│  ├─ support/
│  │  ├─ schemas/
│  │  │  ├─ ticket.ex
│  │  ├─ tickets.ex
├─ app_web/
│  ├─ controllers/
│  │  ├─ ecommerce/
│  │  │  ├─ product_controller.ex
│  │  │  ├─ category_controller.ex
│  │  ├─ backoffice/
│  │  │  ├─ ticket_controller.ex
│  │  │  ├─ product_controller.ex
│  │  │  ├─ category_controller.ex
├─ README.md

En este ejemplo hay dos grandes contextos: ecommerce y backoffice. Pero eso no significa que no puedan surgir más, como marketing, ventas, etc.

A su vez, tanto ecommerce como backoffice contienen el directorio schemas/ (dominio) y un context module (aplicación): API’s públicas para interactuar con los esquemas.

Esta separación en contextos nos permite aumentar la cohesión de nuestro código. Al tener todos los conceptos relacionados cerca: usuario y token, producto y categoría, etc. Mientras que como veremos más adelante, tener una capa de aplicación nos permite reducir el acoplamiento, al separar los casos de uso de quien los llama, sea una interfaz de usuario o una interfaz para sistemas externo.

Una pregunta que puede surgir es: ¿Por qué tenemos un product_controller.ex tanto en ecommerce como en backoffice?

Porque una entidad no necesariamente significan lo mismo en distintos contextos. Un producto puede diferir en algunas características para un cliente en ecommerce que para un usuario interno en el backoffice.

Un lead puede ser apenas un registro en un formulario para marketing, mientras que para ventas es alguien que paso por el embudo de ventas, conteniendo mucha más información.

Capa de aplicación

Tener una capa de aplicación nos permite tener límites bien definidos acerca de cómo acceder a la lógica de negocio. Registro, Login, etc.

Los generadores de Phoenix crean context modules que podríamos considerar como nuestra capa de aplicación. Por ejemplo Accounts.

app/
├─ ecommerce/
│  ├─ accounts/
│  │  ├─ accounts.ex
│  ├─ catalog/
│  │  ├─ catalog.ex
│  ├─ shopping_cart/
│  │  ├─ shopping_cart.ex
├─ backoffice/
│  ├─ support/
│  │  ├─ tickets.ex
├─ app_web/
├─ README.md

Son la API publica para interactuar con nuestros esquemas de ecto.

Si quisiéramos introducir nuevos casos de uso podemos hacer algo como lo siguiente.

Vamos a crear un nuevo directorio services

app/
├─ ecommerce/
│  ├─ accounts/
│  │  ├─ services/
│  │  │  ├─ user_creator.ex
...

services es basicamente un service layer:

Defines an application’s boundary with a layer of services that establishes a set of available operations and coordinates the application’s response in each operation.

Es una forma de encapsular nuestros casos de uso, en este caso crear un usuario.

El módulo user_creator.ex es el que define las operaciones y coordina la respuesta, siguiendo el patrón ThingDoer-do_thing.

defmodule App.Ecommerce.Accounts.UserCreator do
  alias App.Ecommerce.Accounts
  alias App.Ecommerce.Accounts.User

  alias App.Ecommerce.Accounts.ConfirmationEmailJob
  alias App.Ecommerce.Accounts.UserEmail
  alias App.Mailer


  def create_user(email, password) do
    with {:ok, user} <- Accounts.create_user(email, password),
         {:ok, _job} <- ConfirmationEmailJob.enqueue(user) do
      {:ok, user}
    end
  end

  def send_confirmation_email(%User{} = user) do
    email = UserEmail.confirmation(user)

    Mailer.deliver(email)
  end
end

El patrón ThingDoer-do_thing nos permite evitar funciones genéricas y ambiguas como: call, run, o execute, haciendo que nuestro código comunique su comportamiento. Cabe mencionar que el módulo UserCreator no contiene lógica en sí mismo, sino que orquesta los módulos necesarios para cumplir con el caso de uso.

Otro beneficio del service layer es que proporciona una costura:

a seam is a place where you can alter behavior in your program without editing in that place

Si nuestra lógica de negocio acerca de crear usuarios cambia, dichos cambios no tendrán nada que ver con el controlador o el background job.

Capa de infraestructura

La responsabilidad de la capa de infraestructura es validar y normalizar la información que se recibe, de forma que la aplicación y el dominio puedan trabajar con ella.

Como nuestra capa de aplicación define las operaciones disponibles, estas se pueden reutilizar en distintos adaptadores, lo que permite que nuestra aplicación reciba información y responda en el formato adecuado sin importar de donde provenga, ya sea una API JSON, un background job, un Liveview, un evento de dominio, message queues, etc.

Infraestructura es otro nombre para lo que Saša Jurić llama Interfaz en su serie de artículos Towards Maintainable Elixir: The Core and the Interface.

En la sección anterior agregamos algunos modulos nuevos y sus respectivos directorios:

app/
├─ ecommerce/
│  ├─ accounts/
│  │  ├─ jobs/
│  │  │  ├─ confirmation_email_job.ex
│  │  ├─ emails/
│  │  │  ├─ user_email.ex
...

jobs Es un directorio para definir background jobs.

El módulo confirmation_email_job.ex es un background job para agregar confiabilidad al envío del email de confirmación.

emails Bibliotecas como swoosh nos permiten construir emails mediante funciones, de esta forma el módulo user_email.ex puede definir distintos tipos de emails relacionados con el usuario.

Por otro lado, los backgrounds jobs son parte de nuestra capa de infraestructura, por lo que evitamos definir lógica de negocio en ellos. En su lugar se comunican con la capa de aplicación por medio de nuestro service layer :D

defmodule App.Accounts.ConfirmationEmailJob do
  use Oban.Worker, queue: :default

  alias __MODULE__
  alias App.Ecommerce.Accounts
  alias App.Ecommerce.Accounts.UserCreator

  def enqueue(%{id: id} = args) do
    args
    |> ConfirmationEmailJob.new()
    |> Oban.insert()
  end

  @impl Oban.Worker
  def perform(%Oban.Job{args: %{"id" => user_id} = args}) do
    user = Accounts.get_user!(user_id)

    UserCreator.send_confirmation_email(user)
  end
end

Supongamos que nuestra aplicación es SSR por lo que nuestras respuestas son en HTML:

defmodule AppWeb.UserSchema do
  use Goal

  defparams :new do
    required :email, :string
    required :password, :string
  end
end

defmodule AppWeb.Ecommerce.UserController do
  use AppWeb, :controller

  alias AppWeb.UserSchema

  alias App.Ecommerce.Accounts.UserCreator

  def create(conn, %{"user" => user_params}) do
    with {:ok, attrs} <- validate(:new, user_params),
    {:ok, user} <- UserCreator.create_user(attrs.email, attrs.password) do
      {:ok, user} ->
        conn
        |> put_flash(:info, "User created successfully.")
        |> redirect(to: ~p"/users/#{user}")
    else ->
      {:error, %Ecto.Changeset{} = changeset} ->
        render(conn, :new, changeset: changeset)
    end
  end
end

Pero, ademas abrimos la posibilidad a que otras aplicaciones consuman nuestra lógica de crear usuarios mediante un API REST, donde nuestra respuesta es en formato JSON:

defmodule AppWeb.UserSchema do
  use Goal

  defparams :new do
    required :email, :string
    required :password, :string
  end
end

defmodule AppWeb.API.Ecommerce.UserController do
  use AppWeb, :controller

  alias AppWeb.UserSchema
  alias App.Ecommerce.Accounts.UserCreator

  action_fallback AppWeb.FallbackController

  def create(conn, %{"user" => user_params}) do
    with {:ok, attrs} <- validate(:new, user_params),
    {:ok, user} <- UserCreator.create_user(attrs.email, attrs.password) do
      conn
      |> put_status(:created)
      |> put_resp_header("location", ~p"/api/users/#{user}")
      |> render(:show, user: user)
    end
  end
end

Creo que se entiende la idea ;). El punto de entrada a nuestra lógica de negocio es el mismo y el código al rededor es acerca de como responder adecuadamente al formato solicitado.

En estos ejemplos el controlador recibe un mapa que puede contener campos desconocidos o puede haber campos faltantes. Usando la biblioteca Goal nos aseguramos que los campos que necesita nuestra capa de aplicación estén presentes y sean de un tipo correcto, además transforma las llaves a átomos :D.

Por lo que nuestro caso de uso no tendrá que lidiar con información invalida y como es convención en Phoenix, las reglas de negocio como que el email sea único y el password sea suficientemente largo se encuentran más cerca del dominio mediante Ecto Changesets.

Esto tiene la ventaja de que nos aseguramos que estas reglas se cumplan sin importar la interfaz de entrada.

Nótese que ninguno de los módulos contiene Schemas, .Services, .Emails o .Jobs, de la misma forma en que en Phoenix los controladores no llevan .Controllers.

Sería un poco raro ver un controlador App.Ecommerce.Controllers.UserController, de la misma forma evitamos cosas como App.Accounts.Jobs.ConfirmationEmailJob.

Otros menesteres

Hay algunos conceptos como la autorización que pueden ser transversales a nuestra aplicación.

app/
├─ ecommerce/
├─ backoffice/
│─ access_control.ex
...

Podemos promover ese tipo de módulos a nuestra “raíz”, dando a entender que abarca toda nuestra aplicación.

Otro caso común es cuando nuestros módulos, como Accounts o Catalog comienzan a tener cada vez más métodos para cubrir distintos escenarios o para abarcar un escenario complejo como la búsqueda y filtrado de información.

Si nos vemos en la necesidad de recibir parámetros para personalizar nuestras consultas, valdría la pena separar toda esta lógica en módulos nuevos.

app/
├─ ecommerce/
│  ├─ catalog/
│  │  ├─ finders/
│  │  │  ├─ product_finder.ex
...

¿Un pipeline de Brodway? No hay problema :D

app/
├─ ecommerce/
│  ├─ catalog/
│  │  ├─ finders/
│  │  │  ├─ product_finder.ex
│  │  ├─ pipeplines/
│  │  │  ├─ profit_pipeline.ex
...

¿Un cliente para una API externa?

En este caso promovemos el directorio http al primer nivel, ya que puede no ser exclusivo de un contexto y forma parte de la infraestructura.

app/
├─ ecommerce/
│  ├─ catalog/
│  │  ├─ finders/
│  │  │  ├─ product_finder.ex
│  │  ├─ pipeplines/
│  │  │  ├─ profit_pipeline.ex
├─ http/
│  ├─ crm_api.ex
...

También podemos usar el conocido directorio shared/, donde también podríamos promover nuestro modulo de autorización:

app/
├─ ecommerce/
│  ├─ catalog/
│  │  ├─ finders/
│  │  │  ├─ product_finder.ex
│  │  ├─ pipeplines/
│  │  │  ├─ profit_pipeline.ex
├─ shared/
│  ├─ http/
│  │  ├─ crm_api.ex

Otra forma de seguir escalando nuestra estructura de directorios seria agrupar nuestros módulos por la capa a la que pertenecen:

app/
├─ ecommerce/
│  ├─ accounts/
│  │  ├─ domain/
│  │  │  ├─ schemas/
│  │  │  │  ├─ user.ex
│  │  │  │  ├─ user_token.ex
│  │  ├─ application/
│  │  │  ├─ accounts.ex
│  │  │  ├─ user_creator.ex
│  │  ├─ infrastructure/
│  │  │  ├─ jobs
│  │  │  │  ├─ confirmation_email_job.ex
│  │  │  ├─ emails
│  │  │  │  ├─ user_email.ex
├─ shared/
│  ├─ infrastructure/
│  │  ├─ http/
│  │  │  ├─ crm_api.ex
│  ├─ application/
│  │  ├─ access_control.ex
...

Una opción adicional cuando nuestros casos de uso crecen, es organizarlos por el tipo de operación que realizan:

app/
├─ ecommerce/
│  ├─ accounts/
│  │  ├─ application/
│  │  │  ├─ accounts.ex
│  │  │  ├─ create/
│  │  │  │  ├─ user_creator.ex
...

Dependiendo de nuestra aplicación, esto podría ser excesivo o necesario. Todo depende del contexto.

Umbrella al rescate

Como hemos visto, una aplicación puede crecer rápidamente y salirse de control. Una solución común es separar una aplicación en múltiples servicios, algunos patrones con los que se decide como separar estas nuevas aplicaciones pueden ser por subdominio o por business capability.

Aunque tiene sus ventajas, construir servicios separados en repositorios separados conlleva nueva complejidad en cuanto al desarrollo y comunicación de los nuevos servicios.

Afortunadamente, Elixir cuenta con una herramienta llamada proyectos umbrella. Algo así como una aplicación de aplicaciones.

my_app_umbrella/
├─ apps/
│  ├─ ecommerce/
│  │  ├─ accounts/
│  │  │  ├─ domain/
│  │  │  │  ├─ schemas/
│  │  │  │  │  ├─ user.ex
│  │  │  │  │  ├─ user_token.ex
│  │  │  ├─ application/
│  │  │  │  ├─ accounts.ex
│  │  │  │  ├─ create/
│  │  │  │  │  ├─ user_creator.ex
│  │  │  ├─ infrastructure/
│  │  │  │  ├─ jobs
│  │  │  │  │  ├─ confirmation_email_job.ex
│  │  │  │  ├─ emails
│  │  │  │  │  ├─ user_email.ex
│  │  ├─ catalog/
│  │  │  ├─ domain/
│  │  │  │  ├─ schemas/
│  │  │  │  │  ├─ category
│  │  │  │  │  ├─ product.ex
│  │  │  ├─ application/
│  │  │  │  ├─ find/
│  │  │  │  │  ├─ product_finder.ex
│  │  │  │  ├─ catalog.ex
│  │  │  ├─ infrastructure/
│  │  │  │  ├─ pipeplines/
│  │  │  │  │  ├─ profit_pipeline.ex
│  │  ├─ shopping_cart/
│  │  │  ├─ domain/
│  │  │  │  ├─ schemas/
│  │  │  │  │  ├─ cart.ex
│  │  │  │  │  ├─ cart_item.ex
│  │  │  ├─ application/
│  │  │  │  ├─ shopping_cart.ex
│  │  ├─ shared/
│  │  │  ├─ infrastructure/
│  │  │  │  ├─ http/
│  │  │  │  │  ├─ crm_api.ex
│  │  │  ├─ application/
│  │  │  │  ├─ access_control.ex
│  ├─ ecommerce_web/
│  │  ├─ schemas/
│  │  │  ├─ user_schema.ex
│  │  ├─ live/
│  │  ├─ controllers/
│  │  │  ├─ product_controller.ex
│  │  │  ├─ category_controller.ex
│  ├─ backoffice/
│  │  ├─ support/
│  │  │  ├─ domain/
│  │  │  │  ├─ schemas/
│  │  │  │  │  ├─ ticket.ex
│  │  │  ├─ application/
│  │  │  │  │  ├─ tickets.ex
│  ├─ backoffice_web/
│  │  ├─ schemas/
│  │  ├─ live/
│  │  ├─ controllers/
│  │  │  ├─ product_controller.ex
├─ README.md

Con un proyecto umbrella ahora tenemos distintas aplicaciones: ecommerce, ecommerce_web, backoffice y backoffice_web. Con esto eliminamos la necesidad de separar nuestra aplicación original en múltiples repositorios si se vuelve muy grande, lo que agregaría mucho trabajo para manejar y orquestar el desarrollo.

Los proyectos umbrella nos proveen algunas ventajas:

• Desarrollo monorepo
• Puedes construir, probar y desplegar cada aplicación por separado si asi lo deseas.
• Una aplicación puede tener disponible otra si esta define como una dependencia interna (dentro de la umbrella)

Dado que comparten dependencias y la configuración de las mismas, es importante tomarlo en cuenta, ya que al no ser aplicaciones totalmente independientes pudiera causar conflictos.

¿Cuándo comenzar con una aplicación de Phoenix normal y cuando con una umbrella?

Si tu proyecto está empezando y no sabes a ciencia cierta hacia donde va o que tan grande puede ser, comienza simple, una aplicación de Phoenix será suficiente y con un poco de disciplina, promover directorios hacia su propio contexto o su propia app será sencillo.

Si lo que estás desarrollando es un producto con varios subdominios, aunque comiences con uno solo, pero esperas desarrollar el resto eventualmente. O cuando ese subdominio es considerablemente complejo (es un core subdomain) puedes comenzar con un proyecto umbrella.

Tu aplicación es tuya y tú sabes de qué trata

Los frameworks suelen ofrecer una base para comenzar a organizar tu aplicación, sin embargo, no conocen muchos detalles que tú si, quien la desarrolla. No saben de qué trata, que tan grande puede ser que tan simple o compleja es la lógica de negocio. Por eso no pueden ofrecer una guía que sirva para todos los casos y para todos los tamaños.

Tú eres el dueño de tu aplicación y conoces mejor tus necesidades. ¿No te gusta la idea de separar en ecommerce y backoffice? Bien, elimínalas, es tu aplicación :D.

¿No necesitas que tu estructura de directorios te diga a que capa pertenecen los módulos? Excelente!

El punto es que la arquitectura de nuestra aplicación eventualmente necesita evolucionar, pero rara vez esto sucede. Generalmente, se permanece con la arquitectura y estructura original, aunque esta ya no cumpla los requerimientos del producto.

Tener una heurística base nos permite evaluar opciones e implementar la que mejor se ajuste a nuestros requerimientos y nuestra experiencia :D

Links de interes:

• https://medium.com/very-big-things/towards-maintainable-elixir-the-core-and-the-interface-c267f0da43
• https://ulisses.dev/elixir/2022/03/04/elixir-modules-files-directories-and-naming-conventions.html
• https://remote.com/blog/introducing-phx_gen_solid
• https://martinfowler.com/eaaCatalog/serviceLayer.html
• https://aaronrenner.io/2019/09/18/application-layering-a-pattern-for-extensible-elixir-application-design.html

to_form(Accounts.change_user(%User{})))

Sin embargo, pueden surgir situaciones donde tengamos un formulario sin tener que respaldarlo con un changeset.

Porque saltarse el changeset?

Ecto.Changeset es una herramienta para trabajar con información de distintas fuentes. Proporciona validaciones, castings y manejo de errores. Normalmente creamos formularios basados en un schema de Ecto, es decir que tienen una tabla en nuestra base de datos. Sin embargo, hay situaciones en las que generar un changeset puede ser excesivo o innecesario, ya sea basado en un schema o en su forma schemaless.

Si simplemente queremos capturar datos sin necesidad de validaciones complejas, es posible que quieras evitar usar un changeset.

Vamos a poner como ejemplo un formulario de contacto (asumiendo que ya tienes un proyecto de Phoenix corriendo):

defmodule MyAppWeb.ContactLive do
  use MyAppWeb, :live_view

  @impl true
  def mount(_params, _session, socket) do
    params = %{"name" => "", "subject" => "", "body" => "", "email" => ""}
    {:ok, assign(socket, :form, to_form(params))}
  end

  @impl true
  def render(assigns) do
    ~H"""
    <div>
      <.header>
        <:subtitle>Contact</:subtitle>
      </.header>

      <.simple_form for={@form} id="contact_form" phx-submit="save">
        <.input field={@form[:name]} label="Name" />
        <.input field={@form[:subject]} label="Subject" />
        <.input field={@form[:body]} type="textarea" label="Body" />
        <.input field={@form[:email]} type="email" label="Email" />

        <:actions>
          <.button phx-disable-with="Saving...">Send</.button>
        </:actions>
      </.simple_form>
    </div>
    """
  end

  @impl true
  def handle_event("save", params, socket) do
    {:noreply, socket}
  end
end

Y en el router.ex:

 scope "/", MyAppWeb do
    pipe_through :browser

    get "/", PageController, :home

    live "/contact", ContactLive # <-- add this
  end

Si entramos a http://localhost:4000/contact tendremos nuestro formulario de contacto:

Como vemos la única diferencia es que al helper to_form/1 le pasaremos un mapa en lugar de un changeset:

# with changeset
changeset = Accounts.change_user(%User{}))
to_form(changeset)

# without changeset
params = %{"name" => "", "subject" => "", "body" => "", "email" => ""}
to_form(params)

Si probamos el formulario podremos ver lo siguiente en los logs:

De esta forma podemos seguir aprovechando el poder de los helpers y los nuevos componentes del modulo CoreComponents.

Una de las formas más comunes de almacenar datos en software es utilizando bases de datos relaciones. Aún y con el surgimiento de propuestas como las bases de datos NoSQL, el modelo relacional sigue estando presente porque es útil para la mayoría de los casos.

¿Qué es la integridad de los datos?

Se refiere a que la información almacenada en una base de datos sea completa y correcta. Cuando insertamos, actualizamos o eliminamos información la integridad puede perderse.

Existen distintos tipos de integridad:

• Integridad de dominio: Que los datos obligatorios estén presentes y sean del tipo esperado.
• Integridad de entidad: establece que la clave primaria de una tabla debe tener un valor único para cada fila de la tabla.
• La integridad referencial garantiza que la relación entre dos tablas permanezca sincronizada durante las operaciones y se asegura que los registros de las tablas relacionadas son válidos.

Vamos a imaginar el caso de un banco que tiene las siguientes tablas: users, accounts deposits, withdrwals.

Primero vamos a crear las migraciones que van a crear nuestras tablas

rails g model User email:string name:string
rails g model Account balance:decimal active:boolean user_id:references:users
rails g model Deposit amount:decimal account_id:references:accounts
rails g model Withdrawal amount:decimal account_id:references:accounts

Por ahora tenemos las siguientes migraciones:

class CreateUsers < ActiveRecord::Migration[7.0]
  def change
    create_table :users do |t|
      t.string :email
      t.string :name
      t.timestamps
    end
  end
end

class CreateAccounts < ActiveRecord::Migration[7.0]
  def change
    create_table :accounts do |t|
      t.decimal :balance
      t.boolean :active
      t.references :user, null: false, foreign_key: true
      t.timestamps
    end
  end
end

class CreateDeposits < ActiveRecord::Migration[7.0]
  def change
    create_table :sales do |t|
      t.decimal :amount
      t.references :account, null: false, foreign_key: true

      t.timestamps
    end
  end
end

class CreateWithdrawals < ActiveRecord::Migration[7.0]
  def change
    create_table :withdrawal do |t|
      t.decimal :amount
      t.references :account, null: false, foreign_key: true

      t.timestamps
    end
  end
end

Campos vacíos o nulos

Como no queremos que un usuario pueda registrarse sin proporcionar su email y su nombre, forzaremos esto en la base de datos agregando la restricción null: false a la definición de las columnas.

class CreateUsers < ActiveRecord::Migration[7.0]
  def change
    create_table :users do |t|
      t.string :email, null: false
      t.string :name, null: false
      t.timestamps
    end
  end
end

Otro lugar importante donde evitar la presencia de valores nulos es en las llaves foráneas. Además de incluir la misma opción en otros campos donde sea necesario:

class CreateAccounts < ActiveRecord::Migration[7.0]
  def change
    create_table :accounts do |t|
      t.decimal :balance, null: false
      t.boolean :active, null: false
      t.references :user, null: false, foreign_key: true
      t.timestamps
    end
  end
end

class CreateDeposits < ActiveRecord::Migration[7.0]
  def change
    create_table :deposits do |t|
      t.decimal :amount, null: false
      t.references :account, null: false, foreign_key: true

      t.timestamps
    end
  end
end

class CreateWithdrawals < ActiveRecord::Migration[7.0]
  def change
    create_table :withdrawals do |t|
      t.decimal :amount, null: false
      t.references :account, null: false, foreign_key: true

      t.timestamps
    end
  end
end

Valores por defecto

En algunos casos como los campos booleanos es buena práctica definir un valor por defecto. Como es el caso del campo active en la tabla accounts.

Además, considerando que tenemos un campo balance que almacena el balance de la cuenta, podríamos asumir que nuestro caso de uso es que al crear una cuenta se cree con un balance de 0 (no nulo). De esta forma tendremos que lidiar con menos validaciones si queremos realizar operaciones aritméticas con dicho valor.

class CreateAccounts < ActiveRecord::Migration[7.0]
  def change
    create_table :accounts do |t|
      t.decimal :balance, null: false, default: 0
      t.boolean :active, null: false, default: false
      t.references :user, null: false, foreign_key: true
      t.timestamps
    end
  end
end

Campos únicos

En la tabla users guardamos información como el email y el nombre del usuario. Como no queremos que haya 2 usuarios registrados con el mismo email, vamos a agregar esta restricción en nuestra tabla:

class CreateUsers < ActiveRecord::Migration[7.0]
  def change
    create_table :users do |t|
      t.string :email, null: false
      t.string :name, null: false
      t.timestamps
    end

    add_index :users, :email, unique: true
  end
end

La línea add_index :users, :email, unique: true hace 2 cosas:

1. Crea un índice en la columna email de la tabla users
2. Este índice es único

Esto hará que nuestra base de datos responda con un error si intentamos crear un registro con el mismo valor de email que un registro existente.

Otra funcionalidad útil es que podemos crear esta misma restricción con múltiples columnas. Es decir, negar la creación de un registro donde la combinación de dos o más columnas sea igual al de otro registro. Solo hay que agregar las columnas:

add_index :users, [:email, :name], unique: true

Registros huérfanos

En caso de que permitamos que los usuarios eliminen registros de la base de datos o esto suceda por algún proceso interno, podríamos perder integridad referencial.

Por ejemplo, si eliminamos una cuenta de nuestra base de datos, puede que los depósitos y retiros de dicho usuario permanezcan, pero sin saber a que cuenta hacían referencia.

Tenemos varias opciones:

• :cascade Elimina todos los registros relacionados. Alias de la opción CASCADE
• :nullify Establece la llave foránea en todos los registros relacionados en NULL.
• :restrict Genera un error si se intenta eliminar un registro padre que tiene registros relacionados.

class CreateAccounts < ActiveRecord::Migration[7.0]
  def change
    create_table :accounts do |t|
      t.decimal :balance, null: false, default: 0
      t.boolean :active, null: false, default: false
      t.references :user, null: false, foreign_key: true, foreign_key: {on_delete: :restrict}
      t.timestamps
    end
  end
end

class CreateDeposits < ActiveRecord::Migration[7.0]
  def change
    create_table :deposits do |t|
      t.decimal :amount, null: false
      t.references :account, null: false, foreign_key: true, foreign_key: {on_delete: :restrict}

      t.timestamps
    end
  end
end

class CreateWithdrawals < ActiveRecord::Migration[7.0]
  def change
    create_table :withdrawals do |t|
      t.decimal :amount, null: false
      t.references :account, null: false, foreign_key: true, foreign_key: {on_delete: :restrict}

      t.timestamps
    end
  end
end

La mejor opción dependerá de nuestro caso de uso. Por ahora evitaremos su eliminación usando la opción on_delete: :restrict.

Valores inválidos

Por ejemplo, cuando se manejan valores monetarios, como en la tabla donde registramos los depósitos y la tabla de retiros. En el caso del campo balance de la tabla accounts un valor menor a 0 podríamos considerarlo inválido.

Además, en el caso de los depósitos y retiros, no tiene mucho sentido que el monto de una de estas operaciones sea 0 y mucho menos menor a 0.

class CreateDeposits < ActiveRecord::Migration[7.0]
  def change
    create_table :deposits do |t|
      t.decimal :amount, null: false
      t.references :account, null: false, foreign_key: true, foreign_key: {on_delete: :restrict}

      t.timestamps
    end

    reversible do |dir|
      dir.up do
        execute <<-SQL
		  ALTER TABLE deposits
	      ADD CONSTRAINT deposits_amount_must_be_positive
	      CHECK (amount > 0)
        SQL
      end

      dir.down do
        execute <<-SQL
          ALTER TABLE deposits
          DROP CONSTRAINT deposits_amount_must_be_positive
        SQL
      end
	  end
  end
end

class CreateWithdrawals < ActiveRecord::Migration[7.0]
  def change
    create_table :withdrawals do |t|
      t.decimal :amount, null: false
      t.references :account, null: false, foreign_key: true, foreign_key: {on_delete: :restrict}

      t.timestamps
    end

    reversible do |dir|
      dir.up do
        execute <<-SQL
		  ALTER TABLE withdrawals
	      ADD CONSTRAINT withdrawals_amount_must_be_positive
	      CHECK (amount > 0)
        SQL
      end

      dir.down do
        execute <<-SQL
          ALTER TABLE withdrawals
          DROP CONSTRAINT withdrawals_amount_must_be_positive
        SQL
      end
	  end
  end
end

Valores inválidos entre tablas

Cuando tenemos una acción de retiro, asumimos que la cantidad que se retira se resta del balance de la cuenta de la cual se efectúa el retiro.

Para evitar que se realice un retiro por un monto mayor al balance de la cuenta podemos agregar una verificación:

class CreateWithdrawals < ActiveRecord::Migration[6.1]
  def change
    create_table :withdrawals do |t|
      t.decimal :amount, null: false
      t.references :account, null: false, foreign_key: true, foreign_key: {on_delete: :restrict}

      t.timestamps
    end

    reversible do |dir|
      dir.up do
      #...previous constrains

        execute <<-SQL
          CREATE OR REPLACE FUNCTION validate_withdrawal_amount()
          RETURNS TRIGGER AS $$
            BEGIN
              IF NEW.amount > (SELECT balance FROM accounts WHERE id = NEW.account_id) THEN
              RAISE EXCEPTION 'Withdrawal amount is greater than account balance';
              END IF;
              RETURN NEW;
            END;
            $$ LANGUAGE plpgsql;
        SQL

        execute <<-SQL
          CREATE TRIGGER withdrawal_amount_validation
          BEFORE INSERT ON withdrawals
          FOR EACH ROW EXECUTE FUNCTION validate_withdrawal_amount();
        SQL
      end

      dir.down do
        execute <<-SQL
          DROP TRIGGER withdrawal_amount_validation IF EXISTS ON withdrawals;
        SQL

        execute <<-SQL
          DROP FUNCTION validate_withdrawal_amount();
        SQL
      end
    end
  end
end

Dado que en estos ejemplos se está usando Postgres como base de datos, debemos crear una función que se encargue de realizar la verificación, además de un trigger que se encargue de llamar a dicha función cada vez que se realice un insert en la tabla withdrawals.

Esto debido a que PostgreSQL no soporta sub queries en los CONSTRAINT.

Operaciones parciales

En caso de que un usuario realice un retiro, hay 2 operaciones que deben realizarse:

1. Crear el registro en la tabla withdrawals con la información del retiro
2. Actualizar el balance en la tabla accounts restando el monto del retiro al balance de la cuenta

Queremos evitar que una de las operaciones se complete correctamente, pero la otra no. Quedando la base de datos con un estado incorrecto. Por ejemplo, tener un registro de retiro, pero que este monto no sea restado del balance de la cuenta.

Esto lo logramos con transacciones de la base de datos:

ActiveRecord::Base.transaction do
  withdrawal.save!
  withdrawal.account.subtract_balance!(withdrawal.amount)
end

De esta forma nos aseguramos que ambas operaciones se ejecuten correctamente o de lo contrario se lanzara una excepción, realizando un rollback y ninguno de los cambios será confirmado.

Así como estos escenarios hipotéticos, pueden surgir muchos más dependiendo de información que estemos almacenando en nuestra aplicación.

También es importante distinguir los casos donde una restricción es más una regla de negocio que puede cambiar o ajustarse de manera más o menos frecuente. Se debe evaluar si la base de datos es el lugar correcto para dicha restricción o, por el contrario, nos restaría flexibilidad en el futuro y la capa de dominio sería un mejor lugar para manejarla.

¿Qué hay de agregar estas validaciones en los modelos/dominio? Seguro, pero como menciona David Bryant Copeland en su libro Sustainable Web Development with Ruby on Rails: Las validaciones son geniales para la experiencia de usuario, pero estas no proporcionan integridad de los datos.1

Referencias

Avoiding Data Loss: Understanding the :on_delete Option in Elixir Migrations The difference between on_delete: :restrict, :nullify, and :cascade

¿Qué es la integridad de los datos?

Se refiere a que la información almacenada en una base de datos sea completa y correcta. Cuando insertamos, actualizamos o eliminamos información la integridad puede perderse.

Existen distintos tipos de integridad:

• Integridad de dominio: Que los datos obligatorios estén presentes y sean del tipo esperado.
• Integridad de entidad: establece que la clave primaria de una tabla debe tener un valor único para cada fila de la tabla.
• La integridad referencial garantiza que la relación entre dos tablas permanezca sincronizada durante las operaciones y se asegura que los registros de las tablas relacionadas son válidos.

Vamos a imaginar el caso de un banco que tiene las siguientes tablas: users, accounts deposits, withdrwals.

Primero vamos a crear las migraciones que van a crear nuestras tablas

mix phx.gen.schema User users email:string name:string
mix phx.gen.schema Account accounts balance:decimal active:boolean user_id:references:users
mix phx.gen.schema Deposit deposits amount:decimal account_id:references:accounts
mix phx.gen.schema Withdrawal withdrawals amount:decimal account_id:references:accounts

Por ahora tenemos las siguientes migraciones:

defmodule MyApp.Repo.Migrations.CreateUsers do
  use Ecto.Migration

  def change do
    create table(:users) do
      add :email, :string
      add :name, :string

      timestamps()
    end
  end
end

defmodule MyApp.Repo.Migrations.CreateAccounts do
  use Ecto.Migration

  def change do
    create table(:accounts) do
      add :balance, :decimal
      add :active, :boolean, default: false, null: false
      add :user_id, references(:users, on_delete: :nothing)

      timestamps()
    end

    create index(:accounts, [:user_id])
  end
end

defmodule MyApp.Repo.Migrations.CreateDeposits do
  use Ecto.Migration

  def change do
    create table(:deposits) do
      add :amount, :decimal
      add :account_id, references(:accounts, on_delete: :nothing)

      timestamps()
    end

    create index(:deposits, [:account_id])
  end
end

defmodule MyApp.Repo.Migrations.CreateWithdrawals do
  use Ecto.Migration

  def change do
    create table(:withdrawals) do
      add :amount, :decimal
      add :account_id, references(:accounts, on_delete: :nothing)

      timestamps()
    end

    create index(:withdrawals, [:account_id])
  end
end

Campos vacíos o nulos

Como no queremos que un usuario pueda registrarse sin proporcionar su email y su nombre, forzaremos esto en la base de datos agregando la restricción null: false a la definición de las columnas.

defmodule MyApp.Repo.Migrations.CreateUsers do
  use Ecto.Migration

  def change do
    create table(:users) do
      add :email, :string, null: false
      add :name, :string, null: false

      timestamps()
    end
  end
end

Otro lugar importante donde evitar la presencia de valores nulos es en las llaves foráneas. Además de incluir la misma opción en otros campos donde sea necesario:

defmodule MyApp.Repo.Migrations.CreateAccounts do
  use Ecto.Migration

  def change do
    create table(:accounts) do
      add :balance, :decimal, null: false
      add :active, :boolean, default: false, null: false
      add :user_id, references(:users, on_delete: :nothing), null: false

      timestamps()
    end

    create index(:accounts, [:user_id])
  end
end

defmodule MyApp.Repo.Migrations.CreateDeposits do
  use Ecto.Migration

  def change do
    create table(:deposits) do
      add :amount, :decimal, null: false
      add :account_id, references(:accounts, on_delete: :nothing), null: false

      timestamps()
    end

    create index(:deposits, [:account_id])
  end
end

defmodule MyApp.Repo.Migrations.CreateWithdrawals do
  use Ecto.Migration

  def change do
    create table(:withdrawals) do
      add :amount, :decimal, null: false
      add :account_id, references(:accounts, on_delete: :nothing), null: false

      timestamps()
    end

    create index(:withdrawals, [:account_id])
  end
end

Valores por defecto

En algunos casos como los campos booleanos es buena práctica definir un valor por defecto. En el caso del campo active en la tabla accounts, los generadores de Phoenix agregaron dos restricciones al definir el campo como booleano.

Además, considerando que tenemos un campo balance que almacena el balance de la cuenta, podríamos asumir que nuestro caso de uso es que al crear una cuenta se cree con un balance de 0 (no nulo). De esta forma tendremos que lidiar con menos validaciones si queremos realizar operaciones aritméticas con dicho valor.

defmodule MyApp.Repo.Migrations.CreateAccounts do
  use Ecto.Migration

  def change do
    create table(:accounts) do
      add :balance, :decimal, default: 0, null: false
      add :active, :boolean, default: false, null: false
      add :user_id, references(:users, on_delete: :nothing), null: false

      timestamps()
    end

    create index(:accounts, [:user_id])
  end
end

Campos únicos

En la tabla users guardamos información como el email y el nombre del usuario. Como no queremos que haya 2 usuarios registrados con el mismo email, vamos a agregar esta restricción en nuestra tabla:

defmodule MyApp.Repo.Migrations.CreateUsers do
  use Ecto.Migration

  def change do
    create table(:users) do
      add :email, :string, null: false
      add :name, :string, null: false

      timestamps()
    end

    create unique_index(:users, [:email])
  end
end

La línea create unique_index(:users, [:email]) hace 2 cosas:

1. Crea un índice en la columna email de la tabla users
2. Este índice es único

Esto hará que nuestra base de datos responda con un error si intentamos crear un registro con el mismo valor de email que un registro existente.

Otra funcionalidad útil es que podemos crear esta misma restricción con múltiples columnas. Es decir, negar la creación de un registro donde la combinación de dos o más columnas sea igual al de otro registro. Solo hay que agregar las columnas:

create unique_index(:users, [:email, :name])

Registros huérfanos

En caso de que permitamos que los usuarios eliminen registros de la base de datos o esto suceda por algún proceso interno, podríamos perder integridad referencial.

Por ejemplo, si eliminamos una cuenta de nuestra base de datos, puede que los depósitos y retiros de dicho usuario permanezcan, pero sin saber a que cuenta hacían referencia.

Los generadores de Phoenix agregaron la opción on_delete: :nothing en todas las llaves foraneas, que es la opción por defecto. Pero tenemos varias opciones:

• :delete_all Elimina todos los registros relacionados. Alias de la opción CASCADE
• :nilify_all Establece la llave foránea en todos los registros relacionados en NULL.
• :restrict Genera un error si se intenta eliminar un registro padre que tiene registros relacionados.

defmodule MyApp.Repo.Migrations.CreateAccounts do
  use Ecto.Migration

  def change do
    create table(:accounts) do
      add :balance, :decimal, default: 0, null: false
      add :active, :boolean, default: false, null: false
      add :user_id, references(:users, on_delete: :restrict), null: false

      timestamps()
    end

    create index(:accounts, [:user_id])
  end
end

defmodule MyApp.Repo.Migrations.CreateDeposits do
  use Ecto.Migration

  def change do
    create table(:deposits) do
      add :amount, :decimal, null: false
      add :account_id, references(:accounts, on_delete: :restrict), null: false

      timestamps()
    end

    create index(:deposits, [:account_id])
  end
end

defmodule MyApp.Repo.Migrations.CreateWithdrawals do
  use Ecto.Migration

  def change do
    create table(:withdrawals) do
      add :amount, :decimal, null: false
      add :account_id, references(:accounts, on_delete: :restrict), null: false

      timestamps()
    end

    create index(:withdrawals, [:account_id])
  end
end

La mejor opción dependerá de nuestro caso de uso. Por ahora evitaremos su eliminación usando la opción on_delete: :restrict.

Valores inválidos

Por ejemplo, cuando se manejan valores monetarios, como en la tabla donde registramos los depósitos y la tabla de retiros. En el caso del campo balance de la tabla accounts un valor menor a 0 podríamos considerarlo inválido.

Además, en el caso de los depósitos y retiros, no tiene mucho sentido que el monto de una de estas operaciones sea 0 y mucho menos menor a 0.

defmodule MyApp.Repo.Migrations.CreateDeposits do
  use Ecto.Migration

  def change do
    create table(:deposits) do
      add :amount, :decimal, null: false
      add :account_id, references(:accounts, on_delete: :restrict), null: false

      timestamps()
    end

    create index(:deposits, [:account_id])

	create constraint("deposits", "amount_must_be_positive", check: "amount > 0", comment: "Deposit amount can't be 0 or negative")
  end
end

defmodule MyApp.Repo.Migrations.CreateWithdrawals do
  use Ecto.Migration

  def change do
    create table(:withdrawals) do
      add :amount, :decimal, null: false
      add :account_id, references(:accounts, on_delete: :restrict), null: false

      timestamps()
    end

    create index(:withdrawals, [:account_id])

	create constraint("withdrawals", "amount_must_be_positive", check: "amount > 0", comment: "Withdrawal amount can't be 0 or negative")
  end
end

Valores inválidos entre tablas

Cuando tenemos una acción de retiro, asumimos que la cantidad que se retira se resta del balance de la cuenta de la cual se efectúa el retiro.

Para evitar que se realice un retiro por un monto mayor al balance de la cuenta podemos agregar una verificación:

defmodule MyApp.Repo.Migrations.CreateWithdrawals do
  use Ecto.Migration

  def up do
    create table(:withdrawals) do
      add :amount, :decimal, null: false
      add :account_id, references(:accounts, on_delete: :restrict), null: false

      timestamps()
    end

    create index(:withdrawals, [:account_id])

	create constraint("withdrawals", "amount_must_be_positive", check: "amount > 0", comment: "Withdrawal amount can't be 0 or negative")

    execute """
    CREATE OR REPLACE FUNCTION validate_withdrawal_amount()
      RETURNS TRIGGER AS $$
        BEGIN
          IF NEW.amount > (SELECT balance FROM accounts WHERE id = NEW.account_id) THEN
          RAISE EXCEPTION 'Withdrawal amount is greater than account balance';
          END IF;
          RETURN NEW;
        END;
        $$ LANGUAGE plpgsql;
    """

    execute """
    CREATE TRIGGER withdrawal_amount_validation
    BEFORE INSERT ON withdrawals
    FOR EACH ROW EXECUTE FUNCTION validate_withdrawal_amount();
    """
  end

  def down do
	  execute """
    DROP TRIGGER withdrawal_amount_validation IF EXISTS ON withdrawals;
    """

    execute """
    DROP FUNCTION validate_withdrawal_amount();
    """

    drop constraint("withdrawals", "amount_must_be_positive")

    drop index("withdrawals", [:account_id])

    drop table("withdrawals")
  end
end

Dado que en estos ejemplos se está usando Postgres como base de datos, debemos crear una función que se encargue de realizar la verificación, además de un trigger que se encargue de llamar a dicha función cada vez que se realice un insert en la tabla withdrawals.

Esto debido a que Postgres no soporta sub queries en los CONSTRAINT.

Operaciones parciales

En caso de que un usuario realice un retiro, hay 2 operaciones que deben realizarse:

1. Crear el registro en la tabla withdrawals con la información del retiro
2. Actualizar el balance en la tabla accounts restando el monto del retiro al balance de la cuenta

Queremos evitar que una de las operaciones se complete correctamente, pero la otra no. Quedando la base de datos con un estado incorrecto. Por ejemplo, tener un registro de retiro, pero que este monto no sea restado del balance de la cuenta.

Esto lo logramos con transacciones de la base de datos:

MyRepo.transaction(fn ->
  account = Accounts.get!(account_id)
  Withdrawals.create!(account, amount)
  Accounts.update_balance!(account, account.balance - amount)
end)

De esta forma nos aseguramos que ambas operaciones se ejecuten correctamente o de lo contrario se lanzara una excepción, realizando un rollback y ninguno de los cambios será confirmado.

Así como estos escenarios hipotéticos, pueden surgir muchos más dependiendo de información que estemos almacenando en nuestra aplicación.

También es importante distinguir los casos donde una restricción es más una regla de negocio que puede cambiar o ajustarse de manera más o menos frecuente. Se debe evaluar si la base de datos es el lugar correcto para dicha restricción o, por el contrario, nos restaría flexibilidad en el futuro y la capa de dominio sería un mejor lugar para manejarla.

¿Qué hay de agregar estas validaciones en los modelos/dominio? Seguro, pero como menciona David Bryant Copeland en su libro Sustainable Web Development with Ruby on Rails: Las validaciones son geniales para la experiencia de usuario, pero estas no proporcionan integridad de los datos.1

Referencias

Avoiding Data Loss: Understanding the :on_delete Option in Elixir Migrations

Esto puede acarrear errores de semántica y de lógica. Para evitar este problema es una buena práctica definir los campos como null: false y además siempre dar un valor por defecto, por ejemplo admin: false.

create_table :users do |t|
  t.boolean :admin, null: false, default: false
end

Si un campo es booleano, entonces su valor es true o false.

Pero, si tú, como yo en algún momento, pensaste en usar el valor null como un tercer estado, quizás lo que busques es un campo enum:

create_table :users do |t|
  t.integer :role, null: false, default: 1
end

class User < ApplicationRecord
  enum :role, [:user, :admin]
end

o incluso una lookup table:

create_table :roles do |t|
  t.string :role, null: false
end

create_table :users do |t|
  t.references :role, null: false, foreign_key: true
end

La mejor opción dependerá del contexto de tu aplicación.

Un excelente post sobre el tema es Avoid the Three-state Boolean Problem

Es decir, esta biblioteca nos permite consumir y procesar información de fuentes como un Message Broker (Kafka, RabbitMQ, etc.).

Por si fuera poco, viene con una serie de características integradas que nos permiten diseñar nuestros pipelines con una gran flexibilidad:

• Back-pressure
• Concurrencia y procesamiento por lotes
• Rate limiting
• Varios producers out of the box
• La posibilidad de crear custom producers
• Entre otras.

Creando un custom producer

Si bien consumir información desde un message broker es, por decirlo de alguna manera, la opción por defecto de Broadway, esto no significa que esté limitado a estos como fuente de información.

Como ya se mencionó, nos permite crear y conectar nuestros propios producers y estos pueden consumir información de cualquier fuente que queramos. Una base de datos, por ejemplo.

Lo primero es crear un módulo que utilice el behaviour de Broadway:

defmodule MyBroadway do
  use Broadway

  require Logger

  @chunk_size 10

  def start_link(_opts) do
    options = [
      name: __MODULE__,
      producer: [
        module: {DBDummyProducer, []},
        transformer: {__MODULE__, :transform, []},
        concurrency: 1
      ],
      processors: [
        default: [
          max_demand: @chunk_size,
          concurrency: 1
        ]
      ]
    ]

	Broadway.start_link(__MODULE__, options)
  end
end

En las opciones le estamos diciendo a la biblioteca que nuestro producer es el módulo DBDummyProducer, ya que vamos a “realizar” consultas a la base de datos, usamos la opción max_demand para limitar el número de registros que vamos a cargar en memoria. Vamos a utilizar este valor en DBDummyProducer.

Además, le estamos diciendo que vamos a utilizar como transformer la función transform en el mismo módulo MyBroadway. Ya que los datos llegaran como maps o structs y deben incluirse en la estructura Broadway.Message.t().

def transform(event, _opts) do
    Logger.debug("[MyBroadway] transforming event: #{inspect(event)}")

    %Message{
      data: event,
      acknowledger: {__MODULE__, :trackings, :ack_data}
    }
end

Otra función que debemos implementar es ack/3 . Esta función sirve para notificar que los mensajes recibidos se procesaron correctamente o fallaron.

def ack(:ack_id, successful, failed) do
    Logger.debug(
      "[MyBroadway] ack successful: #{Enum.count(successful)}, failed: #{Enum.count(failed)}"
    )

    :ok
  end

Ahora creamos nuestro módulo DBDummyProducer, para efectos de simplificación vamos a generar datos en memoria, solo habría que sustituir esto por la llamada a nuestro contexto o módulo que genere la consulta.

defmodule DBDummyProducer do
  @moduledoc """
  This module emulates DBProducer behavior producing in memory rows
  """
  use GenStage

  require Logger

  @impl GenStage
  def init(opts) do
    {:producer, opts}
  end

  def start_link(opts) do
    GenStage.start_link(__MODULE__, opts)
  end

  @impl true
  @spec handle_demand(integer, any) :: {:noreply, list, any}
  def handle_demand(demand, state) do
    Logger.debug(fn ->
      "[DBProducer] handling demand: #{demand}"
    end)

    # events = Users.list(limit: demand)
    events =
      Enum.map(1..demand, fn _number ->
        %{
          id: Enum.random(1..9_999_999),
        }
      end)

    {:noreply, events, state}
  end
end

Ahora nuestro pipeline puede recibir datos desde nuestro producer. Seguramente necesitamos procesar esta información de alguna manera. Para esto tenemos dos callback handle_message/3 para procesar mensajes individuales y handle_batch/4 para procesar lotes.

def handle_message(_processor, message, _context) do
    Logger.debug(fn -> "[MyBroadway] Incoming Message: #{inspect(message)}" end)
	# perform business logic
    message
end

def handle_batch(_batcher, messages, _batch_info, _context) do
	Logger.debug("[MyBroadway] in default batcher")
	Logger.debug(fn -> "[MyBroadway] size: #{length(messages)}" end)

	messages
end

Sí queremos hacer uso de handle_batch/4 debemos hacer dos cosas:

• Agregar la llave batchers a nuestras options
• Al transformar el mensaje debemos especificar en cual batcher se va a procesar

def start_link(_opts) do
	 options = [
	  # ... previous options
	  batchers: [default: []]
	]
	Broadway.start_link(__MODULE__, options)
	end

def transform(event, _state) do
    Logger.debug("[MyBroadway] transforming event: #{inspect(event)}")

    %Broadway.Message{
      data: event,
      acknowledger: {__MODULE__, :trackings, :ack_data}
    }
    |> Broadway.Message.put_batcher(:default)
  end

Por último, solo resta agregar MyBroadway al supervisor, normalmente en el archivo application.ex

children = [
  {MyBroadway, []}
]

Supervisor.start_link(children, strategy: :one_for_one)

Si intentamos probar el comportamiento del código, no seremos capaces de apreciar los eventos que están sucediendo. Para configurar un poco este comportamiento podemos usar la configuración de rate_limiting en las opciones del producer:

def start_link(_opts) do
	 options = [
	  # ... previous options
	  producer: [
      module: {DBDummyProducer, []},
      transformer: {__MODULE__, :transform, []},
      rate_limiting: [
        interval: 10_000,
        allowed_messages: 10
      ],
      concurrency: 1
    ],
    # .. next options
	]
	Broadway.start_link(__MODULE__, options)
end

Puedes ver el resultado final en el repositorio broadway-custom-producer. Pero nuestro código queda de la siguiente manera:

defmodule MyBroadway do
  use Broadway

  require Logger

  @chunk_size 10

  @doc """
  Uses rate_limiting options to be able to see log messages in the console
  """
  def start_link(_opts) do
    options = [
      name: __MODULE__,
      producer: [
        module: {DBDummyProducer, []},
        transformer: {__MODULE__, :transform, []},
        rate_limiting: [
          interval: 10_000,
          allowed_messages: 10
        ],
        concurrency: 1
      ],
      processors: [
        default: [
          max_demand: @chunk_size,
          concurrency: 1
        ]
      ],
      batchers: [default: []]
    ]

    Broadway.start_link(__MODULE__, options)
  end

  def transform(event, _state) do
    Logger.debug("[MyBroadway] transforming event: #{inspect(event)}")

    %Broadway.Message{
      data: event,
      acknowledger: {__MODULE__, :trackings, :ack_data}
    }
    |> Broadway.Message.put_batcher(:default)
  end

  def ack(:trackings, successful, failed) do
    Logger.debug(
      "[MyBroadway] ack successful: #{length(successful)}, failed: #{length(failed)}"
    )

    :ok
  end

  def handle_message(_processor, message, _context) do
    Logger.debug(fn -> "[MyBroadway] Incoming Message: #{inspect(message)}" end)

    message
  end

  def handle_batch(_batcher, messages, _batch_info, _context) do
    Logger.debug("[MyBroadway] in default batcher")
    Logger.debug(fn -> "[MyBroadway] size: #{length(messages)}" end)

    messages
  end
end

defmodule DBDummyProducer do
  @moduledoc """
  This module emulates database behavior by producing in-memory rows
  """
  use GenStage

  require Logger

  @impl GenStage
  def init(opts) do
    {:producer, opts}
  end

  def start_link(opts) do
    GenStage.start_link(__MODULE__, opts)
  end

  @impl true
  def handle_demand(demand, state) do
    Logger.debug(fn ->
      "[DBDummyProducer] handling demand: #{demand}"
    end)

    # events = Users.list_users(limit: demand)
    events =
      Enum.map(1..demand, fn _number ->
        %{
          id: Enum.random(1..9_999_999_999)
        }
      end)

    {:noreply, events, state}
  end
end

Ahora, si ingresamos a la consola interactiva de nuestra aplicación, veremos algo como los siguientes mensajes que mostramos mediante el Logger:

10:10:39.341 [debug] [DBDummyProducer] handling demand: 10

10:10:39.349 [debug] [MyBroadway] transforming event: %{id: 2730249896}

10:10:39.349 [debug] [MyBroadway] transforming event: %{id: 8277765695}

10:10:39.349 [debug] [MyBroadway] transforming event: %{id: 917212511}

10:10:39.349 [debug] [MyBroadway] transforming event: %{id: 2264493728}

10:10:39.349 [debug] [MyBroadway] transforming event: %{id: 4033891075}

10:10:39.349 [debug] [MyBroadway] transforming event: %{id: 2065156038}

10:10:39.349 [debug] [MyBroadway] transforming event: %{id: 4625753942}

10:10:39.349 [debug] [MyBroadway] transforming event: %{id: 2587137776}

10:10:39.349 [debug] [MyBroadway] transforming event: %{id: 6481119527}

10:10:39.349 [debug] [MyBroadway] transforming event: %{id: 6661902836}

10:10:39.353 [debug] [MyBroadway] Incoming Message: %Broadway.Message{data: %{id: 2730249896}, metadata: %{}, acknowledger: {MyBroadway, :trackings, :ack_data}, batcher: :default, batch_key: :default, batch_mode: :bulk, status: :ok}

10:10:39.353 [debug] [MyBroadway] Incoming Message: %Broadway.Message{data: %{id: 8277765695}, metadata: %{}, acknowledger: {MyBroadway, :trackings, :ack_data}, batcher: :default, batch_key: :default, batch_mode: :bulk, status: :ok}

10:10:39.353 [debug] [MyBroadway] Incoming Message: %Broadway.Message{data: %{id: 917212511}, metadata: %{}, acknowledger: {MyBroadway, :trackings, :ack_data}, batcher: :default, batch_key: :default, batch_mode: :bulk, status: :ok}

10:10:39.353 [debug] [MyBroadway] Incoming Message: %Broadway.Message{data: %{id: 2264493728}, metadata: %{}, acknowledger: {MyBroadway, :trackings, :ack_data}, batcher: :default, batch_key: :default, batch_mode: :bulk, status: :ok}

10:10:39.353 [debug] [MyBroadway] Incoming Message: %Broadway.Message{data: %{id: 4033891075}, metadata: %{}, acknowledger: {MyBroadway, :trackings, :ack_data}, batcher: :default, batch_key: :default, batch_mode: :bulk, status: :ok}

10:10:39.354 [debug] [MyBroadway] Incoming Message: %Broadway.Message{data: %{id: 2065156038}, metadata: %{}, acknowledger: {MyBroadway, :trackings, :ack_data}, batcher: :default, batch_key: :default, batch_mode: :bulk, status: :ok}

10:10:39.354 [debug] [MyBroadway] Incoming Message: %Broadway.Message{data: %{id: 4625753942}, metadata: %{}, acknowledger: {MyBroadway, :trackings, :ack_data}, batcher: :default, batch_key: :default, batch_mode: :bulk, status: :ok}

10:10:39.354 [debug] [MyBroadway] Incoming Message: %Broadway.Message{data: %{id: 2587137776}, metadata: %{}, acknowledger: {MyBroadway, :trackings, :ack_data}, batcher: :default, batch_key: :default, batch_mode: :bulk, status: :ok}

10:10:39.354 [debug] [MyBroadway] Incoming Message: %Broadway.Message{data: %{id: 6481119527}, metadata: %{}, acknowledger: {MyBroadway, :trackings, :ack_data}, batcher: :default, batch_key: :default, batch_mode: :bulk, status: :ok}

10:10:39.354 [debug] [MyBroadway] Incoming Message: %Broadway.Message{data: %{id: 6661902836}, metadata: %{}, acknowledger: {MyBroadway, :trackings, :ack_data}, batcher: :default, batch_key: :default, batch_mode: :bulk, status: :ok}

10:10:40.355 [debug] [MyBroadway] in default batcher

10:10:40.355 [debug] [MyBroadway] size: 10

10:10:40.355 [debug] [MyBroadway] ack successful: 10, failed: 0

Como pudimos ver, Broadway es una opción muy poderosa para consumir y procesar información, podemos diseñar nuestros pipelines incluyendo distintas fases en el proceso y contamos con múltiples opciones que nos permiten adecuar el comportamiento de acuerdo a nuestro caso de uso.

En este post apenas abarcamos lo básico, algunos recursos muy útiles para consultar:

• El libro Concurrent Data Processing in Elixir
• La documentación oficial

Calls to external services can fail for multiple reasons unrelated to business concerns. You can receive a timeout error, the network can fail, bandwith related errors, etc.

However, some patterns exist to build more reliable systems when dealing with network calls.

Retries

It’s basically about automatically retrying failed requests.

But we need to be careful with this pattern if the action isn’t idempotent.

Circuit breaker

It’s commonly found services or processes depend at some point on an external call, and when this external service fails causes a cascade of failures.

The circuit breaker pattern monitors the failures, if the call fails over a certain number of times in a time frame, opens the circuit preventing new requests that you know will fail.

Background jobs

If we have expensive work that doesn’t require completing all steps to send a response to the client this could be very useful.

Exists a lot of libraries provide us with power background jobs with capabilities like automatic retries, exponential back-off, etc.

But even with these libraries we need to concern about issues like having idempotent jobs, not serializing complex structures like a complete object and using an id instead or performance issues, etc.

Off course exists other patterns depending on the problem to handle o multiple ways to manage the same issue. But this is a start point to know some of them.

Lastly, here are some helpful resources:

• Patterns of Service-Oriented Architecture
• Architecting for Reliability Part 2
• Architecture Patterns - Azure learn
• Architecture Patterns - Redhat articles

Following the “rails way” can conduce to a common result called obese models & obese controllers.

This means that your models and your controllers keep growing when you continuously add the business logic in the same place. Another inconvenience is that you are coupling your use cases or business logic to the infrastructure (the framework, the database, and the input interface).

Imagine a common feature like registering a user, easily you can have the following steps:

1. Save the user in the database
2. Generate a token to handle email confirmation
3. Send an email to confirm the user’s email

You would usually see this logic in the model & controller:

A common approach to handle this is to encapsulate the business logic in a specific class, this pattern has several names like class services, handlers, interactors, etc.

Another important thing to leverage this pattern is to take advantage of solid principles like single responsibility. Having multiple specific purpose classes that our service classes can use like query objects, mailers, jobs, POROs, etc.

I take this one from Sustainable Web Development with Ruby on Rails book:

# app/services/user_creator.rb

class UserCreator
  def create_user(user)
    user.save

    if user.invalid?
      return Result.new(created: false, user: user)
    end

    UserEmailConfirmationJob.perform_async(user.id)

    Result.new(created: user.valid?, user: user)
  end

  class Result
    attr_reader :user

    def initialize(created:, user:)
      @created = created
      @user = user
    end

    def created?
      @created
    end
  end
end

Usage:

# app/controllers/users_controller.rb

class UsersController < ApplicationController
  ...

  def create
    user_params = params.require(:user).permit(:email, :password)

    result = UserCreator.new.create_user(User.new(user_params))

    if result.created?
      redirect_to user_path(result.user)
    else
      @user = result.user
      render :new, status: :unprocessable_entity
    end
  end
end

Some considerations:

• This class performs business logic and expects some specific kind of data to make an action. Type casting, input sanitization, etc. These things are infrastructure concerns, not the business.
• Return rich result objects provide more useful details than a single boolean. This is very useful for tests and readability.
• Explicit method names like create_user provide more context than a generic method like call or execute.

Finally, you get some nice advantages: the possibility of testing your business logic independently of the input interface. If your SSR app change to an API REST (or you have both) this will be easy to handle.

For example, take this generated test code from mix phx.gen.auth task:

test "renders log in page", %{conn: conn} do
  conn = get(conn, Routes.user_session_path(conn, :new))
  response = html_response(conn, 200)
  assert response =~ "Log in"
  assert response =~ "Register</a>"
  assert response =~ "Forgot password?</a>"
end

It’s completely ok. But, you can prefer something like this:

test "renders log in page", %{conn: conn} do
  response =
    conn
    |> get(Routes.user_session_path(conn, :new))
    |> html_response(200)

  assert response =~ "Log in"
  assert response =~ "Register</a>"
  assert response =~ "Forgot password?</a>"
end

In this way, you don’t rebind the conn and take advantage of the pipe operator.

• Exist one or more libraries but are unmaintained.
• There is no library at all.
• Existing libraries do not fit our requirements.

At this point, you could take the following paths.

1 Build a service module in your app

Maybe you just need to consume some endpoints and already use some HTTP client like Tesla. In this case, you can use the usual path:

defmodule GitHub do
  use Tesla

  plug Tesla.Middleware.BaseUrl, "https://api.github.com"
  plug Tesla.Middleware.Headers, [{"authorization", "token xyz"}]
  plug Tesla.Middleware.JSON

  def user_repos(login) do
    get("/users/" <> login <> "/repos")
  end
end

2 Build a custom API client

Sometimes you want/need to do it yourself in a library way :). In this case you can follow the pattern mentioned in the Goth redesign.

Use an HTTP client contract:

Using behaviours you can define a contract for the HTTP client. With this contract you can implement the contract and use the HTTP client library that you want:

defmodule API.HTTPClient do

  @type method() :: atom()

  @type url() :: binary()

  @type status() :: non_neg_integer()

  @type header() :: {binary(), binary()}

  @type body() :: binary()

  @doc """
  Callback to make an HTTP request.
  """
  @callback request(method(), url(), [header()], body(), opts :: keyword()) ::
              {:ok, %{status: status, headers: [header()], body: body()}}
              | {:error, Exception.t()}

  @doc false
  def request(module, method, url, headers, body, opts) do
    module.request(method, url, headers, body, opts)
  end
end

Implement the HTTP Client contract

Hackney is a popular HTTP client library, so this can be the default implementation.

defmodule API.HTTPClient.Hackney do
  @behaviour API.HTTPClient

  @impl true
  @spec request(atom(), String.t(), list(), String.t(), Keyword.t()) ::
          {:ok, map()} | {:error, any()}
  def request(method, url, headers, body, opts) do
    with {:ok, status, headers, body_ref} <- :hackney.request(method, url, headers, body, opts),
         {:ok, body} <- :hackney.body(body_ref) do
      {:ok, %{status: status, headers: headers, body: body}}
    end
  end
end

Then you can set this as default in the api client config:

config :api, http_client: API.HTTPClient.Hackney

Using the HTTP client

defmodule API.Resource do

  def get_resource() do
    url = "https://#{Application.fetch_env!(:api, :base_url)}/api/<resource>"

    headers = build_headers()

    result =
      :api
      |> Application.fetch_env!(:http_client)
      |> HTTPClient.request(:get, url, headers, "", [])
      |> handle_response()

    case result do
      {:ok, response} -> {:ok, response}
      {:error, error} -> {:error, error}
    end
  end

  defp build_headers() do
    [
      {"content-type", "application/json"}
    ]
  end

  defp handle_response({:ok, %{status: status, body: body}}) when status in [200, 201] do
    case Jason.decode(body) do
      {:ok, attrs} -> {:ok, attrs}
      {:error, reason} -> {:error, reason}
    end
  end

  defp handle_response({:ok, response}) do
    {:error, Jason.decode!(response.body)}
  end

  defp handle_response({:error, exception}) do
    {:error, exception}
  end
end

Custom implementation

If you don’t use hackney and you use another client like Finch or Mint instead, you can implement the contract yourself:

defmodule MyApp.Extensions.API.FinchClient do
  @behaviour API.HTTPClient

  @impl true
  def request(method, url, headers, body, opts, initial_state) do
    opts = Keyword.merge(initial_state.default_opts, opts)

    Finch.build(method, url, headers, body)
    |> Finch.request(initial_state.name, opts)
  end
end

Then you can use the new implementation in your app config:

config :api,
  http_client: MyApp.Extensions.API.FinchClient,
  base_url: "..."

Advantages:

You can make the default http client dependency optional in your API client: {:hackney, "~> 1.7", optional: true}

Who use the API client can pick their HTTP client, exists a lot of options to choose. Read some at: The State of Elixir HTTP Clients

Avoid duplication of dependencies. If you’re already using hackney great! But if you are already using another client, you are not forced to download and use Hackney additionally.

Who use the API client can use the http client contract to test inside their app using Mox. More about this in: Mocks and explicit contracts

Share code between the organization projects. Preventing writing the same functionality multiple times

Finally, you can see another example in the Tesla library:

• Tesla.Adapter (behaviour)
• Tesla.Adapter.Hackney (contract implementation)

A veces, no todo es un escenario perfecto y puede que para alimentar de información tu aplicación necesitas; no conectarte a una API, si no subir archivos CSV’s.

Si es el caso, no quieres que quien sea responsable de esta tarea tenga que subir de 100 en 100 registros por que si sube un archivo con 101, el servidor tarda demasiado en responder, el navegador muestra un error de timeout y la carga se interrumpe.

Es decir, lo que buscamos es procesar archivos CSV’s grandes, con miles de registros.

Proceso general

Podemos resumir el proceso en los siguientes pasos

1. El usuario envía un archivo al servicio
2. El servicio recibe el archivo y llamas un código similar a este

Task.start(fn -> Modulo.procesar_csv(plug_upload) end)

3. El servicio contesta el request con algo como: “archivo recibido”

La propuesta tiene 2 inconvenientes:

• Si el Task falla estamos perdidos, no tenemos forma de recuperarnos
• Phoenix utiliza el plug Plug.Upload, un GenServer para manejar los archivos cargados.

El problema es que este archivo únicamente vive durante el ciclo de vida de la petición, por lo que si usamos algo como Streams, el archivo terminara despareciendo sin haber concluido el proceso.

Debido a la limitación anterior el flujo se vería modificado de la siguiente manera:

1. El usuario envía un archivo al servidor
2. El servicio recibe el archivo y lo copia a una carpeta del sistema
3. Se ejecuta el procesamiento del archivo de forma asíncrona con una tarea supervisada (utilizaremos Task.Supervisor.async_nolink)
4. El servicio responde la petición
5. Al terminar de procesar el archivo, este es borrado del servidor

Configuración

Primero necesitamos agregar Task.Supervisor al supervisor de nuestra aplicación. Si usamos Phoenix lo encontraremos en el archivo my_app/lib/app/application.ex:

def start(_type, _args) do
    # List all child processes to be supervised
    children = [
      # Start the Ecto repository
      App.Repo,
      # Start the PubSub system
      {Phoenix.PubSub, name: App.PubSub},
      # Start the endpoint when the application starts
      AppWeb.Endpoint,
      {Task.Supervisor, name: App.TaskSupervisor},
    ]

    # See https://hexdocs.pm/elixir/Supervisor.html
    # for other strategies and supported options
    opts = [strategy: :one_for_one, name: App.Supervisor]
    Supervisor.start_link(children, opts)
  end

Guardar el archivo en el servidor

Como dijimos que queremos guardar el archivo en el servidor para poder procesarlo mas tarde sin mantener la conexión con el cliente abierta, creamos un pequeño modulo para esto:

defmodule MyApp.Files do
	@spec move_to_server(Plug.Upload.t()) :: {:ok, String.t())
	def move_to_server(%Plug.Upload{} = upload_params) do
		tmp_dir = System.tmp_dir!() # Nos da un directorio temporal de escritura

    extension = Path.extname(upload_params.filename)
    tmp_file = Path.join(tmp_dir, "#{Ecto.UUID.generate()}#{extension}")

		File.cp(upload_params.path, tmp_file)
	end
end

Server

Ahora crearemos un server, este se encargara de llamar a la tarea y verificar su estatus

defmodule MyApp.FileServer do
  use GenServer

	alias MyApp.Files

  def start_task do
    GenServer.call(__MODULE__, :start_task)
  end

  # In this case the task is already running, so we just return :ok.
  def handle_call(:start_task, _from, %{ref: ref} = state) when is_reference(ref) do
    {:reply, :ok, state}
  end

  # The task is not running yet, so let's start it.
  def handle_call({:process_file, upload_params}, _from, %{ref: nil} = state) do
		{:ok, path_to_file} = Files.move_to_server(upload_params)
    task =
      Task.Supervisor.async_nolink(MyApp.TaskSupervisor, fn ->
        Modulo.procesar_csv(path_to_file)
      end)

    # We return :ok and the server will continue running
    {:reply, :ok, %{state | ref: task.ref}}
  end

  # The task completed successfully
  def handle_info({ref, answer}, %{ref: ref} = state) do
    # We don't care about the DOWN message now, so let's demonitor and flush it
    Process.demonitor(ref, [:flush])
    # Do something with the result and then return
    {:noreply, %{state | ref: nil}}
  end

  # The task failed
  def handle_info({:DOWN, ref, :process, _pid, _reason}, %{ref: ref} = state) do
    # Log and possibly restart the task...
    {:noreply, %{state | ref: nil}}
  end
end

Este server, ejecuta una tarea, guarda en el estado la referencia de esta tarea. Si ya tiene una tarea en el estado y recibe una nueva llamada responde un :ok pero no toma la nueva tarea.

Este comportamiento es útil en mi caso, ya que los registros van a la base de datos, procesar un solo archivo a la vez evita tener problemas de recursos (por ejemplo).

Cuando la tarea termina o falla, se recibe el mensaje :DOWN, si la tarea se completo reason será :normal. En caso contrario podemos notificar o manejar el caso según lo necesitemos cuando sabemos que la tarea fallo.

En ambos casos, limpia el estado y ahora puede recibir un nuevo archivo para ser procesado.

En mi caso particular, notifico por email cuando la tarea finalizo y si hubo errores los recolecto en un CSV que se adjunta al email.

Links útiles:

https://dockyard.com/blog/2019/02/13/understanding-test-concurrency-in-elixir

https://hexdocs.pm/elixir/Task.Supervisor.html#async_nolink/3-compatibility-with-otp-behaviours

A diferencia de la entrada pasada utilizaremos los filtros de validación en lugar de los de saneamiento. Recordemos el formulario del ejemplo anterior:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>Formulario sencillo</title>
    <link rel="stylesheet" href="">
</head>
<body>
    <form action="datos.php" method="POST" >

        <label> Nombre </label>
        <input type="text" name="nombre" required>

        <label> Telefono </label>
        <input type="text" name="telefono" required>

        <label> Email </label>
        <input type="text" name="email" required>

        <label> Mensaje </label>
         <textarea rows="4" cols="0" name="mensaje" required>

        </textarea>

    </form>
</body>
</html>

Después de utilizar filter_var() para sanear los datos podemos utilizarla para validarlos como sigue:

datos.php

<?php

$nombre = $_POST['nombre'];
$telefono = $_POST['telefono'];
$email = $_POST['email'];
$mensaje = $_POST['mensaje'];

filter_var($telefono,FILTER_VALIDATE_INT);

if ( filter_var($email,FILTER_VALIDATE_EMAIL) )
{
    echo "El email es valido!";

} else {

    echo "El email es invalido";

}

La principal limitación es la cantidad limitada de filtros para validar. En nuestro ejemplo solo podemos validar el email y un numero entero de esta forma.

Sin embargo no nos quedaremos atrapados ya que la misma función nos permite validar utilizando expresiones regulares.

En la siguiente entrada veremos esta opción y una serie de regex para validar datos comunes.

Adicionalmente puedes ver los otros filtros disponibles (bastante útiles) en: filters_validate

Basicamente Latch se define como un “cerrojo” para nuestras identidades virtuales, puedes incluirlo en muchisimos sitios mediante plugins listos para usar (Wordpress, owncloud, joomla, prestashop, etc), en sitios donde ya esta implementada la funcion como Tuenti o mediante el SDK que ponen a disposición de los desarrolladores en multiples lenguajes.

Con esta herramienta podemos agregar un segundo factor de autenticación o 2FA, basicamente el servicio protegido por esta herramienta solo estara disponible si tenemos el cerrojo abierto, en caso contrario sera imposible acceder a el.

Tambien puede usarse como otras aplicaciónes tipo Google Authenticator, con passwords de un solo uso, aúnque a mi parecer la primera opción es bastante buena y la segunda solo esta disponible en la versión pro.

Por otra parte si bien hay otros tutoriales para realizar esta misma tarea (como este o este otro , por lo que he visto se basan en un plugin anterior que era exclusivo para SSH, despues este se elimino y su funcionalidad se añadio a la de otros plugins en uno especifico para UNIX, por lo que con el animo de aportar me animo a realizar esta entrada.

Bien, lo primero es que ElevenPaths nos proporciona el latch-plugin-unix, que incorpora varias funcionalidades para sistemas UNIX, podemos proteger cuentas de usuario, SSH, FTP, etc, aunque solo lo he utilizado para la segunda opción.

El manual se divide en las siguientes partes para su mejor lectura:

1. Crear una cuenta de desarrollador y una app
2. Instalar las librerias necesarias
3. Instalación y configuración del plugin
4. Configurar el plugin en SSH
5. Parear cuenta
6. Eliminar cuenta y plugin

1.Crear una cuenta de desarrollador:

1. Necesitamos registrarnos en la web oficial como desarrolladores: Esto nos dara acceso a las distintas herramientas necesarias:
   • Ingresar en “Área de desarroladores”
   • Clic en el botón “Reistrarse como desarrollador”
2. Crear una nueva aplicación: Una vez registrados, accedemos al area para desarrolladores, creamos una nueva app, le damos un nombre
3. Por ultimo necesitamos guardar dos datos importantes, el ID de aplicación y la secret_key, los datos que se muestran en la imagen.

• Aqui tenemos otra opción:
  • Podemos crear “operaciones”, para poder controlar acciones por separado, como comente con este plugin podemos proteger tanto el servicio SSH, como las cuentas de usuario, el comando sudo, etc, creando acciones podemos manejarlas de manera separada.
    • Sin embargo estas no son obligatorias, en caso de querer hacer una para el ssh en especifico seria de la siguiente manera:
  • Creamos una operacion llamada “sshd-login” con OTP y LOR desabilitados. Al añadir la operación se creara un id que aparece junto al nombre entre [], tambien lo necesitaremos.

3. Instalar la app de latch para Android, IOS o Windows Phone dependiendo de donde la utilizaremos, desde ahí controlaremos los “cerrojos”.
4. Iniciar Sesión en la aplicación movil utilizando los datos con los que nos registramos en la web de la herramienta.

2. Librerias necesarias:

Ahora ingresamos a nuestro servidor, antes de comenzar todo el proceso es necesario satisfacer algunas dependencias del plugin, librerias necesarias para su funcionamiento, para ello utilizaremos los siguientes comandos:

sudo apt-get install gcc make

sudo apt-get install libpam0g-dev libcurl4-openssl-dev libssl-dev

3. Instalación y configuración del plugin:

1. Necesitaremos descargar el plugin desde https://github.com/ElevenPaths/latch-plugin-unix.

   • Es necesario tener instalado git en el servidor, en caso de no tenerlo ejecutar: sudo apt-get install git

2. Ahora clonamos el repositorio: git clone https://github.com/ElevenPaths/latch-plugin-unix.git

3. Ingresamos a la carpeta donde se descargo el proyecto: cd latch-plugin-unix

4. Ejecutamos el siguiente comando para instalar: ./configure prefix=/usr sysconfdir=/etc && make && sudo make install

5. Editamos el archivo de configuración donde agregaremos la información que obtuvimos al crear la app en la web de Latch, el “Application ID” y “SecretKey” con el comando:

sudo nano /etc/latch/latch.conf

Tendremos el siguiente contenido en la terminal:

# Identify your Application
# Application ID value
#
app_id = REPLACE_APP_ID_HERE

# Secret key value
#
secret_key = REPLACE_SECRET_KEY_HERE

Solo hace falta reemplazar los valores correspondientes.

Opcional:

• Si se creo la operacion sshd-login en la sección #Operations, buscamos la linea:
• ‘sshd-login = REPLACE_OPERATION_ID_HERE’
• Reemplazamos el texto “REPLACE_OPERATION_ID_HERE” por el id que obtuvimos al crear la operación.

Una vez editados los campos, “Ctrl + X” para cerrar, “Y” para confirmar los cambios y un ultimo “Enter” para guardar el archivo.

6. Ahora es necesario mover el archivo pam_latch.so con el comando: sudo mv /usr/lib/pam_latch.so /lib*/*/security

4. Configurar el plugin en el SSH:

1. Editamos el siguiente archivo: sudo nano /etc/pam.d/sshd

2. Debajo de @include common-auth, agregamos la siguiente linea: auth required pam_latch.so config=/etc/latch/latch.conf accounts=/etc/latch/latch.accounts operation=sshd-login otp=no.

   • Las opciones operation=sshd-login otp=no, solo se agregaran en caso de haber configurado la acción sshd-login, en caso contrario las omitimos.

3. Editamos el archivo sshd_config mediante: sudo nano /etc/ssh/sshd_config

   • Buscamos la linea ChallengeResponseAuthentication, la cual debe quedar así: ChallengeResponseAuthentication yes

   • Buscamos PasswordAuthentication y debe quedar: PasswordAuthentication no

   • Nos aseguramos que al final del archivo este la linea: UsePAM yes

   • Si alguna linea esta comentada con # al inicio, se le quita y se cambia el valor al que se menciona.

4. Ahora reiniciamos el servidor SSH:

sudo service ssh restart

5. El ultimo paso es parear la cuenta:

Para esto son necesarios los siguientes dos pasos, ya con la aplicación instalada en nuestro movil:

1. En el móvil:
   • Abrir la aplicación
   • Usamos la opción agregar un nuevo servicio y luego generar nuevo codigo.
2. En la terminal con la sesión de servidor ejecutamos el comando:

latch -p CÓDIGO

• CÓDIGO es el que nos proporciona la app móvil.

Nos devolvera el mensaje:

Account successfully paired to the user USUARIO

Además deberia saltar una alerta en el movil, informando sobre la acción, elegimos la opcion “setup now”, elegimos si quieremos utilizar alguna de las opciones y listo.

####Ahora solo resta probar si todo funciona correctamente: Si el servicio esta desbloqueado y accedemos recibiremos una alerta como la siguiente:

En cambio si esta bloqueado y damos los datos correctos de acceso sera como la siguiente:

Y veremos que no nos permite acceder.

Recordemos que latch no avisa de intentos de acceso, solo cuando se produce un login exitoso, es decir con los datos correctos.

6. Dejar de usar latch:

Podemos desemparejar una cuenta con el comando: latch -u

Esta acción arrojara el mensaje: Account belonging to the user USUARIO successfully unpaired from latch

• Para desinstalar el plugin se deben revertir los cambios realizados en los ficheros, acceder a la carpeta del plugin y ejecutar el siguiente comando: ./configure prefix=/usr sysconfdir=/etc && make && sudo make uninstall

Para información adicional: No pueden perderse la serie de entradas en el blog de El Maligno: Latch: Cómo proteger las identidades digitales No dejen de revisar el GitHub donde encontraran muchisimo codigo he información: https://github.com/ElevenPaths En diversos blogs hay tutoriales para utilizar Latch en diversos sitios, en el mismo blog oficial o en elladodelmal hay muchos post con información muy valiosa sobre esta herramienta.

Aún así es algo de lo que considero no debería dejar de hablarse, siempre sera un tema que para bien o para mal se retomara, ya sea porque se han hecho avances en esta materia o porque hubo un nuevo intento de algún país para tener acceso libre e ilimitado a toda nuestra información personal.

Por cierto, los animo a leer el siguiente articulo, simplemente excelente: Por qué la privacidad es necesaria: desmontando el “no tengo nada que ocultar”.

Así que aquí muestro algunas recomendaciones para ayudar a mejorar la privacidad (que no anonimato) o seguridad de nuestras comunicaciones por distintas vías:

1. Mensajería privada

En la mensajería móvil tenemos un líder indiscutible que es WhatsApp y su rival Telegram, el segundo es el que más se dice respetuoso de nuestra privacidad y preocupados por la seguridad, pero desde el inicio surgieron varias dudas al respecto, principalmente por el hecho de utilizar un protocolo propio (basado en otro) en lugar de uno abierto y probado por su seguridad, por eso la recomendación es:

• TextSecure (Android y Signal para IOS)

En un principio esta app proporcionaba incluso cifrado para SMS, pero le han dicho adiós, aún así nos proporciona cifrado en los mensajes enviados mediante datos móviles o WiFi, por lo que nuestra privacidad se vera mejorada, además es de código.

Otro aspecto es que whatsapp trabajo junto a whispersystems (desarrolladores de Textsecure entre otras apps) para proveer mejoras a la seguridad de su propia aplicación, al menos para las conversaciones 1 a 1.

• Pidgin + OTR (Windows, Linux)

A pidgin, cuantos no te conocen :), aunque este tipo de comunicaciones tipo messenger hace mucho que se “extinguieron”, siempre podemos utilizar software como pidgin que es multiprotocolo y utilizar nuestras cuentas de correo, XMPP o incluso facebook para comunicarnos con nuestros contactos y si a esto le agregamos el plugin Off-the-Record Messaging (OTR) tendremos nuestros mensajes cifrados.

2. Llamadas

Aunque para cifrar las llamadas comunes que realizamos utilizando nuestra operadora existe hardware especializado, este es caro y poco accesible, para este tema nuestra mejor opción es hacer uso de datos móviles o una conexión WiFi y utilizar alguna aplicación estilo Line o Viber pero con énfasis en la seguridad:

• RedPhone (Linux, Singal en IOS)

De la misma gente que TextSecure, nos proporciona llamadas cifradas, ambas aplicaciones utilizan nuestro numero telefónico, además si llamamos a un contacto de forma normal y este tiene RedPhone instalado nos dará la opción de realizar la llamada utilizándolo. para mas información recomiendo el siguiente articulo (muy completo) Cómo llamar por teléfono conservando la privacidad con Redphone

Alternativas a Skype

Skype es una herramienta muy útil, aunque no muy recomendada por aquellos que se preocupan de la privacidad, aquí no hay muchas opciones pero en lo personal he probado jitsi:

• Jitsi (Windows, Linux, Mac)

Es un cliente multiprotocolo opensource (al igual que las anteriores), nos permite mantener chat y llamadas de voz o vídeo cifradas, bastante bueno en general. Lo mas próximo además de esta alternativa quizá sea Tox, aunque aún esta en desarrollo.

3. Correo electrónico

El email continua siendo un imprescindible en las comunicaciones, muchas veces se envía información sensible como datos bancarios, documentación personal entre otros sin ningún tipo de protección, pero podemos fácilmente mejorar esto.

• PGP

Aquí nuestra mejor alternativa es utilizar GnuPG, una implementación libre de GPG que nos permite cifrar de forma asimétrica cualquier mensaje que sera enviado mediante un medio potencialmente inseguro como el correo electrónico.

Al decir asimétrico se refiere a que se utiliza una clave publica para cifrar, esta se le proporciona a quien quiera enviarnos un mensaje, y para descifrar la información se utiliza una clave privada, la cual no necesitamos compartir. Esto elimina el problema de tener que compartir la contraseña para descifrar un archivo por un medio tan o más inseguro como por el que pasaríamos la información :p.

Suena complejo y de cierta forma lo es, pero la gente de FayerWayer no explican como usarlo sin dolor en: Qué es y cómo usar PGP en tu vida diaria.

###Bonus: utilizar VPN Si queremos mejorar aún mas el tema de la privacidad y seguridad de nuestros datos siempre podemos optar por utilizar una VPN, estas generan un “tunel” por donde nuestra información viaja cifrada de nuestro equipo al destino.

Este tipo de soluciones es especialmente recomendable si utilizamos redes inalámbricas abiertas, en el aeropuerto o ese evento geek donde todos están conectados a la misma red, ya que nunca falta el que usa un sniffer para escuchar las comunicaciones que pasan, en estos casos también son tremendamente útiles para mejorar nuestra seguridad.

Pongamos un ejemplo: Tenemos un pequeño codigo que solicita al usuario ingresar un numero e imprimir si este es par o impar, aquí es donde utilizaríamos el control de flujo, para realizar una acción u otra de acuerdo a una validación.

Estas “validaciones” se realizan mediante dos sentencias, if y else, que básicamente vendría a ser, si, si no.

Para el ejemplo seria: Si el numero es par, imprime “es par”, si no (por eliminación es impar), imprime “es impar”

Ahora if es una función que puede devolver dos resultados, true o false, de acuerdo al resultado de lo que preguntemos, y a continuación ejecutara las instrucciones que le indiquemos, en caso contrario ejecutara lo que le indiquemos en else, este ultimo, aunque no es obligatorio incluirlo, si es recomendable utilizarlo.

Veamos como queda en código:

#include <stdio.h>

int main()
{
	int numero;

	printf("Ingrese un número \n");
	scanf("%d",&numero);

	if(numero%2 == 0) // si el resultado es true ejecutara lo siguiente
	{
		printf("El numero %i es par \n",numero);
	}
	else // si no, ejecutara esto
	{
		printf("El numero %i es impar \n",numero);
	}

	return 0;
}

Como puedes observar, ahora estamos utilizando varias de las cosas que explicamos en las primeras entradas ademas del tema actual:

• Declaración de variables.
• Entrada y salida de datos.
• Operadores aritméticos y de comparación.
• Control de flujo.

Ahora la explicación:

1. Imprimimos un mensaje y leemos lo que el usuario ingresa mediante el teclado, esto ya lo vimos, si no los has visto puedes visitar el post :)
2. El if (esto es lo interesante):

• Estamos realizando una operación y verificando su resultado, decimos que si el modulo de lo que contiene numero es 0, es decir si numero%2 == 0 es verdadero, imprima el mensaje que indica que el numero es par.
  • A modo de repaso, recordemos que el operador modulo(%), devuelve el residuo de una división, por lo que si el resultado del modulo (o el residuo) de cualquier numero entre 2 es 0, significa que este es par, así es como validamos.
• En caso de ser falso imprimirá el mensaje indicando que el numero es impar.

Solo para mostrar otra forma en que podriamos interpretar el ejercicio veremos el siguiente código (espero no se se preste a confusiones, en caso de ser así omitirlo es permisible por ahora):

#include <stdio.h>

int main()
{
	int numero;

	printf("Ingrese un número \n");
	scanf("%d",&numero);

	if(!numero%2 == 0) // si el resultado es true ejecutara lo siguiente
	{
		printf("El numero %i es impar \n",numero);
	}
	else // si no, ejecutara esto
	{
		printf("El numero %i es par \n",numero);
	}

	return 0;
}

¿Cual es la diferencia?, hemos invertido la lógica utilizada, ahora decimos: Si numero%2 == 0, no es cierto (Es lo que hace el agregar el signo ! al inicio), el resultado sera true, por lo que el numero es impar, en caso contrario es par.

¿Confuso?, sin duda lo es al inicio, algunas personas prefieren hacerlo de esta forma, pero no hace falta romperse la cabeza por ahora con este ejemplo, conforme desarrollemos nuestra lógica de programación entenderemos mejor estas variaciones, el objetivo es mostrar que no existe una única forma de hacer las cosas :).

Al final concluimos que estas sentencias son sumamente útiles, no por nada siempre se incluyen en temarios básicos de programación, pero con el tiempo y la practica aprenderemos usos mas avanzados de esta sentencia, pero en esta entrada lo dejaremos aquí.

• Como cualquier variable debe declararse su tipo
• Solo puede albergar valores del tipo con el que fue declarado
• Debe indicarse la longitud del array al ser declarado
• Cada elemento guardado tendrá una posición en el array, posición 0, 1 o 2 etc
• La primera posición de un array es la 0, no la 1

Ahora veamos un ejemplo, crearemos un arreglo de tipo char, con una longitud de 9 espacios que contendrá el texto: “HolaMundo”.

#include <stdio.h>


int main()
{
	char cadena[9] = "HolaMundo";

	printf("La primera letra es %c",cadena[0]);
	printf("El texto es %s",cadena);

	return 0;
}

Como comentamos, se declaro un array de caracteres con una longitud de nueve elementos (La longitud va entre corchetes) y se le asigno el texto “HolaMundo” (Que al ser texto va entre comillas dobles).

En la siguiente linea se imprime la primera letra de la cadena, que seria “H”, se imprime la variable de la misma forma que se explicó en entradas anteriores, en la la posición 0 (se indica entre corchetes al igual que cuando se declara).

En la penúltima linea se imprime la cadena entera, para no tener que imprimir cada posición por separado se utiliza %s, para indicar que ahí va una variable de tipo cadena (o string).

Este tipo de estructuras de datos podemos aplicarlas a distintos tipos de datos, como int o double, colecciones de datos muy útiles sin duda.

Como nota, de igual forma que declaramos arreglos unidimensionales , podríamos declararlos bidimensionales (una matriz) con la siguiente notación: tipo de dato + nombre del array + [longitud de las filas][longitud de las columnas].

int matriz[3][3];

Con lo anterior tendríamos una matriz de 3x3: 3 filas y 3 columnas.

Ahora, una tarea muy común es la de recorrer un arreglo, en el caso de estos ejemplos que son muy simples recorrerlos en tarea fácil ya que conocemos de antemano su longitud, solo haría falta utilizar alguna estructura como un for (Que veremos mas adelante) para recorrer todas las posiciones:

#include <stdio.h>


int main()
{
	char numeros[4] = { 1, 2, 3, 4 };
	int i=0;
	for (i ; i<4; i++)
	{
		printf("El numero es %d",numeros[i]);
	}

	return 0;
}

La salida de lo anterior seria: 1 2 3 4

No es necesario entender todo el código anterior, ya explicaremos la sentencia for, pero es útil tratar de analizar dicho código por uno mismo :).

• Tipos de datos
• Operadores
• Variables y sintaxis basica
• Entrada y salida de datos

Sin embargo, esto nos nos sirve si no sabemos aplicarlo a la resolución de un problema, la logica de programación es algo que no se suele tomar en cuenta en una serie de post como esta, sin embargo en escribocodigo haremos el esfuerzo de utilizar algunos problemas sencillos para poder desarrollar lo que presumiblemente hemos aprendido.

Y es que, al final de todo si solo estudiamos algo “teoricamente” el conocimiento esta incompleto, falta la otra mitad, la practica para poder comprender completamente eso que estamos estudiando.

Por lo que es hora de poner en practica un poco lo aprendido, en esta entrada hay un ejercicio sugerido de nivel basico, la idea es que traten de resolverlo sin buscar en google o ver el codigo de la respuesta (que se colocara mas abajo), a menos que de verdad sientan que no pueden resolverlo, intenten resolverlo por su cuenta. Tanto para este ejercicio como para los siguientes.

El problema:

Guillermo tiene N pesos. Luis tiene la mitad de lo que posee Guillermo. Juan tiene la mitad de lo que poseen Luis y Guillermo juntos. Realiza un programa que capture mediante teclado la cantidad que tiene Guillermo, además que calcule e imprima la cantidad de dinero que tiene cada uno y el que tienen entre los tres.

Por supuesto, si conocen mas problemas de este tipo que seria bueno resolver en este punto no duden en comentarlos.

La idea es que al finalizar esta entrada tengamos todo configurado para poder acceder a Ghost mediante nuestro propio .com, .net, etc y de acuerdo a nuestra preferencias, para este caso utilizando la forma sin www, de modo que al ingresar a www.midomino.com redireccione a midominio.com.

El objetivo es aprender a configurar un dominio con esta plataforma y un droplet de DigitalOcean, en lo personal tuve varios inconvenientes en este tema (cuestión de la inexperiencia jaja), no es tema de esta entrada explicar como instalar la plataforma ya que gracias a las herramientas que se nos proporcionan es muy facil, pero los pasos se resumen en los siguientes:

Iniciar sesión en DO y clic en “Create Droplet”:

1. Seleccionar el tamaño y costo
2. Elegir una ubicación o región
3. En la opción select image serán dos pasos:
   • En la pestaña “Linux Distributions” elegimos la distribución linux a instalar, recomiendo Ubuntu o Debian
   • En la pestaña “Aplications” seleccionamos Ghost

Listo, creamos el droplet y se nos enviaran por correo los datos de acceso.

NOTA: Algunas opciones en “Settings” como “enable backups” conllevan un costo asociado, hay que elegir adecuadamente.

Ahora ya con Ghost instalado, veremos que podremos acceder mediante la ip que nos proporciona el servidor, pero nosotros queremos ingresar mediante el dominio que compramos. Sera necesario trabajar en 4 lugares:

• En la configuración servidor (Nginx)
• En la configuración de Ghost
• Donde tengamos el dominio registrado
• En DigitalOcean.

Como aviso, antes de realizar los pasos se recomienda agregar ambas formas de nuestra dirección (con y sin www) a Google Web Master Tools y elegir el de nuestra preferencia en la configuración para efectos de SEO, más aún si se realiza una migración y ambos dominios estaban activos.

###En el servidor:

Debemos ingresar a nuestro VPS con los datos enviados a nuestro correo al momento de crear el Droplet, una vez ahí ingresamos el siguiente comando:

sudo nano /etc/nginx/sites-available/ghost

NOTA: Agrego ‘sudo’ ya que en este caso el usuario root esta deshabilitado, en caso dcontrario no hace falta

Ahora nos movemos en el contenido del archivo con las flechas del teclado y veremos que en server_name pone my-ghost-blog.com, a nosotros nos debe quedar de la siguiente manera:

  server_name midominio.com www.midominio.com;

    if ($host = 'www.midominio.com' ) {
            rewrite  ^/(.*)$  http://midominio.com/$1  permanent;
    }

Solo hace falta reemplazar las direcciones con las nuestras.

Ojo con usar “Ctrl + c” o “Ctrl + v”, estamos en el editor nano y aqui no funcionan :).

Una vez editado pulsamos Ctrl + x, nos pregunta si queremos guardar los cambios escribimos y , por último enter para confirmar la edición.

###En la configuración de Ghost

Ahora utilizamos el comando:

sudo nano /var/www/ghost/config.js

Repetimos la operación anterior cambiando ‘my-ghost-blog.com’ por el que tengamos y los mismos pasos para guardar.

Ahora toca reiniciar los servicios:

Para reiniciar ghost: service ghost status

Para reiniciar NginX: /etc/init.d/nginx restart

###En el registrador de dominios:

Aquí necesitamos cambiar los DNS que gestionan nuestro dominio, puede varias dependiendo del registrador, pero en NameCheap es así:

1. Vamos a la opción “Manage Domains”
2. Elegimos el dominio que configuraremos
3. En “NAME SERVER INFORMATION” usaremos la opción: “Specify Custom DNS Servers ( Your own DNS Servers )”
4. Llenamos los datos con las DNS de DO:
   • ns1.digitalocean.com
   • ns2.digitalocean.com
   • ns3.digitalocean.com
5. Save Changes y listo

###En DO:

1. Después de loguearnos vamos a la opción DNS
2. Elegimos: “Add Domain”
3. En Name ponemos el dominio
4. En IP Address iría la ip que nos corresponde, tenemos un menú desplegable donde elegimos el droplet que creamos y este dato se llena automáticamente.

Ahora veremos que tenemos un registro de tipo A creado.

Nosotros agregaremos un nuevo registro de tipo CNAME:

1. Clic en “Add Record” y elegir CNAME
2. En Name ponemos: www
3. En Hostname va: @
4. Clic en Create.

Listo, ahora llevara un tiempo para que los DNS se propaguen y podamos acceder mediante el dominio, después de eso notaremos que si utilizamos la dirección con www nos redirige (de esto se encarga la configuración de Nginx), por lo que todo quedo como esperabamos :).

Sin duda parece engorroso el proceso (pero es lo que hay por ser hipsters y utilizar una plataforma no mainstream :p), sin embargo es parecido al que haríamos en otras plataformas, aunque WordPress ofrece mas facilidades para elegir la preferencia del dominio por ejemplo.

Ahora que todo esta listo (por fin!) todos podemos comenzar a disfrutar tu blog o sitio web, si tienen dudas no olviden dejar un comentario.

Básicamente necesitaremos la librería stdio.h, incluirla nos permitirá utilizar la función printf(); que sirve para mostrar texto en pantalla y scanf(); que nos permite leer datos introducidos mediante el teclado.

Antes debemos recordar que al ser un lenguaje estricto con los tipos de datos, deberemos tratar cada dato de acuerdo a su tipo, para realizar una entrada simple de datos tendríamos el siguiente código:

#include <stdio.h>

int main()
{
	int numero;
	printf("Introduce un numero \n");
	scanf("%d",&numero);
	printf("El numero es %d",numero);

	return 0;
}

Como vemos, primero declaramos una variable de tipo Entero(int) llamada numero, despues imprimimos el texto “Introduce un numero” seguida de \n (esto nos indica un salto de linea).

En la siguiente linea leemos el dato, scanf tiene la siguiente estructura: scanf("%x",&variable), donde x corresponde a una letra de acuerdo al tipo de dato que se debe recibir, d para int, c para char, etc. Siempre entre comillas dobles, una coma, el signo “&” (ampersand) junto al nombre de la variable.

Después volvemos a usar la función printf, pero ahora imprime también una variable, para esto se sigue un criterio similar, con %d, para indicar el tipo de variable a imprimir (Esto dentro de las comillas dobles), despues de la coma el nombre de la variable, esta vez sin el sigo `&``.

Si imprimieramos mas variables en una sola linea solo basta agregar un %d por cada variable que se desea imprimir y donde se mostrara, de igual forma después de la coma irán los nombre de las variables (separadas por comas) en el orden en el cual aparecerán, recuerda que % debe ir seguido de la letra correspondiente al tipo de variable.

Terminaremos con el siguiente ejemplo:

#include <stdio.h>

int main()
{
	int numero, numero2;
	printf("Introduce un numero \n");
	scanf("%d",&numero);
	printf("Introduce un segundo numero \n");
	scanf("%d",&numero2);
	printf("Los numeros son %d y %d \n",numero, numero2);

	return 0;
}

En el próximo post veremos uno o dos ejercicios simples para practicar lo visto hasta ahora y desarrollar un poco la soltura de la sintaxis. Si tienes dudas no dudes en comentarlo.

###Plugins recomendados para Sublime Text:

Uso varios, para diferentes funciones, pero están esencialmente destinados para desarrollo web, estos son:

Bracket Highlighter: La función de este plugin es “sencilla” pero extremadamente útil, algo que ST debería incluir por defecto, que es resaltar el inicio y cierre de las llaves { }.

Color Highlighter: Cuando realizas diseño web se suelen utilizar colores en hexadecimal, rgb, etc, Color Highlighter nos permite saber del color que se trata tan solo dando clic en el código hexadecimal, este se iluminara de acuerdo al color del que se trate.

Color Picker: Nos permite utilizar la paleta de colores del sistema utilizando la combinación de teclas ‘Ctrl + shift + c’, con ella podremos seleccionar colores en hexadecimal desde ST

HTML5: Para agregar soporte para esta versión de HTML a ST.

EMMET: Un plugins con un potencial enorme, antes llamado zend-coding, nos permite ahorrar tiempo y trabajo cuando escribimos HTML, ya que al escribir una linea de código y pulsar tabulador podemos obtener grandes resultados, podemos pasar de esto:

nav#navegacion>ul>li.navegacion_elemento*5>a

a esto:

<nav id="navegacion">
	<ul>
		<li class="navegacion_elemento"><a href=""></a></li>
		<li class="navegacion_elemento"><a href=""></a></li>
		<li class="navegacion_elemento"><a href=""></a></li>
		<li class="navegacion_elemento"><a href=""></a></li>
		<li class="navegacion_elemento"><a href=""></a></li>
	</ul>
</nav>

Al principio puede intimidar un poco, pero se volverá imprescindible.

AutoFileName: Editores como Brackets tienen una genial característica que es mostrar los archivos que tenemos conforme escribimos rutas en el código, por ejemplo si utilizamos un ‘require’ en PHP, conforme escribamos la ruta para incluir nuestro archivo se irán mostrando las carpetas y archivos que estén en el mismo nivel, esto nos ahorra mucho tiempo al incluir archivos y con este plugin añadimos esto a nuestro editor.

###Configuraciones útiles:

ST es un editor sumamente personalizable, podemos modificar múltiples aspectos, para esto vamos a Preferences>Settings - User, ahí podemos agregar las siguientes opciones:

Cambiar la fuente: Para ello añadimos la siguiente linea:

"font_face": "SourceCodePro-Medium",

Como verán yo estoy utilizando la fuente SourceCodePro-Medium, pero pueden utilizar cualquier fuente que este instalada en su sistema, esto resulta provechosos ya que existen fuentes mas recomendables para el código que las “comunes”, con mono espaciado y otras características.

Resaltar la linea actual:

Solo hace falta añadir la siguiente linea:

"highlight_line": true,

Resaltar las pestañas con cambios:

Por defecto al modificar el contenido de un archivo ST señala la pestaña del mismo de una forma muy sutil, para mejorar esto agregamos:

"highlight_modified_tabs": true,

Guardar los cambios al cambiar de ventana:

Después de utilizar esta opción me resulta incomodo tener que presionar Ctrl + s cada vez que quiero guardar un cambio, mas si esto significa que iras a ver dicho cambio en el navegador, agregando la opción:

"save_on_focus_lost": true,

ST guardara los cambios realizados cada vez que pierda el foco, es decir cada ves que cambiemos de ventana.

Resaltar las carpetas de los archivos en el sidebar:

Si tienes muchos proyectos en el sidebar de ST, posiblemente se vuelva confuso el árbol de archivos, para resaltar las carpetas de los archivos agregamos la siguiente linea:

"bold_folder_labels": true,

Y eso es todo, con estos plugins y configuraciones tenemos un Sublime Text listo para la acción. Seguro pareciera que mi perfil es frontend, pero no!, jeje es backend.

Como comentario final quisiera hacer énfasis en una idea, que es sacarle el máximo provecho a nuestro editor, mas allá de si utilizas uno u otro, muchas veces desperdiciamos características geniales de cada editor, nos quedamos con cosas como el auto completado y nos olvidamos de características como los cursores múltiples o que en sublime text podemos ordenar alfabéticamente los atributos css seleccionándolos y presionado F9, esos shortcuts que ahorran valiosos segundos que terminan significando un incremento en nuestra productividad :).

En fin, es privilegiar nuestras necesidades y comodidad sobre la “moda” de utilizar un editor u otro, date un tiempo de explorar las diversas características que te ofrecen y elige el que mejor te acomode.

int numero=0;
string nombre="MiBlog"; // Las cadenas de caracteres deben ir entre comillas dobles
char caracter[5]="HOLA";

Lo que estamos declarando es una variable de tipo entero (int), es decir números sin decimales como vimos el la primer parte Tipos de datos en C, recordemos que en C debemos indicar explícitamente el tipo de variable a utilizar.

En el caso del tipo char debemos definir una longitud máxima entre corchetes, es decir el máximo de caracteres que contendrá la variable.

Otro aspecto importante es conocer el ámbito de las variables, ya que estas pueden ser globales o locales, las variables globales puedes ser accedidas desde cualquier parte de nuestro programa, en cambio las variables locales solo pueden ser usadas en donde se declararon, por ejemplo una función:

int global; // esta es una variable global
int main(){

	int local; // esta es una variable local
    //y solo pude ser usada en mifuncion
	return 0;

}

Es tiempo de hablar de la sintaxis básica, de la cual ya vimos un poco en las lineas anteriores, C es estricto con su sintaxis, analicemos el ejemplo del primer:

#include <stdio.h>

int main(){

	printf("Hola Mundo!!");
	return 0;

}

#include : se usa para “incluir” librerías (archivos que contienen funciones), en el ejemplo se incluye la librería standar stdio.h que contienen funciones básicas como printf y scanf.

int main() : aquí definimos una función, las funciones son una serie de instrucciones agrupadas, int hace referencia a que se espera que la función devuelva un resultado de tipo entero, main sirve para definir la función principal, por lo que sera la primera en ejecutarse, además, todas las funciones llevan paréntesis ().

Entre los paréntesis podríamos definir argumentos para la función, que básicamente serian variables necesarias para que esta realice su tarea, un ejemplo seria: int funcion(float pi).

Además, para delimitar las instrucciones de una función estas deben estar dentro de los signos { y }, estos delimitan el inicio y el final de la función.

printf("Hola Mundo!!");, es una función estándar, esta tiene varios elementos: printf Esta es una palabra reservada, es decir que es utilizada por el lenguaje y no puede ser usada para otros propósitos como definir variables.

(""); Como vemos si queremos imprimir texto este debe ir entre comillas dobles, y todas las sentencias deben terminar con punto y coma (;).

Esto es todo por esta entrada, a partir de aquí, otros conceptos sobre la sintaxis u otros aspectos se irán explicando en base a ejemplos (Vaya, por fin!!) que utilicemos en los siguientes temas.

###1. De asignación

Con este “asignamos” valores, por ejemplo si queremos asignar a la variable ‘numero’ un valor entero de 10, se hace de la siguiente forma:

int a = 10;

O podemos asignar el valor de otras variables, la variable ‘f’ tendra el valor de otra variable ‘i’ (recordar que C es fuertemente tipado, por lo que deben ser del mismo tipo):

int i=0; int f=i;

###2. Aritmeticos

No requieren de mayor explicación, permiten realizar operaciones aritméticas (suma, resta, multiplicación, división y modulo¹ ), en orden:

• +, ejemplo: 5+5
• -, ejemplo: 3-2
• *, ejemplo: 6*2 (no se usa "x" para multiplicar)
• /, ejemplo: 10/2
• %, ejemplo: 26%2

###3. De comparación

Nos permiten comparar dos expresiones, si la comparación es verdadera se devuelve un valor booleano ‘true’, en caso contrario sera ‘false’:

• == igual que
• != diferente de
• > mayor que
• < menor que
• >= mayor o igual que
• <= menor o igual que

###4. Lógicos

Relacionan expresiones lógicas y devuelven ‘true’ o ‘false’ de acuerdo al resultado.

• && (AND), ejemplo: 7>5 && 8>3 (7 mayor que 5 y 8 mayor que 3, el resultado seria true ya que ambas son ciertas).

• || (OR), ejemplo: 10==5 || 20!= 6 (10 igual que 5 o 20 diferente de 6, el resultado es true ya que 20 es diferente de 6 aunque 10 no sea igual a 5).

Como vemos, si usamos && devolverá true solo si todas las expresiones son ciertas, en cambio || devolverá true si al menos una de las expresiones es cierta. Veremos su utilidad en algunos ejemplos mas adelante.

Espero este quedando claro el tema, ya que estos operadores se utilizan de manera constante cuando programamos, de cualquier forma estos conceptos básicos lo repasaremos de forma practica mas adelante.

Ya, ya se, dirán: “¿Mas párrafos de teoría?, puff hay que escribir código”, ciertamente puede ser aburrido, pero las bases son importantes, conforme avancemos estos conceptos se irán obviando, pero es lo básico que hay que saber y sin las bases sera mas difícil avanzar, así que empecemos.

Es importante conocer que en C, como en la mayoría de lenguajes de programación hay diversos tipos de datos (en unos mas en otros menos), los básicos son:

• int - Numero entero, ejemplo: 10.
• float - Numero real, ejemplo: 3.1416.
• char - Caracter, ejemplo: “a”.

La forma de declararlos es la siguiente:

int main(){

	int numero = 5;
	float numero_flotante = 3.1415;
	char caracter[5]="Hola"; // aquí especificamos la longitud, que sera hasta 5 caracteres


} // todas las funciones en C se delimitan mediante { y }

Existen otros, como: double, long int, etc, etc. De estos no es necesario preocuparse por ahora.

Hay que decir que C es un lenguaje “fuertemente tipado”, es decir que cuando declaremos variables debemos especificar explícitamente su tipo y se deben utilizar solo como se espera que sean usadas, no es como en PHP donde podemos utilizar las variables a diestra y siniestra.

Existen casos donde el compilador se encarga de realizar conversiones, por ejemplo si decimos que utilizaremos una variable con un numero real pero en realidad la que usamos es de tipo entero, no habría problema, se realizaría de forma implícita, pero si son incompatibles, como float (numero real) y char (caracter), se producirá un error.

Por supuesto podríamos hacer conversiones de un tipo a otro, el llamado casting.

Esta entrada servirá a modo de introducción y a su vez de índice para tener en un solo lugar todos los post.

Indice:

1. Introducción (este post)
2. Tipos de datos
3. Operadores
4. Variables y sintaxis básica
5. Entrada y salida de datos
6. Primer ejercicio
7. Array o arreglos
8. Control de Flujo: if y else

###¿Porque un curso? y ¿Porque acerca de C? Afuera hay muchos recursos para aprender a programar, no solo en C, si no en muchísimos lenguajes de programación, la intención no es hacer mas de lo mismo, el principal objetivo es, (aunque quizá no sea el mas adecuado) desempolvar mis propios conocimientos en C, ya que es el lenguaje con el que aprendí a programar y que mejor manera de hacerlo que ayudar a que otros aprendan.

####Entonces, ¿Que es C?

Un lenguaje de programación compilado, de mediano nivel(o de alto nivel si nos ponemos estrictos), con el podemos interactuar directamente con el sistema, incluso incluir lenguaje ensamblador, además ha influenciado a diversos lenguajes como java, PHP, entre otros. Para mas información: C (lenguaje de programación)

¿Que necesitamos para programar en C? Un compilador y un editor de código esencialmente, existen IDE (Entornos de desarrollo integrados) que suelen incluir estas herramientas entre muchas otras para ayudar al desarrollo.

En Windows he utilizado:

• Orwell Dev-C++
• Code::Blocks

Nada mas instalar alguno estaríamos listos para comenzar, por supuesto existen otros especializados o que podemos utilizar para este fin como Codelite, Netbeans o Eclipse.

En linux es un poco mas largo el proceso, un excelente IDE para este propósito en Geany, sin embargo este no cuenta con un compilador instalado, deberos instalarlo aparte y configurar geany para que lo use o compilar desde la terminal

Para esto instalamos geany, en ubuntu y derivadas esta en los repositorios, bastara con:

sudo aptitude install geany

Para instalar el compilador, en este caso gcc (GNU Compiler Collection)

sudo aptitude install gcc

o en su defecto build-essential en lugar de gcc, que instalara otras herramientas.

Ya deberíamos estar listos, podríamos escribir un “Hola mundo” para no quedarnos con las ganas de escribir algo :), en otro post explicaremos la sintaxis:

#include <stdio.h>
//La librería estándar stdio.h es necesaria para utilizar la función printf
int main(){

	printf("Hola Mundo!! \n"); //Imprime en pantalla el texto Hola Mundo
	return 0; /*la función main espera el retorno de un entero (int), por lo que retornamos 0 para cumplir */

} // todas las funciones en C se delimitan mediante { y }

Por ultimo abrimos Geany y vamos a la opción: Editar>Preferencias>Herramientas y en el campo Terminal colocamos lo siguiente:

x-terminal-emulator -e "/bin/sh %c"

De esta forma podremos compilar directamente desde nustro IDE, en otro caso podemos hacerlo desde la terminal, suponiendo que el codigo esta en el archivo ‘codigo.c’ en la terminal y utilizando gcc seria:

gcc -o codigo codigo.c

Esto genera un ejecutable llamado codigo, para ejecutarlo escribimos el comando:

./codigo

Hasta aquí el post, espero les sea útil, no duden en comentar su opiniones, dudas o sugerencias.