echo -e '*1\r\n$4\r\nPING\r\n' | nc redis.host.com 6379
nc -vv -w 1 redis.host.com 6379
| # Schemas ----- | |
| module Calculator | |
| module Infrastructure | |
| module Schemas | |
| class CalculationPayrollSchema | |
| CALCULATE_PAYROLL_SCHEMA = { | |
| "type" => "object", | |
| "required" => %w[payroll_group_id start_date end_date], | |
| "properties" => { |
| FROM: https://github.com/kubernetes/minikube/issues/4589#issuecomment-614631444 | |
| minikube ssh | |
| sudo vi /etc/systemd/network/10-eth1.network add DNS=8.8.8.8 under [Network] | |
| sudo vi /etc/systemd/network/20-dhcp.network add DNS=8.8.8.8 under [Network] | |
| sudo systemctl restart systemd-networkd |
Hace poco me llego un requerimiento donde me pedían listar una serie de opciones filtradas de un menú, nada complicado, lo interesante del asunto es que ese comportamiento de filtrar la misma data ya existía en un servicio distinto al que estaba trabajando. Así que lo único que debía hacer era reutilizarlo, y para lograrlo, la forma más sencilla posible era creando un proxy.
Un proxy es un patrón de diseño estructural que tiene como propósito ser el intermediario de un recurso para controlar el acceso.
Existen varios tipos de proxy, pero para nuestro caso desarrollaremos el tipo remoto, proxy remoto, que básicamente nos ayuda a tener presencia de un objeto de una clase definida en otro sistema, en nuestro propio sistema.
Muerta la teoría (o al menos parte de ella), manos a la obra.