DEV Community: JavaScript Chile

Separación de Responsabilidades de los Dispositivos

Camilo — Sat, 24 Jan 2026 17:49:45 +0000

La verdad yo creo que mi vida era mucho más ordenada y simple cuando mi celular solo podía conectarse a internet a páginas WAP usando Symbian en un Nokia por allá en el 2007 y solo lo utilizaba para descargar ringtones midi.

Creo que más de 10 años usando iPhone y otros "smartphones" ha mermado mi capacidad de concentración y restado a mi calidad de vida en general. Ha llegado el momento de replantear la relación que yo tengo con la tecnología, sobre todo la que es muy enganchante como las redes sociales.

Siendo un Ingeniero en Software es necesario evaluar estos temas por que la tecnología informática siempre ha sido de mi predilección frente a otras áreas del conocimiento humano. Una vez que se masificaron los smartphones y las redes sociales, poco a poco el tiempo que dedicaba a leer libros, hacer artesanías u simplemente disfrutar el día se ha disminuido notablemente, sobre todo durante y luego de la pandemia. Dedicando un tiempo poco saludable a mirar una pantalla pequeña. Las redes sociales y las constantes notificaciones se han vuelto un sifón de atención y energía que debo controlar.

¿Es ser un Ludista?

No creo que la solución sea eliminar la tecnología actual de nuestras vidas. No abogo ser un seguidor de Ned Ludd. Pero pienso que las tecnologías actuales sin un orden y control adecuado se han convertido en herramientas de servidumbre del humano hacia la máquina y no como era antes donde la máquina servía al humano.

Tecnología Kosher/Halal

Los miembros de la religión Judía utilizan el término "Kosher" para significar que algo "esta bien" y "aprobado" para que un judío utilice un alimento u otro elemento por que está dentro de lo permitido en su religión. Los miembros de la religión Musulmana utilizan el término "Halal" para el mismo fin.

Dentro de ésta tecnología "Kosher" existen los celulares que no permiten acceso a internet o reproductores de mp3 sin acceso a la radio FM, entre otras restricciones. La idea es evitar acceder a contenido que pudiera ser perjudicial para alguien que siga las normas de la religión.

¿Qué opciones hay?

Como Ingeniero en Software es vital estar actualizado en el avance tecnológico y estar capacitado en las tecnologías del estado del arte en la industria que uno desee participar. Pero eso no significa estar conectado 24/7 a la marea de información disponible cada segundo.

Por lo tanto creo que es pertinente poner algunas reglas que permitan dar orden a todo el caos generado por los "smartphones" y redes sociales.

Espacio Dedicado

En la época de los cibercafes pre 2010. La mayoría de las personas tenían un lugar dedicado en la casa para uso del computador. Por que eran comunes las pantallas CRT grandes y equipos pesados. Los notebook si bien existían, tenían precios elevados que no todas las familias podían permitir alcanzar.

Hoy es más probable tener un notebook que un computador de escritorio, ya que los computadores de escritorio se asocian más con streaming, videojuegos y situaciones de alta exigencia de recursos por que hay mayor flexibilidad de cambiar componentes.

Los notebook son más asociados a contextos de trabajo general y navegación de internet, por lo menos las opciones económicas.

Considero que se debe rescatar esa tradición de tener un lugar dedicado para la computación por que permitía ordenar los espacios y tener un mise en place de la computación.

https://es.wikipedia.org/wiki/Mise_en_place#/media/Archivo:Mise_en_place_for_hot_station.jpg

Tener un Celular Simple

Un celular simple se puede encontrar como "Senior Phones" o "Nonnophone". Hoy todavía se pueden encontrar teléfonos con Symbian o similar que son compatibles. La red 2G ya no es funcional en Chile, por lo que muchos celulares del 2010 o anterior ya no sirven. Pero se pueden encontrar algunos reemplazos bastante buenos.

Por ejemplo el Teléfono Móvil Senior 3g Nonnophone 3.0 Green-e.
Este celular no tiene acceso a internet, pero si tiene un cargador moderno, bluetooth, radio FM y posibilidad de sacar fotos a la vieja escuela con una cámara 2GP y guardarlas en una tarjeta sd.

La verdad pienso de que es sumamente útil por que no tiene notificaciones constantes. Los únicos mensajes que llegarán serán por SMS y las llamadas serán de personas que conozcan nuestro número (omitiendo el SPAM de algunas empresas o estafadores). Además no puedes tener instagram, whatsapp, facebook, email, slack, x (ex twitter) o teams instalado.

Herramientas de Trabajo

¿No más smartphone?. En mi experiencia es mejor tener ambos tanto un celular simple como uno smart, algunas de las apps necesitan ser usadas y solo funcionan en un celular smartphone como Instagram o a veces piden las empresas usar aplicaciones de OTP para hacer login a la VPN. Por lo que es necesario tener un smartphone para el mundo laboral actual. Sin embargo creo que es necesario ver el smartphone como una herramienta de trabajo más que como una herramienta de "uso en todos los contextos".

Si no puedo tener esas apps en mi celular ¿Donde las uso?. Pues las herramientas de comunicación como slack, email y amigos son esenciales para cualquier trabajo, pero no deberían ser tan esenciales como para estar conectadas a ella todo el día e incluso en nuestros momentos privados en el baño.

La estrategia es tener un smartphone para las apps obligatorias del trabajo y comunicaciones como Whatsapp. Pero no usarlo ni tenerlo cerca si no es necesario, quizás guardarlo en un cajón y no tenerlo a la vista.

Cambiar el chip para llamadas telefónicas y sms al teléfono simple. De esta forma el smartphone solo se convierte en un puente a la tecnología moderna y conservamos la comunicación esencial en un teléfono simple.

Muchas de las aplicaciones de trabajo funcionan perfectamente en un computador tradicional y se puede hacer todas las tareas que tiene un smartphone, en su gran mayoría.

Por lo que esta estrategia también en más barata a largo plazo, no se necesita un smartphone nuevo cada año y no se necesita usarlo mucho por lo que su tiempo de vida es mayor.

Conclusiones

Creo que es saludable volver a un mundo donde tenemos control de la tecnología y no al revés. Usemos un celular simple para llamar y enviar sms, usemos una cámara de fotos para sacar fotos y un reproductor de música sin internet para escuchar canciones que no puedan ser borradas de un servidor.

El smartphone debe ser catalogado como una herramienta de trabajo, más no convertirse en una aspiradora de nuestro tiempo y energía. Si simplemente lo usamos para las tareas esenciales y obligatorias. Dejando al computador como la herramienta principal de acceso a internet, trabajo y comunicación.

Rescatemos lo mejor de la década del 2000 y aprendamos las buenas prácticas y separación de responsabilidades de cada dispositivo para que no se vuelvan nuestros gobernantes.

Portada: https://commons.wikimedia.org/wiki/File:Telmac_1800.JPG

Programación Orientada a Objetos - Una abstracción de la realidad

Jose Germán Martínez — Thu, 08 Aug 2024 01:29:14 +0000

Hola, en este artículo, que parece tutorial, abordaremos un tema que en lo particular al principio me dio muchos dolores de cabeza. Sin embargo, esta dificultad me llevó a estudiar, estudiar y estudiar para hacer como propia la abstracción de la vida cotidiana y así llevar a líneas de código, la representación de algo tangible (créeme que esto puede llegar a ser una tarea titánica a veces). El tema terminó apasionándome de manera tal que ahora comparto en este artículo datos importantes para comprenderlo, así que vamos al hueso del asunto.

Explicaré o intentaré hacerlo de la mejor manera posible, programación orientada a objetos o por sus siglas (POO) utilizando JavaScript como mi lenguaje de elección. Para entender cómo aplicar la POO a situaciones del mundo real, tienes que internalizar que la programación orientada a objetos no es solo una técnica, ¡es un enfoque de vida! En este artículo, exploraremos conceptos fundamentales de POO y los aplicaremos a ejemplos tangibles de la vida cotidiana.

¿Qué es la Programación Orientada a Objetos?

La programación orientada a objetos es un paradigma de programación que se basa en el concepto de "objetos", puedes imaginarte en este mismo instante literalmente un objeto de la vida: una manzana, un perro, una casa, un auto, un papito de hule. Ahora, visualiza que estos objetos pueden contener datos en forma de propiedades o características y funcionalidades, es decir, pueden hacer cosas. Imagina que estás modelando un mundo virtual donde cada entidad puede ser representada como un objeto independiente con características únicas.

Objetos en la Vida Real y en la POO

Para entender mejor la POO, echemos un vistazo a un ejemplo de la vida real: un auto. Un auto puede tener propiedades como modelo, color y velocidad, así como métodos como arrancar y detener. Transpolar esto al mundo de la POO sería bastante sencillo:

class Auto {
  constructor(modelo, color) {
    this.modelo = modelo;
    this.color = color;
    this.velocidad = 0;
  }

  arrancar() {
    console.log(`El auto ${this.modelo} ha arrancado.`);
  }

  detener() {
    console.log(`El auto ${this.modelo} se ha detenido.`);
    this.velocidad = 0;
  }

  acelerar(kmh) {
    this.velocidad += kmh;
    console.log(`El auto ${this.modelo} acelera a ${this.velocidad} km/h.`);
  }
}

// Crear un objeto auto
const miAuto = new Auto('Sedán', 'Rojo');

// Utilizar métodos del objeto auto
miAuto.arrancar();
miAuto.acelerar(50);
miAuto.detener();

En este ejemplo, hemos creado una clase Auto con propiedades como modelo, color y velocidad, así como métodos, es decir, las cosas que puede hacer: como arrancar, detener y acelerar. Luego, creamos un objeto miAuto basado en esta clase y lo utilizamos para simular acciones de la vida real.

Herencia: La Clave de la Jerarquía

Imagina ahora que queremos modelar no solo coches, sino también motocicletas. Ambos comparten algunas similitudes, pero también tienen características únicas. Aquí es donde entra en juego el concepto de herencia en la POO.

class Camioneta extends Auto {
  constructor(modelo, color, tipo) {
    super(modelo, color);
    this.tipo = tipo;
  }

  realizarTruco() {
    console.log(`La camioneta ${this.modelo} ${this.tipo} realiza un asombroso truco.`);
  }
}

// Crear un objeto camioneta
const miCamioneta = new Camioneta('Explorer', 'Negra', '4x4');

// Utilizar métodos del objeto camioneta
miCamioneta.arrancar();
miCamioneta.acelerar(80);
miCamioneta.realizarTruco();
miCamioneta.detener();

Aquí, hemos creado una nueva clase Camioneta que extiende la clase Auto. La palabra clave extends nos permite heredar todas las propiedades y métodos de la clase padre (Auto). Además, la clase hija (Camioneta) puede tener propiedades y métodos adicionales.

Encapsulamiento: Protegiendo tus Secretos

El encapsulamiento es otro pilar de la POO que nos permite proteger los detalles internos de un objeto y exponer solo lo necesario. Veamos un ejemplo sencillo utilizando una "Cuenta Bancaria":


class CuentaBancaria {
  constructor(titular, saldoInicial) {
    this.titular = titular;
    this._saldo = saldoInicial; // El saldo se designa con el prefijo _ para indicar que es privado
  }

  get saldo() {
    return this._saldo;
  }

  depositar(cantidad) {
    if (cantidad > 0) {
      this._saldo += cantidad;
      console.log(`${cantidad} depositados. Nuevo saldo: ${this._saldo}`);
    } else {
      console.log("Error: La cantidad debe ser mayor que cero.");
    }
  }

  retirar(cantidad) {
    if (cantidad > 0 && cantidad <= this._saldo) {
      this._saldo -= cantidad;
      console.log(`${cantidad} retirados. Nuevo saldo: ${this._saldo}`);
    } else {
      console.log("Error: Cantidad inválida o saldo insuficiente.");
    }
  }
}

// Crear una cuenta bancaria
const miCuenta = new CuentaBancaria('Juan Pérez', 1000);

// Utilizar métodos del objeto cuenta bancaria
console.log(`Saldo inicial: ${miCuenta.saldo}`);
miCuenta.depositar(500);
miCuenta.retirar(200);

En este ejemplo, hemos encapsulado el saldo de la cuenta utilizando un método get para acceder a él. Esto protege el saldo de ser modificado directamente desde fuera de la clase, manteniendo la integridad de nuestra cuenta bancaria.

Polimorfismo: La Magia de la Versatilidad

El polimorfismo permite que diferentes clases compartan el mismo nombre de método, pero con comportamientos específicos para cada una. Para ilustrar esto, imaginemos un zoológico con animales que emiten sonidos.


class Animal {
  hacerSonido() {
    console.log('Algunos sonidos genéricos de animal.');
  }
}

class Perro extends Animal {
  hacerSonido() {
    console.log('¡Guau! ¡Guau!');
  }
}

class Gato extends Animal {
  hacerSonido() {
    console.log('¡Miau! ¡Miau!');
  }
}

// Crear objetos animales
const miAnimal = new Animal();
const miPerro = new Perro();
const miGato = new Gato();

// Utilizar el método hacerSonido de cada objeto
miAnimal.hacerSonido();
miPerro.hacerSonido();
miGato.hacerSonido();

En este ejemplo, las clases Perro y Gato heredan de la clase Animal, pero cada una sobrescribe el método hacerSonido con su propia implementación única. Esto permite que diferentes tipos de animales utilicen el mismo método de manera distinta.

Conclusión: POO... ponlo en Acción

¡Te agradezco mucho llegar este punto! Exploramos conceptos clave como objetos, herencia, encapsulamiento y polimorfismo, y los hemos aplicado a situaciones de la vida real. Recuerda, la POO es una forma de pensar que te permite modelar y entender el mundo de manera más efectiva...y llevarla a código.

Así que la próxima vez que veas un auto, una cuenta bancaria o incluso a tu mascota, piensa en cómo podrías representarlos como objetos en tu código. La programación orientada a objetos no solo es una herramienta poderosa, ¡es una forma de dar vida a tus programas!

Espero que hayas disfrutado este artículo y que le puedas sacar provecho en tus proyectos. Déjeme tus comentarios para saber que te pareció y si tienes alguna otra abstracción de la vida real. ;)

¿Trabajo Remoto o Híbrido?

Camilo — Wed, 03 Jul 2024 16:42:00 +0000

Este es un pequeño artículo sobre reflexiones sobre los llamados trabajos "Híbridos" y la necesidad de establecer una definición adecuada para no confundir.

Trabajo Presencial

Primero tendremos el trabajo presencial, el cual estás obligado a ir a una oficina o lugar específico para ejercer tus labores. En la pandemia del 2020 vimos un cambio hacia lo remoto. Los primeros años de la década del 2020 demostraron que si se puede trabajar remotamente para gran parte de las labores tech.

Trabajo Híbrido

Luego de la pandemia comenzaron a surgir los llamados trabajos "híbridos". Hay una clara mal interpretación de lo que es trabajo Híbrido. Se puede asumir de que "Algunos días remoto y algunos días presencial", pero esto causa confusión.

La definición que propongo híbrido es lo siguiente:

Se trabaja en un horario y zona horaria específica.
Se tiene a disposición una oficina pero es opcional asistir.
Es obligación estar dentro de un territorio (Por ejemplo dentro de Chile, por temas legales, tributarios y otros).

En términos simples, si te obligan a ir presencial entonces es un trabajo presencial y no híbrido.

Trabajo Remoto

El trabajo remoto es similar al híbrido con la salvedad de que puede ser en cualquier parte del mundo o zona horaria, no tienes la obligación de estar en el mismo país donde esta el trabajo.

Es más pensado para ofertas laborales en el extranjero donde tu debas pagar tus propias cotizaciones, previsión de salud y pagar los costes de transferencias.

¿Por qué es importante?

Muchas personas dicen que les gusta ir a la oficina por diversos motivos. Se confunde muchas veces trabajar remotamente con trabajar desde casa. Lo cual es erróneo. Trabajar remoto simplemente significa que tienes la libertad de trabajar donde sea más cómodo. Puede incluso ser una oficina, pero la clave es la libertad de elección donde se trabaja. Es por esto que muchos defienden el ir presencial a una oficina y privilegian por sobre la opción remota. El drama es que no debería ser obligatorio ir a la oficina en un trabajo híbrido, es opcional y no habría problemas si deseas trabajar fuera de ella todo el tiempo. La oficina se transforma en un espacio de cowork opcional más que un lugar de sometimiento y esclavitud a horarios y expectativas de calentar sillas.

Piensa todas las horas de vida que pierdes solo por ir a un lugar obligado, costos en salud mental, costos de alimentación y transporte. Costos que asumes personalmente y no la empresa.

Que tu relación laboral sea de mutuo beneficio y no unilateral para la empresa.

Como profesionales de la tecnología está en nuestro poder exigir este beneficio a las empresas. Si nos sometemos el ir presencial obligadamente, afectaremos tanto a nuestra salud mental como a los seres queridos que tenemos y principalmente afectamos a la industria en general haciendo más fome las condiciones laborales para todos los miembros del oficio.

Conclusión

Prioriza tu vida y tu salud mental y financiera, prefiere siempre trabajos donde sea opcional ir presencial.

Imagen: https://commons.wikimedia.org/wiki/File:Remote_work_Telelavoro_1.jpg

Super Club Net: Libro de Introducción a HTML, CSS y JS

Camilo — Tue, 25 Jun 2024 16:12:00 +0000

Con motivo de dar honor a la revista Club Nintendo y su mini curso de HTML.

La revista Club Nintendo y su curso de HTML

Camilo for JavaScript Chile ・ Jun 8 '24

#html #clubnintendo #principiante #chile

He elaborado este pequeño libro actualizando y ampliando los conceptos vistos en esa revista.

Un libro gratuito que puede ser leído en los siguientes sitios web:

Contenidos

HTML y CSS básico.
JavaScript básico.
Manipulación de DOM.
Formularios y validación.
Tips y recomendaciones.

Una escritura amena y con ejemplos basados en juegos de Nintendo 64. Incluye un proyecto para ejercitar con temática de Mario Kart 64.

Pensado para personas que recién inician en el mundo HTML y quizás para alguien que quiera refrescar conceptos.

Hecho con mucho amor por Ninjas.cl para todo aquel con curiosidad y paciencia de aprender HTML, CSS y JS para desarrollo web :)

Desafío de Nombres y Apellidos

Camilo — Tue, 11 Jun 2024 19:29:00 +0000

El siguiente es un pequeño ejercicio encontrado en el curso de Haskell
disponible en la Universidad de Helsinki.

Desafío

Dado una lista de nombres y apellidos:

Nombres: ["Eva", "Mike"]
Apellidos: ["Smith", "Wood", "Odd"]

Retornar una lista cuyos elementos sean solo de personas con largo par.

Ejemplo de Retorno

["EvaSmith", "EvaOdd", "MikeWood"]

Solución en Haskell

Haskell permite pattern matching y list comprehensions.

[whole | first <- ["Eva", "Mike"],
         last <- ["Smith", "Wood", "Odd"],
         let whole = first ++ last,
         even (length whole)]

Solución en Elixir

Si bien la solución en Elixir no es tan corta como en Haskell
es igual de elegante.

require Integer

for first <- ~w[Eva Mike],
  last <- ~w[Smith Wood Odd],
  name <- [first <> last],
  name
  |> String.length()
  |> Integer.is_even(), do: name

Para esto utilizamos las características de for comprehensions.

https://elixirschool.com/en/lessons/basics/comprehensions

Solución en Javascript

David de Javascript Chile nos escribe una solución en versión
imperativa y declarativa utilizando Javascript.

Imperativa

const nombres = ["Eva", "Mike"];
const apellidos = ["Smith", "Wood", "Odd"];

const output = [];

for(let i = 0; i < nombres.length; i++){
    for(let j = 0; j < apellidos.length; j++){
        const fullName = `${nombres[i]}${apellidos[j]}`;
        if(fullName.length % 2 == 0){
            output.push(fullName);
        }
    }
}

Declarativa

const nombres = ["Eva", "Mike"];
const apellidos = ["Smith", "Wood", "Odd"];

const output = nombres.flatMap(n =>
        apellidos.map(a => `${n}${a}`)
    )
    .filter(fullName => fullName.length % 2 == 0);

Elixir

La versión declarativa de Javascript la podríamos emular en Elixir de la siguiente
forma:

~w[Eva Mike]
|> Enum.flat_map(fn first ->
  ~w[Smith Wood Odd]
  |> Enum.map(fn last ->
    first <> last
  end)
end)
|> Enum.filter(&
    &1
    |> String.length()
    |> Integer.is_even()
)

Aunque no es tan elegante como usar for comprehensions.

¿En qué otros lenguajes puedes solucionar el desafío?

La revista Club Nintendo y su curso de HTML

Camilo — Sat, 08 Jun 2024 17:47:00 +0000

Quiero compartir el curso que inicio mi interés por la informática.
El curso de HTML de la revista Club Nintendo. Encontré los escaneos de la versión
mexicana, aunque yo leí la edición chilena. El contenido es el mismo.

Primera Parte

https://archive.org/embed/club-nintendo-ano-06-no-05-mexico

Página 44. Introducción al HTML.
Etiquetas básicas como <h1>, <img> y los colores hexadecimales. Tablas y listas.

Conceptos

Segunda Parte

https://archive.org/embed/club-nintendo-ano-06-no-10-mexico

Página 44. Mapas de imagenes. Frames, enlaces.

Conceptos

Tercera Parte (final)

https://archive.org/embed/club-nintendo-ano-06-no-11-mexico

Página 52. Formularios y un poquito de Javascript.

Conceptos

Experiencia personal

Personalmente yo tenía 8 años y estaba en segundo básico (Mayo de 1997), no hace mucho había aprendido a leer y escribir. Mi padre trajo a la casa un viejo computador con Windows 3.1 que habían dado de baja en su trabajo y me sirvió para practicar las cosas de la revista, aunque principalmente lo usaba para jugar juegos de DOS
y aprender a escribir con el teclado, con eso también aprendí los comandos básicos de terminal como crear carpetas, copiar y borrar archivos y esas cosas del DOS.

Mi padre era más de Excel y Word, así que tuve que aprender todas esas cosas viendo y experimentando por mi cuenta.

Aunque no tuvimos internet en la casa como hasta el 2004, pude ir a su trabajo y descargar cosas y más tutoriales.

Luego de eso también me trajo un libro fotocopiado de Visual Basic 6, donde también aprendí armar programas de escritorio, aunque super básicos.

Terminaré este pequeño post con las mismas palabras del curso de HTML de la revista Club Nintendo:

Ojalá que estos 3 cursos de HTML. te sirvan y que despierten tu interés por aprender más. Si es así, existen libros muy buenos de programación de otros lenguajes para usarse en Internet.

Historia de la BeamVM

Camilo — Thu, 06 Jun 2024 16:00:00 +0000

¿Qué es Erlang?

Erlang es un lenguaje de programación funcional. Esto quiere decir que se basa en los principios de funciones con transparencia referencial e inmutabilidad. La transparencia referencial quiere decir que una función con los mismos parámetros debería retornar el mismo resultado. La inmutabilidad quiere decir que no puedo alterar el valor de una variable una vez que se ha asignado, por ejemplo si digo que x es 5, no es lógico que también sea 6 (sería deshonesto). Sin embargo existen casos donde una función puede retornar otro resultado con los mismos parámetros (por ejemplo una función de la fecha actual). Erlang usa un enfoque pragmático: Obedecer los principios de la programación funcional (inmutabilidad, transparencia referencial) y romperlos cuando aparecen conflictos del mundo real.

Además del lenguaje de programación, Erlang tiene todo un ecosistema de herramientas. En primer lugar se encuentra su máquina virtual (BEAM VM), la cual ejecuta código compilado con un bytecode específico, muy similar a la JVM de Java. Por lo que el código puede ser ejecutado en cualquier sistema para la cual la BEAM VM sea compatible. También proporciona herramientas de desarrollo como compiladores, debuggers, herramientas para análisis de rendimiento y pruebas. El framework OTP, servidores web, generadores de analizadores de código fuente (parsers), una base de datos distribuida llamada mnesia, entre otras herramientas. La máquina virtual y sus bibliotecas permiten actualizar el código en caliente (hot reload), lo que significa cambiar el código durante la ejecución del programa sin interrupción del servicio y también permitir la ejecución del código de forma distribuida en varias computadoras, manejando los errores y fallos de una forma simple y poderosa.

Todas estas características permiten una habilidad de Erlang para la resiliencia frente a errores y organización del código en procesos y mensajes concurrentes.

Origen de Erlang

Erlang comenzó como una biblioteca de Prolog, luego como un dialecto de Prolog, para finalmente ser un lenguaje de programación por si mismo. El objetivo fue resolver el problema de construir sistemas distribuidos robustos y confiables. Desarrollado originalmente en la empresa de telecomunicaciones Ericsson para sus switch telefónicos. Desde un inicio se enfrentaron a desafíos de escala mundial como cientos de milllones de usuarios y condiciones de servicio muy estrictas. Fue liberado al público en 1998 como un proyecto Open Source. Hoy en día, según Cisco, el 90% del tráfico de internet es orquestado por nodos programados en Erlang.

// Detect dark theme var iframe = document.getElementById('tweet-1002494428748140544-407'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1002494428748140544&theme=dark" }

Erlang y la BEAM VM han evolucionado a lo largo de más de 30 años para otros casos de uso como la robótica, machine learning, aplicaciones web, entre otros. Uno de sus creadores principales Joe Armstrong lo detalla de la siguiente forma:

Erlang fue diseñado para escribir programas concurrentes que se ejecutasen eternamente. Erlang usa procesos concurrentes para estructurar el programa. Estos procesos no tienen memoria compartida y se comunican por paso de mensajes asíncronos. Los procesos de Erlang son ligeros y pertenecen al lenguaje, no al sistema operativo. Erlang tiene mecanismos que permiten que los programas cambien on-the-fly (en vivo) así, esos programas pueden evolucionar y cambiar sin detener su ejecución. Estos mecanismos simplifican la construcción de software implementando sistemas non-stop (que no se detienen).

El desarrollo inicial de Erlang tuvo lugar en 1986 en el Laboratorio de Computación de Ericsson. Erlang fue diseñado con un objetivo específico en mente: proporcionar una mejor forma de programar aplicaciones de telefonía. En ese momento, las aplicaciones de telefonía eran atípicas del tipo de problemas que podían resolver los lenguajes de programación convencionales. Las aplicaciones de telefonía son, por su naturaleza, altamente concurrentes: un simple switch debe manejar decenas o cientos de miles de transacciones simultáneas. Tales transacciones son intrínsecamente distribuidas y el software se espera que sea altamente tolerante a fallos. Cuando el software que controla los teléfonos falla, sale en los periódicos, algo que no ocurre cuando fallan las aplicaciones de escritorio. El software de telefonía debe también cambiar on-the-fly, esto es, sin perder el servicio mientras se realiza una actualización del código. El software de telefonía debe también operar en tiempo real, con ajustados requisitos de tiempo para algunas operaciones, y más relajado tiempo en otras clases de operaciones.

¿Por qué Erlang es Bueno?

Joe Armstrong, fijó los requisitos de Erlang en solucionar los problemas de un entorno altamente concurrente, que no puede permitirse caer y que debe de actualizarse sin pérdida de servicio. Actualmente, esta definición calza con casi la mayor parte de servicios en Internet.

Sin embargo pensar de que Erlang solamente es para casos de uso de procesos y mensajes livianos y concurrentes es insuficiente para describirlo. En su tésis de doctorado Joe Armstrong detalla componentes genéricos llamados "behaviours" (comportamientos) en Erlang. Estos "behaviours" son similares a las interfaces en otros lenguajes de programación y permiten el polimorfismo, es decir, que los programas puedan trabajar con múltiples formas.

Joe Armstrong detalló seis distintos behaviours gen_server, gen_event, gen_fsm (gen_statem), supervisor, application y release. Definió que estos seis behaviours eran suficientes para crear sistemas distribuidos confiables y robustos.

Los behaviours son escritos por expertos y están basados en años de experiencia y representan las "mejores prácticas". Permiten que los programadores de la aplicación se enfoquen en la "lógica de negocios", mientras que la infraestructura es proporcionada automáticamente por el behaviour. El código es escrito de forma secuencial y toda la concurrencia es realizada por el behaviour "por debajo". Esto facilita que nuevos miembros del equipo aprendan la lógica de negocios, ya que es secuencial y es similar a cómo operan otros lenguajes de programación.

La siguiente lista es una breve descripción de cada behaviour.

gen_server: Un servidor genérico. Permite crear un servicio que puede recibir llamadas.
gen_event: Un gestor de eventos. Permite enviar mensajes cuando ocurren eventos definidos.
gen_statem: Una máquina de estados, anteriormente conocida como gen_fsm. Permite validar estados de los datos.
supervisor: Un supervisor es un proceso cuya tarea es que otros procesos (hijos) esten vivos y realizando su labor. Con múltiples estrategias para reiniciarlos si estos fallan. Un supervisor puede ser padre de otros supervisores.
application: Una aplicación es un conjunto de componentes gen_server, gen_event, gen_statem y supervisor utilizados para un fin. Se le llama "árbol de supervisión" (supervision tree).
release: Un sistema puede contener una o múltiples application, lo que se considera un release. Además proporciona herramientas para actualizar el código y volver a un estado anterior (rollback) si la actualización falla.

Si se tiene en cuenta que un supervisor puede supervisar a otros supervisores (los cuales pueden estar ejecutándose en otro computador), nos da una idea de lo poderoso que pueden ser los behaviour. Se podría hacer un paralelo con Kubernetes, pero la principal diferencia es que estos behaviours son ejecutados a nivel del proceso/hilo a diferencia de Kubernetes que se ejecuta a nivel del contenedor Docker.

Las ideas de los supervisores y las estrategias de reinicio vienen de la observación de que usualmente es más simple reiniciar un servicio para solucionar un problema. ¿Has probado apagar y prender un equipo para solucionar un problema?. Esto se puede explicar con un ejemplo: Si estoy siguiendo la ruta de un mapa y me pierdo, es más simple partir del punto inicial que desde donde me perdí para llegar a la meta, es decir, en vez de encontrar el error y repararlo sobre la marcha, es más rápido y correcto registrar el error y volver al inicio para intentarlo de nuevo.

Saber que los procesos pueden fallar y serán reiniciados por un supervisor nos permite fallar temprano y rápido (Siguiendo las recomendaciones de Jim Gray). Un proceso produce un resultado correcto según la especificación o envía una señal de fallo y se detiene su operación. "Let it crash!" (Déjalo caer) es una frase acuñada por Joe Armstrong para denominar este comportamiento de "camino feliz", donde si ocurre algo fuera del "camino feliz", el proceso debe detenerse y no tratar de solucionar el problema sobre la marcha (potencialmente empeorando la situación), dejando que otro componente dentro del árbol de supervisión maneje el error.

Los supervisores y la filosofía de "Let it Crash!" de Erlang le permiten producir sistemas robustos y confiables. Se puede ejemplificar con la máquina Ericsson AXD301, la cual alcanzó nueve nueves (99.9999999%) de fiabilidad en sus sistemas. Para poner en perspectiva la fiabilidad de cinco nueves (99.999%) se considera bueno (5.26 minutos de servicio caido por año). En grandes compañias se estima que existe 1.6 horas de servicio caido por semana. Nueve nueves de fiabilidad es como un parpadeo al año de servicio caido (31.56 milisegundos al año). Si bien los nueve nueves fueron alcanzados en una situación específica y no hay claridad total de cómo se obtuvieron dichos datos, se puede afirmar que la tecnología de Erlang da una fiabilidad y robustes muy grande.

El modelo de Actores

Se ha definido Erlang y su ecosistema, pero para tener una noción más íntegra se debe explicar lo que es concurrencia. En muchos lugares se puede considerar concurrencia y paralelismo como el mismo concepto. En Erlang son dos ideas separadas. La concurrencia se refiere a la idea de actores ejecutandose de forma independiente, pero no necesariamente al mismo tiempo. El paralelismo es tener actores independientes ejecutandose al mismo tiempo. Si lo vemos a nivel de procesador, concurrencia es que cada proceso tiene su tiempo de ejecución en un único procesador, similar a como funcionaban los sistemas antes de la existencia de múltiples núcleos en los procesadores. El paralelismo ha estado disponible desde el inicio de Erlang, simplemente era necesario un computador anexo y conectado al computador principal. En la actualidad los procesadores con múltiples núcleos permiten paralelismo en un único computador (en contextos industriales llegando a docenas de núcleos por procesador) y Erlang permite aprovechar estas características completamente (desde aproximadamente el año 2009 con la implementación del multiprocesamiento simétrico).

Para lograr la concurrencia Erlang utiliza el modelo de actores. Cada actor es un proceso separado (función) y aislado en la máquina virtual y se comunican utilizando mensajes. Cada proceso (actor) es totalmente independiente y no comparte ninguna información con otros procesos, solamente utilizan mensajes entre ellos para comunicar datos. Son livianos (no son procesos del sistema operativo). Toda la comunicación es explícita, segura y con alta trazabilidad. Si un proceso falla, no afectará a los otros procesos, ya que son totalmente independientes entre si.

Una cosa importante a considerar en relación a las habilidades de escalamiento de Erlang y sus procesos ligeros. Es cierto que pueden tener cientos de miles de procesos existentes al mismo tiempo, pero no significa abusar de ellos. Por ejemplo crear un videojuego de disparos en los que cada bala sea su propio actor es algo excesivo. Ya que hay un pequeño costo en enviar mensajes entre actores, si se dividen las tareas demasiado puede incluso perjudicar el rendimiento.

Se puede pensar de que la programación paralela es directamente proporcional a la cantidad de núcleos de un procesador, lo que se conoce como escalamiento lineal. Pero es importante recordar de que no existe algo perfecto y libre de costos asociados. El paralelismo no es la respuesta a cada problema, en algunos casos incluso puede afectar la velocidad de la aplicación, por ejemplo cuando existen tareas redundantes o el código es 100% secuencial pero intenta utilizar procesos paralelos. Un programa en paralelo va tan rápido como su parte secuencial más lenta. Esto significa que usar paralelismo para todos los problemas no garantiza que sea más rápido. Simplemente es una herramienta que puede ser muy útil, pero no siempre es la adecuada.

Conclusión

Quizás se ha encontrado con una situación similar a la siguiente: Mi sistema es local y no necesito de las capacidades de concurrencia que Erlang proporciona. Jamás llegaré a los niveles de exigencia en mis sistemas que justifiquen utilizar dichas capacidades.

Se podría pensar de que al tener sistemas de nicho nunca tendremos la necesidad de usar las bondades de la BEAM VM. ¿Pero qué pasa si tenemos una cantidad de datos enorme que debe ser procesada?.

Esto sucedió en una empresa donde debían migrar una base de datos de usuarios a un nuevo sistema. Se debían procesar las tablas y ajustarlas al formato del nuevo sistema, es decir, se debía crear un pequeño script ETL (Extract Transform Load) para extraer, transformar y cargar datos. En un inicio un programador que solamente conocía Python intentó realizar la migración, pero debido a la cantidad de datos la operación tomaba más de una semana en completar. Luego la tarea pasó a un equipo que conocía Elixir y la operación tardó menos de un día en ser completada, gracias a las bondades de concurrencia y paralelismo de la Beam VM.
Se puede argumentar de que tal ves era inexperiencia en Python o no se usaron las herramientas adecuadas en dicho lenguaje. Pero eso nos habla de que realizar concurrencia y paralelismo en otros lenguajes no es tan simple como en el ecosistema de Erlang.

Si bien todas estas herramientas e ideas podrían ser implementadas y desarrolladas en otros lenguajes de programación y ecosistemas (y viceversa). No es una tarea sencilla y tampoco se contaría con más de 30 años de evolución funcionando en sistemas productivos de clase mundial. Por lo que la máquina virtual de Erlang (BEAM VM) es una tecnología robusta, confiable y acertada para ser usada en las soluciones de software actuales. Se debe evaluar cada problema y seleccionar las herramientas adecuadas según su contexto.

Referencias

Entendiendo la Mutabilidad y la Re-asignación

Gonzalo Fernández — Sun, 02 Jun 2024 22:18:04 +0000

Buenas, hoy quisiera hablar sobre un tema que puede ser confuso al iniciar en programación, especialmente en lenguajes como Javascript donde la diferencia es tan clara: La Mutabilidad y la Re-asignación.

Al igual que en otros lenguajes, Javascript permite la definición de variables en las cuales almacenar datos. Existen 3 palabras reservadas que nos sirven para definir variables: var, let y const, pero para este artículo, nos concentraremos en estas últimas 2, y ahondaremos en su relación con la mutabilidad y la reasignación.

let: Permite definir una variable cuyo valor puede re-asignarse en cualquier momento.
const: Permite definir una variable cuyo valor no puede re-asignarse, esa decir, una constante.

Estas definiciones, si bien son concisas, podrían no bastar para dar cuenta del impacto que tiene el uso de uno versus el otro en Javascript, pues en mi opinión, es necesario hacer énfasis primeramente en los conceptos de re-asignación y mutabilidad que conlleva el uso de una u otra palabra reservada.

Para ello, nos remontaremos a cómo funciona la memoria en un computador: a grandes rasgos, e ignorando cierta cantidad de aspectos fundamentales sobre arquitectura de computadores, es la memoria RAM la que almacena los datos con los que vamos a trabajar. Estos datos tienen direcciones a través de las cuales accedemos a ellos.

Veamos un ejemplo: supongamos que tenemos una memoria RAM de 8 bytes, por lo que si necesitáramos almacenar 1 byte, podríamos hacerlo en cualquiera de los 8 espacios distintos disponibles. Vamos a decir que estos espacios son direcciones de memoria, y los nombraremos del 0 al 7.

Cuando declaramos la primera variable en nuestro código, digamos x = 5, el computador va a buscar un espacio de memoria disponible en nuestra RAM, digamos que en este caso es el espacio 0, y va a guardar allí el valor 5. Esto significa que la variable x va a apuntar a la dirección de memoria 0, porque en nuestra memoria RAM hemos guardado el número 5, pero nuestra variable x no contiene el número 5, sino que contiene la dirección de memoria donde se encuentra el número 5.

Memoria RAM de 8 bytes, con x apuntando a la dirección 0 y guardando el número 5.

Ahora bien, tenemos entonces variables que representan direcciones de memoria, y direcciones de memoria en donde se guardan datos. Estos datos pueden ser números, caracteres e incluso punteros. Para entender esto, primero vamos a definir el concepto de puntero:

Puntero: es un dato que contiene una dirección de memoria de otro dato, por eso se dice que apunta hacia otra dirección de memoria.

Siguiendo con nuestro ejemplo, podemos guardar en la dirección 1 de la memoria un puntero hacia la dirección 2. Por lo tanto, si quisiéramos acceder al dato que se encuentra en la dirección 2, tendríamos que acceder primero a la dirección 1, que nos llevará a la dirección 2.

Supongamos que en la dirección 2 se almacena una Lista de 4 elementos (7, 'a', 'c' y 9). Como ya no es un solo dato, vamos a utilizar más espacios de memoria: 4 bytes en total, desde el espacio 2 (el inicio) hasta el espacio 5 (el final). Entonces, resumiendo, en la dirección 0 de nuestra RAM tenemos el número 5, en la dirección 1 tendremos un puntero a la dirección 2, y en la dirección 2 una lista de 4 elementos:

Memoria RAM de 8 bytes, con x apuntando a la dirección 0, un puntero en la dirección 1 apuntando a la dirección 2, y 4 elementos correspondientes a la lista que parte en la dirección 2 y termina en la dirección 5.

Teniendo este escenario en mente, vamos a definir los conceptos de re-asignación y mutabilidad. La reasignación es cuando queremos cambiar el valor almacenado en la dirección de memoria que representa nuestra variable. Es decir, la operación x = 10 accedería a la dirección 0 y cambiaría el valor que allí se almacena de 5 a 10, lo que estaría re-asignando a la variable x. O bien, podríamos re-asignar la dirección de memoria 1 para que deje de almacenar la dirección de memoria 2, y de ahora en adelante guarde un número cualquiera en vez de un puntero.

Por otro lado, diremos que la mutabilidad es la capacidad que tiene una variable de modificar su contenido sin cambiar el valor almacenado en la dirección de memoria que representa. Siguiendo la idea anterior, si tenemos una nueva variable y que representa la dirección de memoria 1 (que recordemos, almacena un puntero a la dirección de memoria 2, donde hay una lista), y queremos modificar un elemento de esa lista, podemos hacerlo sin cambiar el valor que se encuentra en la dirección de memoria 1. Esto significa que estaríamos mutando la variable y, ya que vamos a modificar un valor en otra dirección de memoria. Sin embargo, si ahora queremos que la variable y tenga el valor 3, la estaría re-asignando y no mutando.

En resumen:

Re-asignación: capacidad de una variable de cambiar el valor almacenado en la dirección de memoria a la que apunta.
Mutabilidad: capacidad de una variable de modificar su contenido sin cambiar el valor en la dirección de memoria a la que apunta.

Habiendo entendido esto, podemos aterrizar estos conceptos al ecosistema de Javascript, observemos el siguiente ejemplo

const x = 10;
x = 5; // Uncaught TypeError: Assignment to constant variable.

Las variables definidas con const no se pueden re-asignar, por lo que una vez que le asignamos el valor 10, ya no hay nada más que podamos hacer para modificar ese valor. Lo mismo ocurre con objetos:

const x = { nombre: 'Javascript Chile' };
x.url = 'https://jschile.org/'; // Ningún problema.
x = { url: 'localhost' } ;      // Uncaught TypeError: 
                                // Assignment to constant variable.

En este caso, definimos un objeto el cual posteriormente mutamos, añadiéndole la propiedad url, sin embargo, cuando quisimos asignar un objeto diferente, nos encontramos un error. Esto es porque cuando trabajamos con objetos, lo que se almacena en la dirección de memoria que representa la variable es un puntero, el cual apunta a la dirección de memoria donde se almacena el objeto, y por lo tanto, intentar almacenar otro objeto implicaría cambiar el valor almacenado en la dirección de memoria de x, cambiando hacia donde apunta el puntero, y por lo tanto intentando re-asignar la variable.

Para finalizar, queda el siguiente ejemplo con let:

let x = { nombre: 'Javascript Chile' };
x.url = 'https://jschile.org/'; // Ningún problema.
x = { url: 'localhost' } ;      // Ningún problema.

Donde ambas operaciones funcionan porque let permite tanto la re-asignación como la mutabilidad. Dicho esto, vale la pena estudiar más sobre como la mutabilidad impacta en el desarrollo de nuestros productos, y en la forma en la que programamos. A modo de detalle, en este artículo utilizo el concepto re-asignación, porque las memorias RAM siempre tienen un dato asignado, siempre tendrán almacenado un 1 o 0 en sus celdas, por lo que sería erróneo en mi opinión hablar de asignación bajo el nivel de detalle en que se desenvuelve este artículo, más no significa que esté erróneo per sé hablar de asignar una variable.

Espero que se haya entendido bien el concepto con este artículo, y quedo atento a cualquier comentario que puedan tener, por último, quisiera mencionar que este artículo fue extraído de un Apunte de Introducción a Javascript, el cual redacté para mis estudiantes de Desarrollo Web, puedes descargarlo haciendo clic en la imagen:

Nos vemos!

Introducción a Elixir

Camilo — Wed, 22 May 2024 16:21:00 +0000

¿Se han preguntado que és lo que hace genial a un lenguaje de programación?. Una de las razones por la que Elixir es genial es su consistencia. José Valim tomó ideas de otros lenguajes de programación como Ruby y Erlang, ideas que han sido desarrolladas por más de 30 años y las hizo mucho más consistentes. 30 años de ideas pensadas para diferentes propósitos por diferentes personas condensadas en una serie de bibliotecas mucho más rápidas de usar y entender.

Elixir se ejecuta en la máquina virtual BEAM, una VM realmente antigua, ya que fue creada por Ericsson en 1986 para el lenguaje Erlang (Más antigua que Java). Estas tecnologías fueron las principales protagonistas de las aplicaciones en un entorno de telecomunicaciones que manejan innumerables solicitudes por segundo de una manera confiable y eficiente.

Unas décadas más tarde, esta VM fue considerada por José Valim, quien creó el lenguaje Elixir a mediados de 2011 para utilizar todo el poder de BEAM en un lenguaje moderno y enfocado en la experiencia de desarrollo. Este lenguaje también fue responsable de la popularización de la máquina virtual de Erlang.

Un pequeño vistazo de Elixir

booleano = true || false
numero = 123_456
string = "Un binario" <> "Concatenada" <> "Interpolación #{numero}"
char = ?A
atomo = :un_atomo
funcion = fn _ -> "Hola" end
mapa = %{valor: "hola"}
tupla = {:ok, 1234}
lista = [1, "dos", :tres]
keyword_list = [valor: "hola"]
IO.inspect("Imprimir en Terminal")
# Comentario
_ # variable placeholder
_var # variable omitida

defmodule MiModulo do

  @atributo "Un atributo del módulo"

  # Retorno el resultado de la última expresion
  def mi_funcion_publica(parametro \\ true) do
    "Función Pública con #{parametro}"
  end

  # Pattern matching selecciona cual ejecutar según la firma de la función
  def mi_funcion_publica() do
    "Función Pública Sin parámetros"
  end

  defp mi_funcion_privada() do
    "Función Privada"
  end
end

MiModulo.mi_funcion_publica()

¿Qué significa Consistencia?

La palabra consistencia se puede definir según la RAE como:

f. Duración, estabilidad, solidez.
f. Trabazón, coherencia entre las partículas de una masa o los elementos de un conjunto.

Adicionalmente definiremos coherencia:

f. Conexión, relación o unión de unas cosas con otras.

Así como cohesión:

f. Fís. Fuerza de atracción que mantiene unidas las moléculas de un cuerpo.

En el desarrollo de software los componentes que utilizamos para elaborar el sistema idealmente deben ser consistentes, coherentes y cohesivos, es decir, que tengan una armonía y sean una base sólida para facilitar la mantención e implementación de los requisitos del sistema.

Ejemplos de Inconsistencias

En otras tecnologías podemos encontrar inconsistencias.

Inconsistencias en la API

PHP es un gran ejemplo de inconsistencias en su biblioteca oficial de funciones.
Por ejemplo notemos como las diferencias entre las funciones str_replace y strpos. Ambas funciones para trabajar con strings.

El nombre es inconsistente, la primera utiliza guión bajo para separar str_ y la otra no.
El nombre de los parámetros es incosistente. $search y $haystack son equivalentes.

 str_replace(
    mixed $search,
    mixed $replace,
    mixed $subject,
    int &$count = ?
): mixed

strpos(string $haystack, string $needle, int $offset = 0): int|false

Además la función strpos puede retornar un valor que sea un entero, pero podría ser considerado falso (0).
Por lo que debería usar el operador === para verificar el real valor de retorno.

En Elixir se podría utilizar un retorno de tuplas {:ok, pos} y {:error, motivo}
y utilizar pattern matching, simplificando las validaciones.

Inconsistencias en los Datos

En otros lenguajes de programación una fuente de inconsistencias es la mutabilidad de sus estructuras de datos. Elixir al ser un lenguaje funcional trabaja con estructuras inmutables que permiten una consistencia en los datos.

El siguiente ejemplo escrito en Python, nos muestra los problemas de inconsistencias en lenguajes de programación con estructuras de datos mutables.

mapa = {
  'lista': [1,2,3],
  'numero': 10
}

lista = mapa['lista']
numero = mapa['numero']

lista += [4]
numero += 10

print(lista)
# [1, 2, 3, 4]

print(numero)
# 20

print(mapa)
# {'lista': [1, 2, 3, 4], 'numero': 10}

Hemos modificado la variable lista y numero, pero sin embargo la variable mapa fue afectada. Esto es debido a que lista fue accedido por referencia y numero accedido por valor.

En Elixir eso no pasa, gracias a su inmutabilidad. Podemos trabajar con las variables lista y numero sin miedo a alterar el valor de la variable mapa.

mapa = %{
  lista: [1, 2, 3],
  numero: 10
}

lista = mapa.lista
numero = mapa.numero

lista = lista ++ [4]
numero = numero + 10

IO.inspect(lista)
# [1, 2, 3, 4]

IO.inspect(numero)
# 20

IO.inspect(mapa)
# %{lista: [1, 2, 3], numero: 10}

https://en.wikipedia.org/wiki/Functional_programming

Las diferencias con lenguajes OOP

Acoplamiento en la OOP

Los objetos son el acomplamiento de tres componentes: Comportamiento, Estado y Mutabilidad (cambios en el tiempo). Cada vez que se crea un objeto se obtiene una entidad que acopla esos tres componentes. Este acoplamiento causa muchas veces problemas, ¿Cómo puedo solamente utilizar uno de los componentes?.

Una de las mayores fuentes de problemas es la herencia entre objetos. Si por ejemplo tenemos un objeto que tiene acoplado estado y comportamientos, luego deseo añadir más comportamientos, debo recurrir a la herencia. Los objetos por definición existen para encapsular un estado, para modificar el estado debo interactuar con el objeto. Al utilizar herencia se tiene un mecanismo que permite adulterar el estado directamente, invalidando al objeto. Es así como algunos lenguajes de programación incluyen operadores como protected, final, entre otros para controlar la visibilidad de lo que se supone no debería tener acceso.

Básicamente existe un problema cuya solución crea otros problemas, sin incluir cosas como la herencia múltiple. Todo esto debido al acomplamiento inherente de la orientación a objetos.

La Programación Orientada a Objetos (POO) no se trata de crear una taxonomía gigante con una compleja jerarquía de objetos. El uso desmedido de la sintaxis del punto (objeto.metodo()) es una consecuencia de esa mala interpretación. La POO se trata de tener objetos que parpean como un pato, pero no necesariamente son un pato (quack like a duck, but is not a duck). Hay una gran confusión acerca de que en la POO solo existen métodos y no funciones. Hasta Smalltalk (padre de la POO) hay funciones (escondidas bajo una sintaxis especial).

En el conocido libro del Design Patterns: Elements of Reusable Object-Oriented Software mencionan: "Preferir la composición por sobre la herencia".

Los lenguajes funcionales como Haskell, Lisp y Elixir han estado resolviendo problemas complejos sin recurrir a la herencia. Mientras que los lenguajes orientados a objetos pueden utilizar la composición gracias a las interfaces. Ya que las interfaces son un mecanismo de polimorfismo, es decir, que nos permiten trabajar con múltiples formas a través de un contrato pre-establecido.

Los Componentes de Elixir

En Elixir existe comportamiento (Módulos), estado (Datos) y una visión de mutabilidad (Procesos), pero no están acoplados. Lo que nos permite elaborar software utilizando solamente el componente requerido, sin incurrir en los problemas ocasionados por el acoplamiento de la POO. Elixir dispone de tres dimensiones para realizar sistemas, a diferencia de la POO que solamente cuenta con una. Por lo que puede tener un polimorfismo distinto en cada componente (Behaviours, Protocols, Messages).

En el libro Concepts, Techniques, and Models of Computer Programming mencionan la regla de lo menos expresivo. "Cuando se programa un componente, el modelo computacional correcto para lograr un programa natural es el menos expresivo posible". Lo que se puede simplificar como "utilizar la abstracción más simple posible para resolver el problema".

Ejemplo de Acoplamiento

Vamos por un ejemplo simple comparando la forma de contar caracteres en un string.

El siguiente es un ejemplo en Ruby.

"Hola".length
# 4

En Elixir la misma operación sería:

String.length("Hola")
# 4

En Ruby el string "Hola" es un objeto que además de tener
la estructura de datos, tiene una serie de comportamientos asociados.
Esta altamente acoplado.

En cambio en Elixir el string "Hola" solamente es un dato
que no tiene comportamientos. Para poder realizar operaciones
debemos utilizar las funciones del módulo String. Existe
un desacople entre datos y comportamientos.

¿Por qué es importante este desacople?

Veamos un ejemplo. Si asignamos una variable a "Hola",
con el tiempo podemos cambiar el contenido de la variable
y ya no podremos utilizar el método asociado a los tipos string.

variable = "Hola"
variable.length
# 4

variable = 1
variable.length
# (irb):4:in `<main>': undefined method `length' for an instance of Integer (NoMethodError)

Esto puede ser un problema, sobre todo si existe una jerarquía de herencias y combinado con la mutabilidad del lenguaje, es una receta para el caos y soluciones poco elegantes si no se maneja adecuadamente los riesgos.

En Elixir al estar totalmente desacoplados dato, comportamiento y cambios de estado, se puede asegurar productos de software libres de problemas asociados a jerarquías de herencias y mutabilidad.

Pattern Matching

Esta técnica propia de los lenguajes funcionales, se utiliza para buscar patrones y decidir qué hacer en cada momento. Debemos pensar en el operador = no como un signo igual típico de otros lenguajes, sino como el que nos encontramos en una función matemática del tipo x = a + 1. Es decir que estamos diciendo que x y a + 1 tienen el mismo valor.

# a = 1
# b = "elixir"
# c = "ninjas"
{a, b, c} = {1, "elixir", "ninjas"}

https://joyofelixir.com/6-pattern-matching

El Operador Pipe

Los sistemas operativos inspirados por Unix vienen usando Pipelines desde sus inicios.
En este ejemplo, listamos el contenido del directorio, filtramos solo las líneas que contienen "archivo.txt", y redirigimos la salida a un archivo llamado resultado.txt.

ls -l | grep "archivo.txt" > resultado.txt

https://www.swhosting.com/es/comunidad/manual/uso-de-pipes-en-sistemas-unix

En el caso de Elixir, el operador pipe (tubería) |> es una hermosa herramienta que nos permite expresar una cadena de funciones como una secuencia de acciones.

Aún si no has usado Elixir podrías entender la lógica del siguiente código.

parametros_formulario
|> validar_formulario()
|> insertar_usuario()
|> crear_reporte()
|> mostrar_resultado()

Utilizar una serie de operadores pipe se conoce como un pipeline. Es simple de leer y comprender lo que ocurre. Pero por su simpleza también tiene algunas limitaciones. Debido a que las funciones están encadenadas, dependen del resultado anterior. Si alguna de las funciones falla quebraría el flujo completo. No se puede hacer mucho frente a esto a menos que se maneje los casos de error en cada función.

https://blog.appsignal.com/2022/07/19/writing-predictable-elixir-code-with-reducers.html

En Elixir Todo es un Reductor (Reducer)

Primero partiremos explicando los conceptos de acumulador y reductor.

Acumulador

Un acumulador es una variable que durante la ejecución de un programa va referenciar así misma y almacenar el resultado de realizar operaciones con los valores contenidos en otras variables.

acumulador = acumulador + variable

Reductor

Un reductor es una forma de procesar una tarea grande poco a poco. Utiliza un acumulador para facilitar las operaciones intermedias y entrega un único resultado final.

La estructura común de un reductor es la siguiente.

reductor(elementos_enumerables, valor_inicial_acumulador, funcion_reductora)

elementos_enumerables: Una lista de elementos que pueden ser enumerados. Ejemplo [1, 2, 3].
valor_inicial_acumulador: El valor que tendrá nuestro acumulador en la primera ejecución de la función reductora. Ejemplo 0.
funcion_reductora: Es la función que recibe dos parámetros. El elemento en la lista y el valor actual del acumulador. Ejemplo fn elemento, acc -> acc + elemento end

El reductor ejecutará la función reductora por cada elemento y retornará el valor final del acumulador cuando cada elemento haya sido procesado.

https://redrapids.medium.com/learning-elixir-its-all-reduce-204d05f52ee7

Ejemplo

Vamos a ver un ejemplo concreto de cómo funciona un reductor. Primero definiremos una función para sumar dos valores. Utilizaremos la sintaxis simplificada con el operador de captura (&).
Lo que nos permite expresar una función de forma más corta.

La siguiente forma de expresar una función con dos parámetros

sumar = fn elemento, acc -> elemento + acc end

Puede ser simplificada utilizando el operador de captura &.

sumar = &(&1 + &2)

Sumaremos la lista de elementos [1, 3, 4] para que podamos obtener la sumatoria que es 8.

# sumar = fn elemento, acc -> elemento + acc end
sumar = &(&1 + &2)

&:erlang.+/2

Si utilizamos el módulo Enum y la función reduce obtendremos nuestro resultado

# reduce(enumerable, acumulador, funcion_reductora)
Enum.reduce([1, 3, 4], 0, sumar)

Es equivalente a llamar a la funcion sumar de forma anidada.

sumar.(4, sumar.(3, sumar.(0, 1)))

También puede ser expresada como un pipeline de la función sumar, cuyo valor incial es. 0.

0
|> sumar.(1)
|> sumar.(3)
|> sumar.(4)

Este pipeline se podría expresar como llamar a la función suma utilizando el resultado de la función anterior. En este caso se podría expresar como lo siguiente:

# 1
sumar.(0, 1)
# 4
sumar.(1, 3)
# 8
sumar.(4, 4)

CRC: Crear, Reducir y Convertir

Elixir utiliza módulos y tipos de datos, lo que permite una forma de organizar nuestro código en lo que se denomina CRC (Constructores, Reductores y Conversores). Por lo que tendremos funciones para (crear) un acumulador, funciones que realizarán operaciones (reductores) con este acumulador y finalmente funciones que transformarán el acumulador en un formato final (conversores). Ésto es algo que ha existido por largo tiempo en diferentes lenguajes de programación como Haskell o Lisp. Lo más importante que puedes hacer en un lenguaje es unir ideas utilizando composición.

La idea es crear un pipeline que reciba como primer parámetro un acumulador y realizar una serie de operaciones reduce hasta llegar al conversor final.

  entrada
  |> constructor() # crea el acumulador inicial
  |> reductor()
  |> reductor()
  |> reductor()
  |> conversor()  
  # salida de la función listo para ser utilizado por otro pipeline
  # o ser mostrado al usuario final

Por esta razón podemos considerar que todo en Elixir es un conjunto de acumuladores y reductores. Mucha de las funciones del core de Elixir pueden ser implementadas usando nada más que un acumulador y Enum.reduce.

¿Por qué es importante?

Gracias a ésta forma de organización podemos ver nuestro código de forma coherente
y unificada. Al tener una estructura de datos en común con varias funciones
podemos realizar operaciones y expresarnos con una facilidad de lectura mayor.
Nuestros sistemas serán más fáciles de entender y mantener en el futuro.

La consistencia es un factor importante de calidad en nuestros sistemas y utilizar CRC es una gran herramienta para lograr eso.

https://github.com/ElixirCL/ElixirCL/wiki/%5BTutorial%5D-CRC-y-DFTBLWB

# Creamos un nuevo mapa con nuestro acumulador
constructor = &%{acc: &1}

# Retornamos el valor del acumulador actualizado
suma = &%{acc: &1.acc + &2}

# Mostramos solamente el valor que deseamos
conversor = & &1.acc

0
|> constructor.()
|> suma.(1)
|> suma.(3)
|> suma.(4)
|> conversor.()

Ejemplo de CRC

Vamos a ejemplificar un poco utilizando un mapa del tesoro. En este mapa vamos a dar una serie de direcciones norte, sur, este y oeste. Se puede ver como tenemos una función de creación que retorna una tupla {x, y}, la cual será nuestra estructura de datos del acumulador. Luego tenemos una serie de reductores que modifican la tupla y devuelven una nueva tupla con los valores apropiados. Finalmente tenemos nuestro conversor que retorna un String con un mensaje final.

defmodule Tesoro do
  # Creador
  def nuevo(x, y), do: {x, y}
  def nuevo, do: nuevo(0, 0)

  # Reductores
  def norte({x, y}), do: {x, y - 1}
  def sur({x, y}), do: {x, y + 1}

  def este({x, y}), do: {x - 1, y}
  def oeste({x, y}), do: {x + 1, y}

  # Conversor
  def mostrar({x, y}), do: "El tesoro se encuentra en las coordenadas #{x},#{y}"
end

{:module, Tesoro, <<70, 79, 82, 49, 0, 0, 11, ...>>, {:mostrar, 1}}

import Tesoro

nuevo()
|> norte()
|> este()
|> este()
|> oeste()
|> oeste()
|> sur()
|> sur()
|> sur()
|> este()
|> este()
|> este()
|> mostrar()

"El tesoro se encuentra en las coordenadas -3,2"

Como se puede apreciar logramos generar nuestro mapa del tesoro utilizando un pipeline de funciones que aceptan una estructura de datos en común como primer parámetro (acumulador). Se realizan las operaciones a esta estructura para finalmente crear una salida con un formato específico.

Hemos logrado algo genial. Tomamos una idea compleja de distintas funciones y las unificamos como si fueran eslabones de una misma cadena. De esta forma puedes ver como las operaciones forman una cascada enviando valores. Hemos creado una composición utilizando reductores.

Las ideas de CRC (Crear, Reducir y Convertir) pueden ser encontradas a lo largo de todo el ecosistema de Elixir, por ejemplo con OTP y el estado de un GenServer o Phoenix para tomar un dato y convertir ese dato a HTML, SVG, JSON o similares.

El ver las operaciones como una cadena simplifica cómo construir, leer y probar todo el software en el ecosistema de Elixir, gracias a una excelente consistencia y decisiones de diseño.

¿Por qué usar Elixir frente a las alternativas?

Algunas razones:

Un lenguaje funcional moderno y preciosamente consistente. Permitiendo un nivel más desacoplado y consistente que con otras tecnologías.
Se ejecuta en la BEAM con más de 30 años de herramientas para sistemas robustos, escalables y concurrentes. Logrando una mayor confiabilidad y resiliencia a fallos que con otras soluciones.
Gran ecosistema de herramientas para IOT, Robótica, IA, Web, Mobile, entre otros.
Un mercado atractivo para profesionales con ofertas laborales novedosas y frescas, sin tanta competencia como en otras tecnologías. Mercado laboral en auge en USA, Alemania, Japón, entre otros.
Multitud de capacitaciones y certificaciones disponibles (Grox.io, Erlang Solutions).
Utilizado por empresas de alto calibre como Facebook, Whatsapp, Discord, Pepsico, Walmart, entre otros.

¿Qué nos depara la industria en el futuro?

La industria informática está llena de cambios. Podemos mencionar la tecnología de los 80's con las primeras computadoras personales como el Commondore o Atari. Luego en los 90's vimos los inicios de internet con HTML, JS y CSS. En los 2000's vimos el auge de las redes sociales como Facebook y plataformas como Youtube. En los 2010's se masificaron las aplicaciones y teléfonos móviles "inteligentes". ¿Qué se viene en la década del 2020's?. Lo más probable es la masificación de la IA y sistemas concurrentes. Casos donde Elixir y Erlang son idóneos, superando a otras alternativas como Python y Ruby. Los profesionales que aprendan lenguajes de la BEAM estarán preparados para las próximas décadas de la industria, debido a que cada día la concurrencia y robustez de los sistemas será mucho más necesaria.

Los lenguajes de programación que son "difíciles de contratar" siempre serán un problema. Desafortunadamente, este no es un problema que realmente puedas resolver, porque nadie conoce el futuro. Si por ejemplo elijes un lenguaje de programación popular hoy, luego a la gente deja de gustarle y no será fácil encontrar personal (VB6, Action Script Flash). ¿Qué pasa con casos como Python, donde la migración de 2.x a 3.x fue tan tortuosa, que prácticamente fue un cambio a un lenguaje distinto?. Las organizaciones que no se casan con un solo lenguaje o tecnología y adoptan estratégicamente nuevas herramientas, estarán mejor capacitadas para las variaciones del mercado e industria.

Imágen: https://commons.wikimedia.org/wiki/File:%C3%89lixir_et_liqueur.JPG

Documenta tu Evolución Profesional

Camilo — Tue, 02 Apr 2024 15:18:01 +0000

Un sitio web personal es un gran aliado para documentar nuestro camino y evolución en la industria I.T.

Github Es Insuficiente

Muchos pueden pensar de que solamente subiendo nuestro código a plataformas como Github, Gitlab, Codeberg y similares es suficiente. Pero lamentablemente tienen los siguientes problemas:

No sirven para documentar proyectos privados.
La información no está ordenada y es difícil de destacar las partes importantes.
Dependes de un tercero y no tienes autonomía al almacenar y distribuir tu contenido.

El principal problema es que cuando participas en proyectos donde no eres dueño del código. Normalmente para empresas privadas. En tu sitio web puedes por lo menos documentar que participaste en dichos proyectos (Si tu contrato lo permite).

Además muchas veces son tantos proyectos dispersos que es mejor tener un lugar centralizado que puedes poner en tu currículum vitae.

Super Tip

Si lograste algo importante en un proyecto privado puedes crear un ejemplo que no tenga los datos restringidos y que demuestre lo que aprendiste o lograste.

De esta forma puedes tener una documentación personal y tal ves en otros proyectos futuros puedas tener este código de ejemplo o cómo lograste algo en específico.

Comienza Hoy

Lo ideal es que si eres estudiante o estas aprendiendo, comiences desde ya a tener un sitio personal que documente los proyectos, ideas, eventos y otras experiencias que has vivido en tu carrera profesional. Si ya tienes algunos años te costará un poco más comenzar a documentar todo y tomará más tiempo ordenar el material que has acumulado con el paso de los años.

¿Qué tecnología usar?

Lo más importante es tener la capacidad de migración. Si algún evento causa que tu proveedor de hosting cierre, puedas encontrar otro fácilmente y migrar tu contenido. Además de poder ser almacenado en archive.org para preservación histórica.

La recomendación es utilizar sitios web estáticos con las viejas confiables tecnologías de HTML y CSS.

Usa un generador de sitios estáticos

Lo ideal es usar uno elaborado con la tecnología que más te guste, hay diversas opciones y para todos los gustos.

Acá una selección pequeña

geolessel / vox

The static site builder for Elixir lovers

Vox

The static site generator for Elixir lovers.

Quick start

There is a new site generator that is the quickest way to get started In order to use it, run

mix archive.install hex vox_new
mix vox.new blog

This will generate a simple scaffolded site that you can customize and tweak as you see fit.

There is also an example blog built with Vox that attempts to take advantage of all the features of Vox as they are built. You can look at the source code for that (and clone it and build it yourself) at geolessel/vox-example.

`vox.new` options

--esbuild - include a simple esbuild installation for asset compilation

Manual installation

The package can be installed by adding vox to your list of dependencies in mix.exs.

For now, it is recommended to install directly from GitHub. Note that the mix vox.new generator will generate the "~> 0.1.0" version instead.

…

View on GitHub

gohugoio / hugo

The world’s fastest framework for building websites.

A fast and flexible static site generator built with love by bep, spf13, and friends in Go.

Overview

Hugo is a static site generator written in Go, optimized for speed and designed for flexibility. With its advanced templating system and fast asset pipelines, Hugo renders a complete site in seconds, often less.

Due to its flexible framework, multilingual support, and powerful taxonomy system, Hugo is widely used to create:

Corporate, government, nonprofit, education, news, event, and project sites
Documentation sites
Image portfolios
Landing pages
Business, professional, and personal blogs
Resumes and CVs

Use Hugo's embedded web server during development to instantly see changes to content, structure, behavior, and presentation. Then deploy the site to your host, or push changes to your Git provider for automated builds and deployment.

Hugo's fast asset pipelines include:

Image processing…

View on GitHub

11ty / eleventy

A simpler site generator. Transforms a directory of templates (of varying types) into HTML.

eleventy 🕚⚡️🎈🐀

A simpler static site generator. An alternative to Jekyll. Written in JavaScript. Transforms a directory of templates (of varying types) into HTML.

Works with HTML, Markdown, JavaScript, Liquid, Nunjucks, with addons for WebC, Sass, Vue, Svelte, TypeScript, JSX, and many others!

➡ Documentation

Star this repo on GitHub!
Follow us on Mastodon @11ty@neighborhood.11ty.dev
Follow us on Bluesky @11ty.dev
Install from npm
Follow on GitHub
Watch us on YouTube
Chat on Discord
Latest:

Installation

npm install @11ty/eleventy --save-dev

Read our Getting Started guide.

Tests

npm test

We have a few test suites, for various reasons:

ava JavaScript test runner (assertions docs) (primary test suite in test/)
Node.js Test runner (secondary test suite in test_node/)
Vitest (in Browser Mode) (client tests in packages/client/test/)
Benchmark for Performance Regressions

These run in various environments:

Community Roadmap

Top…

View on GitHub

Crea tu propio generador de contenidos

Es una buena forma de practicar un lenguaje o tecnología, un proyecto pequeño que se adapte a tus necesidades. Aunque esta opción es solamente para quien desee dedicar mucho tiempo en detalles que ya están solucionados por los generadores disponibles.

Compra tu Dominio y Hosting

Lo ideal es tener un dominio y hosting propio. Puedes empezar con el hosting de Github Pages para empezar.

Proveedores de Dominio

https://nic.cl : Dominios de Chile
https://dyndns.com : Dominios para Ips
https://www.dynadot.com : Dominios Internacionales
https://porkbun.com/: Otro proveedor de dominios.

Proveedores de Hosting

Dependiendo de tus necesidades puedes tener algo propio en una Raspberry PI, o adquirir un hosting. La siguiente es una lista no ordenada de distintas opciones.

https://cpanelhost.cl/: Hosting Chileno Barato
https://www.silverhost.cl/: Hosting Chileno Mediano
https://pages.cloudflare.com/ : Hosting de Páginas Estáticas
https://pages.github.com/ : Hosting de Páginas Estáticas
https://codeberg.page/ : Hosting de Páginas Estáticas
https://neocities.org/ : Hosting de Páginas Estáticas
Servidor Propio (Raspberry PI)
Servidores VPS (DigitalOcean, Vultr, etc)
Servidores de Aplicaciones (Fly.io, Vercel)
Servidores de Nube (AWS, Azure, GCP)

Foto de Ilya Pavlov en Unsplash

¿Me conviene un Bootcamp Tecnológico?

Camilo — Thu, 28 Mar 2024 12:30:00 +0000

Los Bootcamps son escuelas donde te enseñan un conjunto de herramientas con el objetivo de mejorar tus habilidades y hacer más expedito tu proceso laboral en la industria de las tecnologías de información (I.T). Una pregunta habitual es ¿Me conviene un Bootcamp?. Debido a las diversas opciones, este pequeño artículo te podría ayudar a determinar si un Bootcamp es algo que quieras experimentar.

¿Cuál es tu perfil?

Lo primero en determinar es cuál es el perfil que tienes.

1. Beginner

Sin experiencia ni conocimientos previos. Vienes de otra industria o nunca has realizado ningún proyecto de informática.

Un Bootcamp te podría ayudar a definir tu camino y asesorarte en las tecnologías que puedes aprender. Además de presentarte un pequeño conjunto de proyectos que puedes hacer.

Sin embargo evalúa primero estudiar un curso específico (gratuito o de pago) de alguna tecnología para que puedas tantear el terreno antes de una inversión de tiempo y dinero significativa.

Personalmente recomendaría algún curso estatal de bajo coste como Talento Digital.

Recordar que los Bootcamps no son obligatorios para entrar en la industria o aprender las tecnologías.

2. Intermediate

Haz hecho algunos proyectos (sin usar tutoriales) pero tienes muy poca experiencia profesional en la industria.

Solo ingresa a un Bootcamp si realmente sientes que te dará un apoyo y valor relevante.

Si ya tienes algo de conocimientos, la recomendación es realizar proyectos en formato freelance o de apoyo a ONG para sacar filo y engrasar las herramientas.

El tener pequeños proyectos para clientes te dará mayores incentivos para aprender las herramientas y volverte un experto.

3. Expert

Haz estudiado una carrera de la industria o tienes experiencia laboral relevante en ella (más de dos años).

La verdad que un Bootcamp no te servirá mucho. Te conviene más cursos específicos de alguna tecnología o práctica. Realizar proyectos por tu cuenta, aumentar las habilidades blandas y mejorar tus redes de contacto serán más provechosos.

¿Tienes el Dinero?

Un Bootcamp es una inversión grande de dinero y tiempo. Por ningún motivo te endeudes (con un banco) para estudiar en uno. Ir a un Bootcamp no te da garantías de encontrar un trabajo ni tampoco comenzar recibiendo sumas millonarias de sueldo. No es una bala de plata que te da las llaves para entrar en la industria, simplemente son escuelas de capacitación.

La verdad yo recomendaría al menos dos años de estudio. Un Bootcamp ronda entre 6 a 12 meses.

Si cuentas con los recursos para costear una carrera técnica, recomendaría ir a una universidad o instituto certificado antes que un Bootcamp.

¿Cuál es su prestigio?

Muchas empresas en la actualidad tienen filtros sobre la calidad de los egresados de algunas instituciones. Procura que donde estudies tengan buena reputación en la industria y que sus egresados tengan buenas recomendaciones sobre la institución. El prestigio de donde estudiaste puede jugar a favor o en contra, sobre todo en los primeros años cuando no tienes mucha experiencia laboral que respalde tus capacidades.

¿Tienen redes de apoyo?

Un Bootcamp debería ser capaz de ayudarte en conseguir tu primer trabajo en la industria. Ya sea dándote empresas y prácticas o por último la capacidad de tener entrevistas. Si no te dan eso, no son diferentes a un curso presencial u online de alguna OTEC.

Además del conocimiento técnico un Bootcamp debería también darte asesoría en crear tu currículum y entrenar cómo hacer entrevistas laborales y redes de contacto.

Aprende los Fundamentos

Muchos Bootcamps se enfocan en tecnologías populares como Javascript y Python. Pero recordar que las tecnologías son efímeras, la industria cambia tanto como la dirección del viento, por lo que es de mucha importancia que aprendas los fundamentos que te permitirán adaptarte a cualquier tecnología o industria.

Yo personalmente recomiendo la tecnología Elixir, por su paradigma funcional, te permitirá salir de lo común y realizar proyectos en una amplia gama de contextos.

Si bien esta tecnología no es tan conocida como Javascript y Python (aún), te puede servir mucho para aprender Algoritmos, Sistemas Web, Apps Móviles, Robótica, Machine Learning y muchos otros casos de uso.

Sigue el Track de Elixir en Exercism para practicar ejercicios que te ayudarán a mejorar tus habilidades.

Podrías comenzar con tecnologías como Pascal, C y Assembler para aprender los fundamentos, altamente recomendado. Pero la verdad yo estimo que Elixir es una tecnología relevante y moderna, con un alto futuro y posibilidades de crecimiento. Personalmente lo veo como una apuesta segura.

Nada quita que una vez sepas los fundamentos puedas ir por otras tecnologías como Javascript, tener varias herramientas bajo el brazo nos dará mayor chances de destacar y tener seguridad personal de que podemos tener éxito en la maravillosa industria I.T.

Cover Foto por ThisisEngineering RAEng en Unsplash

Construyendo un mapa para aprender sobre el Back-end

Yorman Amaro — Wed, 28 Feb 2024 18:47:05 +0000

Para los que estudiamos desarrollo de software y nos fuimos por el desarrollo FullStack, sabemos que llegara ese momento donde tendremos que tomar una decisión ya sea por voluntad propia o simplemente porque nos lo exigen en nuestro trabajo o proyecto, y es me voy por el lado del Front-end o del Back-end.

Independientemente del camino que elijas, debes ser consciente de que cada lado será tan apasionante como complejo y es que el mundo de tecnologías que existen tanto en una como en la otra es tan diversa y amplia, que hay que tomarlo con calma y con una ruta bien definida.

Es por eso, que en este artículo lo que vamos a hacer es hablarte de forma amplia sobre el mundo del Backend, y que es lo que debes saber de esta rama del desarrollo de aplicaciones y, teniendo esto claro, puedas encauzar tu camino como un perfecto back.

Qué es el Back-end:

Esto es lo primero que lógicamente deberíamos saber para poder iniciar en esta rama, al menos saber para qué nos va a servir en nuestra aplicación tener un back-end.

De una forma simple, el back-end es la parte de toda aplicación que funciona del lado del servidor o también la podemos explicar como la parte que comunica los datos con los clientes; estos clientes pueden ser tanto internos como externos dentro de la misma empresa o clientes fuera de esta.

Las API:

Imagínate básicamente un puente, que es lo que hace un puente, comunica un lado con el otro; esto es lo que hace una API en nuestras aplicaciones, va a hacer el puente de comunicación para intercambiar información entre las peticiones de los clientes y nuestros datos en el servidor.

Debemos destacar, que este intercambio de información puede ser tanto del cliente hacia la API como de la API hacia el cliente, y esto va a depender del tipo de API que estemos manejando, lo que debemos saber es que una API puede ser sincrónica o asíncrona.

Sincrónica implica que el cliente espera una respuesta inmediata del servidor, mientras que la comunicación asíncrona implica que el cliente no espera una respuesta inmediata, sino que puede recibir una notificación posteriormente.

Protocolos de comunicación:

Estos protocolos van a definir cómo se establece la conexión, cómo se transmiten los datos y cómo se verifica la integridad de esos datos; son como los lineamientos de cómo se van a manejar los datos en la aplicación.

Estos protocolos van a depender del tipo de aplicación, arquitectura, entre otras, que estemos construyendo estos protocolos son:

REST: Manejado por formatos como JSON.
SOAP: Manejado por formatos como XML.
GraphQL: Permitiendo consultas de una forma más flexible.

Base de datos:

En un back-end también debemos construir las peticiones y la forma en que se van a enviar los datos, ese lenguaje se llama SQL.

En el mundo de los datos se manejan dos tipos:

Relacionales: En estos encontramos a MySQL, PostgreSQL, MariaDB.
No Relacionales: En estos encontramos a MongoDB, Redis, Cassandra, Neo4J.

Estos por nombrar algunos dentro de muchos más.

Estructura de datos y algoritmos:

Aquí estamos hablando, de la forma en que guardamos la información en memoria, con el fin de que esta pueda ser mejor utilizada en las diferentes peticiones que se hagan.

Las más usadas:

Arrays.
Pilas.
Colas.
Listas enlazadas.
Hashmaps.
Árboles.

Algoritmos:

Esta es una parte importante en un proyecto back-end, ya que es la forma en que vamos a resolver el flujo de la información para hacerlo de la manera más eficiente, mejorando las respuestas de nuestro sistema o puente de comunicación. Estas las podemos evaluar mediante lo siguiente:

Complejidad Temporal: Se refiere al número de operaciones que realiza un algoritmo para hacer una tarea.
Complejidad Espacial: Se refiere al espacio en memoria que utiliza un algoritmo para almacenar datos.
Notación Big O: Mide la complejidad algorítmica en términos de tiempo y espacio.

Estos conceptos son importantes tenerlos en cuenta al momento de desarrollar como back-end, así garantizamos las mejores prácticas y el mejor rendimiento de la app.

Framework y Librerías en el Backend:

Estos 2 conceptos son muy utilizados en nuestros días y son los que nos van a ayudar a construir nuestras aplicaciones en el back-end; un framework incluye todas las herramientas que necesitas para desarrollar un proyecto completo y una librería solo aborda utilidades específicas, sin embargo, actualmente una librería puede llegar hacer muchas cosas, tanto como un framework.

Estos son algunos lenguajes de programación con sus pares de librerías para el back-end:

Node.js: Express.js - Nest.js.
Python: Flask - Django - Fast API.
Ruby: Ruby on Rails.
PHP: Laravel - Synfony.
Java: Spring.
C++ y #C: .NET
Go: Fiber.
Elixir: Phoenix.

Objetos relacionales de mapeo (ORM) :

Estos van a establecer una estructura ya desarrollada para obtener muestras de datos, es decir, nuestras peticiones a la base de datos.

Menciono algunas con su referente lenguaje de programación:

JavaScript: Mongoose - Sequelize - TypeORM.
Java: Hibernate.
PHP: Doctrine.
.NET: Dapper.
Python: Django (esta librería ya incorpora un ORM).

Como podemos ver, en el back-end existe un universo de conceptos y herramientas con las cuales podemos construir ese puente de comunicación entre los datos y los clientes y que nos van a permitir hacer aplicaciones más eficientes; todo va a depender del tipo de arquitectura que estemos construyendo y con el lenguaje de programación con que lo estemos haciendo.

Este fue un artículo a modo introductorio, ya que en los próximos continuaremos en el lado del back-end, pero desarrollando más en profundidad cada una de las partes mencionadas aquí.

La tecnología que utilizas no impresiona a nadie. La experiencia que creas con ella lo es todo. Sean Gerety

Nos vemos en un siguiente artículo.
Un fuerte abrazo y saludos...

DEV Community: JavaScript Chile

Separación de Responsabilidades de los Dispositivos

¿Es ser un Ludista?

Tecnología Kosher/Halal

¿Qué opciones hay?

Espacio Dedicado

Tener un Celular Simple

Herramientas de Trabajo

Conclusiones

Programación Orientada a Objetos - Una abstracción de la realidad

¿Qué es la Programación Orientada a Objetos?

Objetos en la Vida Real y en la POO

Herencia: La Clave de la Jerarquía

Encapsulamiento: Protegiendo tus Secretos

Polimorfismo: La Magia de la Versatilidad

Conclusión: POO... ponlo en Acción

¿Trabajo Remoto o Híbrido?

Trabajo Presencial

Trabajo Híbrido

Trabajo Remoto

¿Por qué es importante?

Conclusión

Super Club Net: Libro de Introducción a HTML, CSS y JS

La revista Club Nintendo y su curso de HTML

Camilo for JavaScript Chile ・ Jun 8 '24

Contenidos

Desafío de Nombres y Apellidos

Desafío

Solución en Haskell

Solución en Elixir

Solución en Javascript

La revista Club Nintendo y su curso de HTML

Primera Parte

Conceptos

Segunda Parte

Conceptos

Tercera Parte (final)

Conceptos

Experiencia personal

Historia de la BeamVM

¿Qué es Erlang?

Origen de Erlang

¿Por qué Erlang es Bueno?

El modelo de Actores

Conclusión

Referencias

Entendiendo la Mutabilidad y la Re-asignación

Introducción a Elixir

Un pequeño vistazo de Elixir

¿Qué significa Consistencia?

Ejemplos de Inconsistencias

Inconsistencias en la API

Inconsistencias en los Datos

Las diferencias con lenguajes OOP

Acoplamiento en la OOP

Los Componentes de Elixir

Ejemplo de Acoplamiento

Pattern Matching

El Operador Pipe

En Elixir Todo es un Reductor (Reducer)

Acumulador

Reductor

Ejemplo

CRC: Crear, Reducir y Convertir

¿Por qué es importante?

Ejemplo de CRC

¿Por qué usar Elixir frente a las alternativas?

¿Qué nos depara la industria en el futuro?

Documenta tu Evolución Profesional

Github Es Insuficiente

Super Tip

Comienza Hoy

¿Qué tecnología usar?

Usa un generador de sitios estáticos

geolessel / vox

The static site builder for Elixir lovers

Vox

Quick start

vox.new options

Manual installation

`vox.new` options