Todos los vídeos

GenServer (parte 3: control de errores y otros asuntos)

Un popurrí de trucos y consejos para usar los GenServers, así como una explicación sobre cómo señalizar correctamente los errores en un GenServer mediante el átomo :stop. Síganme para más recetas: https://hexdocs.pm/elixir/GenServer.html 00:00 ¿Pero cuál de todas estas funciones debo usar? 03:35 Devolviendo :stop o :ignore en el init 07:51 Timeouts en el servidor 11:37 Cuando las cosas no salen bien: devolviendo :stop 15:10 Devolviendo :noreply en el handle_call. 17:50 Se acabó GenServer

GenServers (parte 2: handle_call y handle_cast)

Siguiendo en el tour de los GenServer, las funciones más importantes de un GenServer son, sobre todo, handle_call; y también, handle_cast. Usaremos handle_call para gestionar llamadas síncronas por parte de los clientes que se conecten a nuestro servidor; y handle_cast para las llamadas asíncronas. 00:00 impl handle_call 06:05 GenServer.call 08:53 Timeouts 13:10 impl handle_cast 15:23 handle_info vs handle_cast 15:40 GenServer.cast 17:22 Envolviendo calls y casts

GenServer (parte 1)

El GenServer es una estructura de alto nivel construida por encima de la API de Procesos de Elixir para facilitar el uso de procesos en los cuales se envían mensajes y se gestionan estados. En este vídeo empezamos viendo init y handle_info, funciones útiles para empezar a trabajar con procesos. Además, de refilón: ¿os habéis fijado que con pid/1 puedo obtener un PID dado un string con sus tres números? ¿y que con r() puedo recompilar sobre la marcha mediante hot swap un módulo en IEx?

Procesos que se monitorizan

Vale, dejar caer un proceso cuando sus procesos conectados caen no es precisamente lo más robusto. Por eso, podemos pedirle a la OTP en su lugar que en vez de dejar caer un proceso, simplemente nos informe mediante otro paso de mensaje, cuando un proceso haya finalizado mal. Presentamos la monitorización, que con Process.monitor/1 o con spawn_monitor permite una forma más dulce de detectar cuando un proceso cae.

Procesos que fallan

Por defecto, en caso de que un proceso falle y se detenga, no nos vamos a enterar, porque OTP descarta esos errores silenciosamente. Sabemos que ha dejado de operar porque deja de estar alive pero poco más. Con un link (Process.link/1 y spawn_link) podemos conectar dos procesos que dependen entre sí para que el fallo de uno afecte al otro.

Procesos que recuerdan cosas

Algunas estrategias sobre cómo hacer procesos que pueden persistir un estado entre receive y receive.

Procesos que comunican

Con las primitivas send y receive podemos hacer que dos procesos se intercambien información. En Elixir, la forma estandar de compartir información entre procesos es mediante sistema de paso de mensajes, teniendo procesos aislados que se comunican mediante un sistema de mailboxes (bandejas de mensaje), formando un sistema de actores.

Concurrencia y OTP: creando procesos

Con la programación concurrente podemos tener de forma simultánea múltiples hilos de ejecución para evaluar en paralelo múltiples expresiones. Con la primitiva spawn podemos pedirle a la plataforma OTP que nos lance un nuevo proceso para evaluar por separado una expresión.

Sobre las macros, require y use

Use es una palabra clave empleada para invocar una macro declarada en otro módulo con el objetivo de importar código en nuestro módulo. Como si fuese un copia y pega, se traerá definiciones que haya en ese módulo. Require sirve para importar macros específicas. Esto requiere que presente por encima la metaprogramación, aunque no es el día de hablar de ella.

Alias e import

Después de escribir este código, vamos a usarlo como base para tratar algunas herramientas útiles que nos ofrece Elixir para controlar el código de nuestros módulos. Alias sirve para darle otro nombre a un módulo y hacerlo más fácil de escribir. Import sirve para traer definiciones de otros módulos y así no tener que poner su prefijo delante.

Por duración
Por tema