Micronaut 2.0

Object Computing, Inc. (OCI) ha lanzado formalmente Micronaut 2.0, una versión importante del marco de trabajo basado en JVM que ayuda a crear aplicaciones sin servidor, nativas de la nube y basadas en microservicios que utilizan lenguajes como Java, Groovy y Kotlin.

Esta nueva versión mejora significativamente la experiencia del desarrollador con la disponibilidad de Micronaut Launch, una CLI de Micronaut más rápida y completamente renovada, un nuevo complemento de Maven y una actualización a la versión de Gradle. Ahora es compatible con Java 14, aplicaciones escritas en Groovy 3 y marcos reactivos que incluyen RxJava 3 y Reactor. Las capacidades sin servidor se han ampliado al agregar compatibilidad con Azure Functions y Cloud Functions de Google. También proporciona soporte para HTTP/2 y Servlets y un diseño de seguridad renovado. Finalmente, la nueva versión proporciona un rendimiento mejorado con una integración más profunda con GraalVM, consumo de memoria optimizado y tiempos de inicio mejorados hasta en un 20% en promedio en todo el marco.

Micronaut 2.0 incluye un nuevo servicio de inicio, Micronaut Launch, que ayuda a crear un andamio en las aplicaciones basadas en Micronaut. Disponible tanto como una herramienta basada en navegador como como una API REST, Launch ayuda a construir rápidamente y generar aplicaciones basadas en Micronaut. También ofrece una vista previa de la aplicación generada. La CLI de Micronaut tradicional ha pasado por un rediseño completo con un enfoque en el rendimiento y la eficiencia utilizando imágenes nativas de GraalVM. Micronaut Launch, un wrapper de Micronaut CLI, garantiza la interoperabilidad.

EL soporte de Maven se ha actualizado para traerlo a la paridad de características con el conjunto de características actual de Gradle. Se proporciona un nuevo complemento de Maven (mn: run) que ayuda a ejecutar aplicaciones Micronaut a través de Maven con capacidades de recompilación y reinicio automáticos. Además de esto, los proyectos de Maven heredan de un nuevo POM padre que configura la gestión de dependencias de forma más limpia.

La versión de Gradle se ha actualizado a 6.5, lo que brinda soporte de compilación incremental para proyectos de Micronaut 2.0. Básicamente, esto significa que Micronaut no tiene que ejecutar los procesadores de anotaciones completos para cada compilación.

El soporte sin servidor se ha hecho más sólido con la adición de Google Cloud Functions y Azure Functions, al tiempo que se mejora el conjunto de características para AWS Lambda. Micronaut proporciona dos enfoques para ayudar a crear aplicaciones sin servidor. El primer enfoque define una aplicación Micronaut tradicional y le agrega la característica de función sin servidor correspondiente (por ejemplo, funciones en la nube, funciones de Azure o lambdas). Dependiendo de la plataforma sin servidor elegida, Micronaut proporcionará la infraestructura de plomería necesaria para enrutar las solicitudes de funciones a la aplicación.

El segundo enfoque define un tipo de aplicación de "función sin servidor" que permite a los desarrolladores escribir código de función directo de bajo nivel específico para la función de función sin servidor elegida (p. Ej., Funciones en segundo plano de Google Cloud que se suscriben a mensajes pub-sub).

A continuación se muestra un ejemplo de una función sin servidor de bajo nivel escrita en Micronaut para la plataforma sin servidor de funciones de Google Cloud.

public class Function extends GoogleFunctionInitializer

        implements BackgroundFunction<PubSubMessage> {

    @Inject LoggingService loggingService;

    @Override

    public void accept(PubSubMessage message, Context context) {

        loggingService.logMessage(message);

    }

}

class PubSubMessage {

    String data;

    Map<String, String> attributes;

    String messageId;

    String publishTime;

}

Otras características que han llegado a la nueva versión incluyen la capacidad de probar funciones localmente utilizando los SDK proporcionados por la plataforma sin servidor que Micronaut incluye como dependencia y el soporte de imágenes nativas de GraalVM para AWS SDK 2.

Además de Netty, Micronaut 2.0 ahora agrega soporte para tiempos de ejecución de servlet integrados (Jetty / Tomcat / Undertow). Esto permite a los desarrolladores utilizar funciones tradicionales basadas en servlets en sus aplicaciones Micronaut. La experiencia de desarrollar aplicaciones Micronaut basadas en servlets es la misma que usar Netty para incluir recompilación automática / pruebas más rápidas, etc. Esto también incluye la capacidad de crear imágenes nativas basadas en GraalVM para los archivos uber basados en servlets.

A continuación se muestra un ejemplo de cómo crear una aplicación Micronaut basada en servlets utilizando la CLI y luego ejecutarla. Esto usa la función de servidor de embarcadero.

mn> create-app demo-servlet --features jetty-server

$ cd demo-servlet

$ ./gradlew run

org.eclipse.jetty.server.Server - Started @1219ms

io.micronaut.runtime.Micronaut - Startup completed in 615ms. Server Running: http://localhost:8080/

Micronaut 2.0 agrega soporte para HTTP / 2 y se puede habilitar usando un simple cambio en el archivo application.yml para una aplicación Micronaut. Este soporte está disponible actualmente solo para el servidor HTTP y el cliente basados en Netty.

La configuración del lado del servidor se muestra a continuación.

micronaut:

  ssl:

build-self-signed: true

  application:

name: http2Demo

  server:

http-version: http_2_0

El soporte para imágenes nativas de GraalVM se ha movido del estado experimental y ahora tiene soporte de primera clase y ampliado en todo el marco, lo que solidifica aún más el compromiso con GraalVM. Esto incluye la configuración automática de recursos estáticos, controladores JDBC, Hibernate, Flyway, AWS SDK 2 y otras áreas.

Dejo link : https://www.infoq.com/news/2020/08/micronaut-v2/

Records y Pattern Matching para instanceof en JDK 16

Todavia no me aprendo java 11 y ya tenemos noticias de java 16. Al parecer viene con registros, cosa que particularmente no me gusta y no entiendo la necesidad. Un ejemplo sería : 

record Name(String firstName, String lastName){}

Los registros se pueden declarar en un archivo separado o como parte de otra clase. 

Cuando se define una clase normal, implícitamente se agrega un constructor predeterminado. Los registros tienen un comportamiento similar y contienen implícitamente varios miembros:

• Campos privados para todos los componentes del registro.
• Métodos de acceso público para todos los componentes del registro.
• Constructor con argumentos para todos los componentes del registro. Este constructor se denomina constructor canónico.
• equals, toString y hashCode con su implementación.

El registro definido anteriormente no contiene ningún código personalizado, pero es posible definir métodos explícitos. Incluso es posible declarar explícitamente los diversos métodos agregados implícitamente y el constructor canónico. Por ejemplo, es posible crear un método toString personalizado.

En JDK 14, se requería que el constructor canónico fuera público. Desde JDK 15 en adelante, el constructor canónico implícito obtiene el mismo modificador de acceso que la clase de registro. Al definir un constructor canónico explícito, el modificador de acceso debe proporcionar al menos tanto acceso como la clase de registro.

Como parte del cambio, también se modificó la anotación @Override. Ahora se puede utilizar para anotar un método de acceso explícito en un registro.

También vamos a tener pattern matching para el instaceof. Ahora debemos hacer : 

if (person instanceof Customer) {

    Customer customer = (Customer) person;

    customer.pay();

}

y con pattern matching vamos poder hacer : 

if (person instanceof Customer customer) {

    customer.pay();

}

y podemos utilizarlo en el equals por ejemplo: 

@Override

public boolean equals(Object o) {

    return o instanceof Customer other &&

            name.equals(other.name);

}

Dejo link: https://www.infoq.com/news/2020/08/java16-records-instanceof/

Aprende con Google!!

Quiero recomendarles este sitio que encontré donde pueden aprender desde programación hasta vida profesional. Esta en castellano y esta muy bueno. 

No tiene cursos avanzados solo básicos pero para empezar esta bien, sin más dejo link: 

https://learndigital.withgoogle.com/activate/courses

opensource.microsoft.com

Como cambian los tiempos quien diría que Microsoft publicaría un sitio para promocionar sus proyectos open source y aquí lo tenemos! 

Sin más dejo link: https://opensource.microsoft.com/

Trait Objects para hacer Dynamic Dispatch en Rust

Seguimos con rust y el polimorfismo. 

Como sabemos el Dynamic Dispatch significa que el compilador llama código que es determinado en tiempo de ejecución.

Cuando usamos objetos de trait, Rust debe usar Dynamic Dispatch. El compilador no conoce todos los tipos que podrían usarse con el código que usa objetos de trait, por lo que no sabe qué método implementado en qué tipo llamar. En cambio, en tiempo de ejecución, Rust usa los punteros dentro del objeto de trait para saber a qué método llamar. Hay un costo de tiempo de ejecución cuando ocurre esta búsqueda que no ocurre con el envío estático. El envío dinámico también evita que el compilador elija insertar el código de un método, lo que a su vez evita algunas optimizaciones. Sin embargo, obtuvimos una flexibilidad adicional propia del polimorfismo.

Algunas reglas complejas gobiernan todas las propiedades que hacen que un objeto de trait sea seguro, pero solo dos reglas son relevantes. Un trait es seguro para objetos si todos los métodos definidos en el trait tienen las siguientes propiedades:

• El tipo de retorno no es Self.
• No hay parámetros de tipo genérico.

La palabra clave Self es un alias para el tipo en el que estamos implementando los métodos. Los objetos de trait deben ser seguros para objetos porque una vez que has usado un objeto de rasgo, Rust ya no sabe el tipo concreto que está implementando ese rasgo. Si un método de rasgo devuelve el tipo Self concreto, pero un objeto rasgo olvida el tipo exacto que es Self, no hay forma de que el método pueda usar el tipo concreto original. Lo mismo ocurre con los parámetros de tipo genérico que se completan con parámetros de tipo concreto cuando se utiliza el rasgo: los tipos concretos pasan a formar parte del tipo que implementa el rasgo. Cuando el tipo se olvida mediante el uso de un objeto de rasgo, no hay forma de saber con qué tipos completar los parámetros de tipo genérico.

Un ejemplo de un trait cuyos métodos no son seguros para objetos es el trait Clonar de la biblioteca estándar. La firma para el método de clonación en el rasgo Clonar se ve así:

pub trait Clone {

    fn clone(&self) -> Self;

}

El tipo String implementa el rasgo Clone, y cuando llamamos al método clone en una instancia de String, obtenemos una instancia de String. De manera similar, si llamamos a clonar en una instancia de Vec <T>, obtenemos una instancia de Vec <T>. La firma del clon necesita saber qué tipo sustituirá a Self, porque ese es el tipo de retorno.

El compilador le indicará cuando esté intentando hacer algo que viole las reglas de seguridad de los objetos con respecto a los objetos característicos. Por ejemplo, digamos que intentamos implementar la estructura Screen en el Listado 17-4 para contener los tipos que implementan el rasgo Clonar en lugar del rasgo Dibujar, así:

pub struct Screen {

    pub components: Vec<Box<dyn Clone>>,

}

Obtendríamos este error:

$ cargo build Compiling gui v0.1.0 (file:///projects/gui) error[E0038]: the trait `std::clone::Clone` cannot be made into an object --> src/lib.rs:2:5 | 2 | pub components: Vec<Box<dyn Clone>>, | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::clone::Clone` cannot be made into an object | = note: the trait cannot require that `Self : Sized` error: aborting due to previous error For more information about this error, try `rustc --explain E0038`. error: could not compile `gui`. To learn more, run the command again with --verbose.

Este error significa que no puede usar este trait de esta manera. Si está interesado en obtener más detalles sobre la seguridad de los objetos, consulte Rust RFC 255.

Dejo link: https://doc.rust-lang.org/book/ch17-02-trait-objects.html

Scala 3, indentación en vez de llaves ???

Una característica experimental, Scala 3 impone algunas reglas sobre sangría y permite que algunas apariciones de llaves {...} sean opcionales. Se puede desactivar con el indicador del compilador -noindent.

• Primero, algunos programas mal sangrados van a estar marcados con un error de tipo advertencias.
• En segundo lugar, algunas apariciones de llaves {...} se hacen opcionales. Generalmente, la regla es que agregar un par de llaves opcionales no cambiará el significado de un programa bien sangrado.

Esta característica seguro los hace pensar en python, pero les recuerdo que en haskell tambien la identación es importante. Y scala, tiene más influencia de haskell que de python.

El compilador impone dos reglas para programas bien sangrados, marcando las violaciones como advertencias.

1.En una región delimitada por llaves, no se permite que ninguna instrucción comience a la izquierda de la primera instrucción después de la llave de apertura que comienza una nueva línea.

Esta regla es útil para encontrar llaves de cierre faltantes. Previene errores como:

if (x < 0) {

  println(1)

  println(2)

println("done")  // error: indented too far to the left

2.Si la sangría significativa está desactivada (es decir, en el modo Scala-2 o en -noindent) y estamos al comienzo de una subparte con sangría de una expresión, y la parte con sangría termina en una nueva línea, la siguiente instrucción debe comenzar en una ancho de sangría menor que la subparte. Esto evita errores en los que se olvidó una llave de apertura, como:

if (x < 0)

  println(1)

  println(2)   // error: missing `{

Estas reglas aún dejan un gran margen de maniobra sobre cómo se deben sangrar los programas. Por ejemplo, no imponen ninguna restricción sobre la sangría dentro de las expresiones, ni requieren que todas las declaraciones de un bloque de sangría se alineen exactamente.

Las reglas generalmente son útiles para identificar la causa raíz de los errores relacionados con la falta de llaves de apertura o cierre. Estos errores suelen ser bastante difíciles de diagnosticar, en particular en programas grandes.

Además, el compilador insertará tokens <indent> o <outdent> en ciertos saltos de línea. Gramaticalmente, los pares de tokens <indent> y <outdent> tienen el mismo efecto que los pares de llaves {y}.

Con estas nuevas reglas, las siguientes construcciones son todas válidas:

trait A:

  def f: Int

class C(x: Int) extends A:

  def f = x

object O:

  def f = 3

enum Color:

  case Red, Green, Blue

type T = A:

  def f: Int

given [T](using Ord[T]) as Ord[List[T]]:

  def compare(x: List[T], y: List[T]) = ???

extension (xs: List[Int])

  def second: Int = xs.tail.head

new A:

  def f = 3

package p:

  def a = 1

package q:

  def b = 2

Ojo que agregá los : 

En fin, me parece un gran cambio y va a generar 2 formas de escribir y no sé si es la mejor idea, ya que un junior no va saber cuando escribir de que forma. 

Dejo link: https://dotty.epfl.ch/docs/reference/other-new-features/indentation.html

Rust by Example

Tal vez este link lo conocen todos y yo recien lo veo, pero bueno quien me quita lo compartido. 

En la docu oficial de Rust hay un apartado Rust by example, que esta muy bueno. Dada que la docu es muy extensa este apartado viene bien para aterrizar algunos conceptos programando. 

Sin más, dejo link: https://doc.rust-lang.org/stable/rust-by-example/

Polimorfismo con traits en Rust

Siguiendo con Rust y su implementación a conceptos de orientación a objetos, veamos como implementa polimorfismo sin el concepto de herencia tradicional, sino con traits. 

 

La documentación oficial de Rust explica el polimorfismo en Rust con un ejemplo. Crea una herramienta de interfaz gráfica de usuario (GUI) de ejemplo que recorre una lista de elementos, llamando a un método de dibujo. Este metodo puede dibujar diferentes tipos como Button o TextField.

No implementaremos una biblioteca GUI completa para este ejemplo, pero mostraremos cómo encajarían las piezas. En el momento de escribir la biblioteca, no podemos conocer ni definir todos los tipos que otros programadores podrían querer crear. Pero sabemos que la interfaz gráfica de usuario necesita realizar un seguimiento de muchos valores de diferentes tipos, y necesita llamar a un método de dibujo en cada uno de estos valores con tipos diferentes. No necesita saber exactamente qué sucederá cuando llamemos al método de dibujo, solo que el valor tendrá ese método disponible para que lo llamemos.

Para hacer esto en un lenguaje con herencia, podríamos definir una clase llamada Componente que tenga un método llamado dibujar. Las otras clases, como Button, Image y SelectBox, heredarían de Component y, por lo tanto, heredarían el método de dibujo. Cada uno podría redefinir el método de dibujo para definir su comportamiento personalizado, y la ventana podría tratar todos los tipos como si fueran instancias de componentes y llamar a dibujar sobre ellos. Pero debido a que Rust no tiene herencia, necesitamos otra forma de estructurar la biblioteca de interfaz gráfica.

Para implementar el comportamiento que queremos que tenga la interfaz gráfica de usuario, definiremos un traits llamado Dibujar que tendrá un método llamado dibujar:

pub trait Draw {

    fn draw(&self);

}

Ahora definimos la ventana que tiene que ser capaz de dibujar diferentes tipos de componentes. Para eso la ventana va tener un vector de componentes. Y definimos un componente como una caja o Box que contiene un tipo dinámico que implementa el trait Draw : 

pub struct Screen {

    pub components: Vec<Box<dyn Draw>>,

}

Recordemos que en Rust la definición de un "objeto" esta dividida en sus datos y sus métodos. Ahora definamos los métodos: 

impl Screen {

    pub fn run(&self) {

        for component in self.components.iter() {

            component.draw();

        }

    }

}

Alguien atento, podria decir porque no utilizamos genericos con ventana de este modo : 

pub struct Screen<T: Draw> {

    pub components: Vec<T>,

}

impl<T> Screen<T>

where

    T: Draw,

{

    pub fn run(&self) {

        for component in self.components.iter() {

            component.draw();

        }

    }

}

Pero el problema aquí es que no se va a poder utilizar Screen con diferentes componentes. Si tipamos a Screen con Button por ejemplo, solo va poder tener Buttons y no es lo que queremos. Hago esta aclaración porque con este contraejemplo se ve la función de la caja o Box, que es permitirnos diferentes componentes que implementan Draw. 

Ahora agregaremos algunos tipos que implementan Draw:

pub struct Button {

    pub width: u32,

    pub height: u32,

    pub label: String,

}

impl Draw for Button {

    fn draw(&self) {

        // code to actually draw a button

    }

}

//------------------------------

struct SelectBox {

    width: u32,

    height: u32,

    options: Vec<String>,

}

impl Draw for SelectBox {

    fn draw(&self) {

        // code to actually draw a select box

    }

}

Y por último ver la magia en acción: 

use gui::{Button, Screen};

fn main() {

    let screen = Screen {

        components: vec![

            Box::new(SelectBox {

                width: 75,

                height: 10,

                options: vec![

                    String::from("Yes"),

                    String::from("Maybe"),

                    String::from("No"),

                ],

            }),

            Box::new(Button {

                width: 50,

                height: 10,

                label: String::from("OK"),

            }),

        ],

    };

    screen.run();

}

Como vemos llamamos a run de screen que llamará a draw. 

Al especificar Box <dyn Draw> como el tipo de valores en el vector de componentes, hemos definido que Screen pueda aceptar diferentes tipos en dibujar pero todos deben implementar Draw sino tirra error en tiempo de compilación: 

use gui::Screen;

fn main() {

    let screen = Screen {

        components: vec![Box::new(String::from("Hi"))],

    };

    screen.run();

}

Esto no compila porque String no es un Draw : 

$ cargo run

   Compiling gui v0.1.0 (file:///projects/gui)

error[E0277]: the trait bound `std::string::String: gui::Draw` is not satisfied

 --> src/main.rs:5:26

  |

5 |         components: vec![Box::new(String::from("Hi"))],

  |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `gui::Draw` is not implemented for `std::string::String`

  |

  = note: required for the cast to the object type `dyn gui::Draw`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.

error: could not compile `gui`.

To learn more, run the command again with --verbose.

Dejo link: 

https://doc.rust-lang.org/book/ch17-02-trait-objects.html

Programación funcional, pros y contras

Lei un articulo y me gusto mucho, por lo tanto les dejo un resumen, al final esta el articulo original :

Como saben, los programadores son personas creativas, pero al mismo tiempo se adhieren celosamente a ciertas ideas, por ejemplo, la elección de un lenguaje de programación. PHP se considera un "lenguaje vago" y JavaScript es magia "difícil de predecir". Y en medio de la gran abundancia de lenguajes, los lenguajes funcionales están ganando cada vez más seguidores y cada vez más se están abriendo camino en la mayoría de las empresas de todo el mundo. Según la analítica RedMonk. Desde junio de 2017 y la evaluación combinada de la popularidad de los lenguajes en GitHub y Slack Overflow, los lenguajes funcionales (Elm, Elixir) están creciendo lenta pero seguramente. El gran aumento en la popularidad de JavaScript también está impulsando un mayor interés en FP. Además, los desarrolladores con experiencia en programación funcional posteriormente comenzaron a trabajar en frameworks y como resultado, tenemos Redux, React, MobX y otras librerías que usan millones de personas.

Entonces, ¿qué es la programación funcional, por qué hay tanto auge y por qué vale la pena considerar aprenderla? Vamos a resolverlo.

El mundo de JavaScript está hirviendo. Hace unos años, solo unos pocos desarrolladores entendían la programación funcional, pero en los últimos tres años, casi todas las bases de código de grandes aplicaciones han estado utilizando activamente ideas tomadas del mundo de la programación funcional. Y por una buena razón: la programación funcional le permite escribir código más conciso y predecible, y es más fácil de probar (aunque aprender desde cero no es fácil).

Las principales características distintivas del desarrollo de software con FP:

• funciones puras;
• evitar el estado compartido, datos mutables y efectos secundarios;
• La prevalencia de un enfoque declarativo más que imperativo.

La programación funcional se basa inherentemente en los principios fundamentales y definitorios enumerados anteriormente. Y para comenzar a comprenderlos, primero debe cambiar al modo "académico" y cómo debe estudiar las definiciones de términos que lo seguirán implacablemente en FP: funciones puras, composición de funciones, evitar el estado compartido, etc. Esto es más como volver a la escuela. a una lección de matemáticas, pero después de eso verás tanto la funcionalidad como la programación de una manera completamente diferente.

Profundicemos un poco más en los términos de FP y, al menos superficialmente, comprendamos lo que significan.

Las funciones puras  son funciones deterministas sin efectos secundarios. Una función determinista significa que para el mismo conjunto de valores de entrada, devuelve el mismo resultado. Para FP, las propiedades de tales funciones son muy importantes: por ejemplo, las funciones puras tienen transparencia referencial: puede reemplazar una llamada de función con su valor final sin cambiar el valor del programa.

La composición de funciones se refiere al proceso de combinar dos o más funciones para crear una nueva función o realizar cálculos.

El principal problema con los estados compartidos es que para comprender los efectos de una función, debe conocer el historial completo de cada variable compartida que utiliza la función. Por lo tanto, la programación funcional evita estados compartidos, confiando en cambio en estructuras de datos inmutables y computación sin procesar para extraer nuevos datos de los existentes. Otro matiz que surge cuando se trabaja con estados compartidos es que cambiar el orden de las llamadas a funciones puede provocar una avalancha de errores. En consecuencia, al evitar estados compartidos, también evita este problema.

Subyacente a toda la programación funcional está la inmutabilidad (inmutabilidad). Y aquí es importante no confundirse const con la inmutabilidad. const crea un enlace de nombre variable que no se puede reasignar después de la creación, pero no crea objetos inmutables. No podrá cambiar el objeto al que pertenece el enlace, pero aún puede cambiar las propiedades de este objeto const, por lo tanto , los enlaces creados no son inmutables. Los objetos inmutables no se pueden cambiar en absoluto. Esto se logra mediante la congelación profunda de las variables.

Los efectos secundarios significan que, además de devolver un valor, la función también interactúa con el estado mutable externo. ¿Por qué FP los evita? Porque de esta manera los efectos del programa son mucho más fáciles de entender y probar. Haskell, por ejemplo, usa mónadas para aislar los efectos secundarios de las funciones puras.

El punto es que el enfoque imperativo funciona según el principio de control de flujo y responde a la pregunta "cómo hacerlo". El enfoque declarativo describe el flujo de datos y responde a la pregunta "qué hacer". Además, el código imperativo a menudo se basa en instrucciones (operadores), mientras que el código declarativo se basa más en las expresiones.

Entonces, descubrimos qué es la programación funcional y qué necesita saber al respecto. Y, antes de pasar a discutir sus ventajas, propongo pasar primero por las desventajas, más precisamente, para comprender la esencia del estereotipo "la programación funcional no es natural".

A juzgar por lo que escribí anteriormente, los seguidores de la programación funcional ya deberían haber surgido entre los lectores. Sin embargo, a pesar de la gran cantidad de artículos laudatorios, no hay menos artículos titulados "La programación funcional es extraña y no tiene futuro" (por ejemplo). ¿Esto significa que estoy equivocado? No. ¿Hay alguna razón para pensar que la FA es extraña? Por supuesto.

Permíteme darte una cita de Internet que refleja completamente la actitud de muchos desarrolladores hacia FP:

"Escribir código funcional es como escribir al revés y la mayoría de las veces es como resolver un rompecabezas en lugar de explicar el proceso a una computadora".

De hecho, esta es una actitud bastante subjetiva hacia la FP para aquellos que no quieren dedicar suficiente tiempo para comprender los matices de la programación funcional y simplemente intentarlo. Pero, como prometí, veamos las desventajas de FP y luego veamos las ventajas.

Primero, no existe un vocabulario eficiente desordenado y configurado para lenguajes funcionales. Los diccionarios puramente funcionales son más lentos que las tablas hash, y esto puede ser crítico para algunas aplicaciones. En segundo lugar, no hay tablas hash débiles puramente funcionales, aunque para la mayoría de los desarrolladores esta falla puede pasar desapercibida.

Además, FP no es adecuado para algoritmos en gráficos (debido a su funcionamiento lento) y, en general, para aquellas soluciones que se han basado en programación imperativa durante décadas.

De acuerdo, el último punto suena más como una queja: no podemos culpar a FP por lo que no estaba destinado. Por lo tanto, propongo recurrir a lo agradable, es decir, a las ventajas de FP y su uso en proyectos reales por parte de compañías internacionales reales.

Uno de los beneficios más obvios de la programación funcional son las abstracciones de alto nivel que ocultan muchos de los detalles de las operaciones de rutina, como la iteración. Debido a esto, el código es más corto y, como resultado, garantiza menos errores que se pueden cometer.

Además, el FP contiene menos primitivas de lenguaje. Las clases bien conocidas en FP simplemente no se usan: en lugar de crear una descripción única de un objeto con operaciones en forma de métodos, la programación funcional utiliza varias primitivas básicas del lenguaje que están bien optimizadas internamente.

Además, la programación funcional permite al desarrollador acercar el lenguaje al problema, en lugar de viceversa, todo a expensas de las estructuras flexibles y la flexibilidad del lenguaje. Además, FP ofrece a los desarrolladores nuevas herramientas para resolver problemas complejos que los programadores de POO a menudo descuidan.

De hecho, es demasiado largo para enumerar todas las ventajas de la programación funcional; realmente hay muchas de ellas. Puedo decir esto: trabajar con lenguajes funcionales proporciona una escritura de código precisa y rápida, facilita las pruebas y la depuración, los programas son de nivel superior y las firmas de funciones son más informativas.

Por supuesto, uno no puede negar las ventajas de POO, pero vale la pena recordar que los lenguajes funcionales están a la par con muchos otros en términos de conveniencia y merecen su atención.

En el mundo de TI, nada sucede. Una cosa se aferra a la otra, y ahora todas las tendencias más actuales están interconectadas.

Si recordamos las tendencias más sensacionales de 2016-2017, estas, por supuesto, serán AI, IoT, Big Data y Blockchain. Están en boca de todos, todos conocen su potencial y sus características clave. Y son algunas de estas tendencias las que han catalizado la creciente popularidad de la programación funcional entre los desarrolladores.

Actualmente, el problema del procesamiento paralelo y el trabajo con grandes flujos de datos es muy grave, en otras palabras, trabajar con Big Data. Y, paralelizando el procesamiento de estos datos, puede obtener el resultado deseado en una fracción de segundo, lo cual es muy crítico en el mundo real. Además, no se olvide de la informática descentralizada (distribuida): blockchains y otras, que, en esencia, son un mecanismo bastante complejo. Y para tales cálculos, el código funcional es más adecuado debido a todos los principios de la programación funcional (como las funciones puras, por ejemplo). El uso de todas las técnicas básicas de FP facilita la ejecución y el mantenimiento de código paralelo.

Además, si la programación funcional anterior se usaba solo para resolver problemas específicos, ahora incluso se aplica a proyectos clásicos. 

Como probablemente ya haya entendido, no debe temer la programación funcional. Un poco de diligencia y curiosidad, y ahora has dominado la FP. Aquí hay algunos consejos para aquellos que han decidido probarse en un nuevo género y aprender algo radicalmente nuevo:

• Relájate :) Al principio será muy complicado, teniendo en cuenta que tendrás que dejar atrás lo que sabes y aprender nuevos enfoques y principios. Y eso esta bien. Piense en la primera vez que aprendió a codificar. Nada malo sucederá.
• Comience con micro tareas para tenerlo en sus manos.
• Comience a aprender Haskell y luego pase a Scala (o F #) para comenzar a comprender los principios de programación funcional (y al mismo tiempo comenzar a pensar más "funcional").

Dada la prevalencia de la programación funcional, puede estar seguro de su futuro profesional (con la debida diligencia), ya que seguramente puede usar sus habilidades recién adquiridas. ¡No tengas miedo de intentarlo!

Dejo link: https://dou.ua/lenta/articles/functional-programming/

Scala.js

Que tal si llevamos a scala al browser?? Bueno esto se puede hacer con scala.js. 

Scala.js es básicamente el typescript de scala y provee muchas cosas más que typescript : 

Y otro tema interesante es que tiene integración con los framework javascript más utilizados como react o Vue.js

No soy muy fanatico del Frontend, pero esta sin duda es una gran opción. 

Dejo link: https://www.scala-js.org/doc/

https://www.scala-js.org/doc/tutorial/basic/

Se creo la Micronaut Foundation

Quiero hacerme eco de esta noticia dado que me interesa mucho el futuro de Micronaut.

Object Computing, Inc. (OCI) ha anunciado la creación de la Fundación Micronaut, una fundación sin fines de lucro establecida para promover la innovación y la adopción de Micronaut. La fundación "supervisará la hoja de ruta y el desarrollo del software, las mejores prácticas y procesos, el control de repositorio, la documentación y el soporte, y la recaudación de fondos relacionados con el framework de código abierto". La fundación recibirá fondos iniciales de $ 2M de OCI para desarrollo.

Anteriormente conocido como Project Particle, Micronaut es un framework completo basado en JVM para crear aplicaciones basadas en microservicios, nativas de la nube y sin servidor que se pueden escribir en Java, Groovy y Kotlin. Micronaut se introdujo en marzo de 2018 y posteriormente fue de código abierto en mayo de 2018.

Dejo link: https://www.infoq.com/news/2020/07/oci-micronaut-foundation/

Piratería y desarrollo: discursos, historias y política de un amor negado

Cuando vi este video pensé en situaciones que suceden en el mundo del software y en general en todas las industrias. 

Me paso en el blog que por algunos comentarios gente me acusaba de utilizar por ejemplo imágenes que tenían copyright, y en realidad esas imágenes no agregaban mayor valor al post en sí, sino que eran decorativas. Copyright tiene libros enteros de los que los apoyan y los que lo condenan, pero por ejemplo con las imágenes que les contaba, mucha gente podría conocer esas imagenes a partir de un post que nada que ver. Y la rueda puede seguir rodando... En general pienso que es más lo que se pierde de lo que se gana, en fin les dejo el video : 

Contador de palabras ...

Me gustaría hacer un conjunto de post de contadores de palabras, en diferentes tecnologías. Ya se lo que piensan : 

String[] palabras = getPalabras()

int contador = 0

for (String p : palabras) contador++

return contador

o los que piensan de forma más funcional : 

String[] palabras = getPalabras()

int contador = palabras.fold(0, (c, a) => c++)

Pero la idea de esta actividad es hacerla en paralelo, por ejemplo utilizar 3 hilos. y contar el 1/3 en un hilo, y así...

Empiezo mi tarea haciendo un github : https://github.com/emanuelpeg/contador

Por algo se empieza, quien me ayuda??  

Conectarse a un servidor FTP con Python

Para conectarse a un servidor FTP desde Pythos debemos utilizar el módulo ftplib y la clase FTP (que original). 

El constructor de FTP, recibe como parámetros al host, usuario, clave. A la vez, esta librería nos provee un monton de funcionalidad, veamos un ejemplo : 

from ftplib import FTP

ftp = FTP()

ftp.connect('0.0.0.1', 21, -999)

ftp.login('user', 'pass')

print ftp.getwelcome()

ftp.mkd('nuevo-dir')

ftp.cwd('nuevo-dir')

print ftp.pwd()

ftp.storlines('STOR example.txt', open('ftp_examples.py', 'r'))

ftp.rename('example.txt', 'example.py')

ftp.dir()

archivo = ftp.retrlines('RETR example.py')

print archivo

ftp.close()

Y listo!! 

The RedMonk Programming Language Rankings: June 2020

Media tarde la noticia, estamos a fines de Julio :S

Pero bueno, no quería dejar pasar este gráfico sobre los lenguajes más utilizados. Al parecer Python toma la delantera pero javasctipt sigue adelante. 

En fin, hay varios rankings y algunos dan a ganador a Java o a Python o Javascript. Que se yo? Den su opinión!!  

Dejo link: https://redmonk.com/sogrady/2020/07/27/language-rankings-6-20/

Machine Learning at Enterprise Scale

Quiero compartir este libro de Machine Learning que es gratuito y parece bastante bueno, sin más :

https://get.oreilly.com/ind_machine-learning-at-enterprise-scale.html

Enviando e-mails desde Python

Para poder enviar e-mail desde un servidor (u ordenador local), en primer lugar, es necesario contar con un MTA (Mail Transpor Agent o “Agente de transporte de correo”). Uno de los MTA más populares para sistemas linux, es sendmail. Por lo tanto debemos instalarlo:

sudo apt-get install sendmail

Para enviar e-mails desde Python, éste nos provee smtplib, otro módulo de la librería estándar de Python, quien nos permitirá enviar mensajes de correo electrónico, incluso, en formato HTML.

Solo necesitaremos:

• Crear un objeto smtplib.SMTP el cuál recibirá como parámetro de su método constructor, el host (localhost)
• Crear un mensaje de correo: Enviar el mensaje mediante una llamada al método sendmail del objeto SMTP.

Veamos el código : 

import smtplib

remitente = "ElmachodelPirulin <emanuel@blog.com.ar>"

destinatario = "Ella <ella@gmail.com>"

asunto = "E-mail enviado desde Python"

mensaje = """Hola!<br/> <br/>

Este es un <b>e-mail</b> enviando desde <b>Python</b>

"""

email = """From: %s

To: %s

MIME-Version: 1.0

Content-type: text/html

Subject: %s

%s""" % (remitente, destinatario, asunto, mensaje)

try:

  smtp = smtplib.SMTP('localhost')

  smtp.sendmail(remitente, destinatario, email)

  print "Correo enviado"

except:

  print """Error: el mensaje no pudo enviarse.

  Compruebe que sendmail se encuentra instalado en su sistema"""

Así de simple, enviamos un e-mail con Python!

Conceptos que debemos tener claros cuando hablamos de lenguajes informáticos...

Cuando se habla de lenguajes no se tiene bien en claro muchos conceptos, por eso voy a tratar de dejar algo de luz aquí : 

Lenguaje informático: es un lenguaje artificial, utilizado por ordenadores y personas para comunicarse. Los lenguajes informáticos, pueden clasificarse en: 

• lenguajes de programación (Python, PHP, Pearl, C, etc.); b) 
• lenguajes de especificación (UML)
• lenguajes de consulta (SQL)
• lenguajes de marcas (HTML, XML)
• lenguajes de transformación (XSLT)
• protocolos de comunicaciones (HTTP, FTP)
• entre otros... 

Lenguaje de programación: es un lenguaje informático, diseñado para expresar órdenes e instrucciones precisas, que deben ser llevadas a cabo por una computadora. El mismo puede utilizarse para crear programas que controlen el comportamiento físico o lógico de un ordenador. Está compuesto por una serie de símbolos, reglas sintácticas y semánticas que definen la estructura del lenguaje.

Lenguajes de alto nivel: son aquellos cuya característica principal, consiste en una estructura sintáctica y semántica legible, acorde a las capacidades cognitivas humanas. A diferencia de los lenguajes de bajo nivel, son independientes de la arquitectura del hardware, motivo por el cual, asumen mayor portabilidad y son mucho más abstractos. Se acercan al humano y se alejan de la maquina. 

Lenguajes interpretados: a diferencia de los compilados, no requieren de un compilador para ser ejecutados sino de un intérprete. Un intérprete, actúa de manera casi idéntica a un compilador, con la salvedad de que ejecuta el programa directamente, sin necesidad de generar previamente un ejecutable. Ejemplo de lenguajes de programación interpretado son Python, PHP, Ruby, Lisp, entre otros.

Tipado dinámico: un lenguaje de tipado dinámico es aquel cuyas variables, no requieren ser definidas asignando su tipo de datos, sino que éste, se auto-asigna en tiempo de ejecución, según el valor declarado.

Multiplataforma: significa que puede ser interpretado en diversos Sistemas Operativos como GNU/Linux, Windows, Mac OS, Solaris, entre otros.

Multiparadigma: acepta diferentes paradigmas (técnicas) de programación, tales como la orientación a objetos, aspectos, la programación imperativa y funcional.

Código fuente: es un conjunto de instrucciones y órdenes lógicas, compuestos de algoritmos que se encuentran escritos en un determinado lenguaje de programación, las cuales deben ser interpretadas o compiladas, para permitir la ejecución del programa informático.

Como sería una base de datos reactiva??

Antes que nada voy a aclarara que este post tiene como objetivo solo hacer un ejercicio mental, no tiene como objetivo proponer un estándar o sugerir un cambio. Solo vamos a utilizar la imaginación y disfrutar…

Otra cosa, se que existe RDBC que básicamente ofrece un conjunto de funcionalidades reactivas para utilizar base de datos relacionales y esta bien, pero pero tiene sabor a poco. Dado que este conector tiene como objetivo simular un origen de datos reactivo que en realidad no es tan así …

En fin, una base de datos reactiva debería cumplir el manifiesto reactivo :

• Responsivos
• Resilientes
• Elásticos
• Orientados a Mensajes

No quiero detallar como implementar estos puntos, existen muchas bases de datos nosql que intentan implementarlo y a su modo lo hacen muy bien.

Dado los siguientes puntos y supongamos que los cumpla. Una base reactiva debería retornar siempre un Observer (si utilizamos RxJava, o puede ser un Flux o Mono si utilizamos spring) , por ahora no estoy agregando nada de conocimento esto es igual que R2DBC, vamos a soñar …

Lo que podríamos hacer es trasmitir datos por ejemplo : 

Preparestatement ps = con.createPreparestatement(“select * from Persona”); 

ps.subscribe( rs => System.out.println(rs.getString(“name”); ); 

  

Cada vez que se inserte un registro nuevo se imprimirá el nombre.

Le podríamos poner un delay, por ejemplo :

Preparestatement ps = con.createPreparestatement(“select * from Persona”); 

ps.delay(100);

ps.subscribe( rs => System.out.println(rs.getString(“name”); );

Si tuviéramos que hacer esto, de forma tradicional, deberíamos, revisar la base de datos cada tanto tiempo para ver si insertaron un dato nuevo. En cambio, si hubiera una base reactiva, la base nos retornará  cada 100 nanosegundos el nombre de una persona y esto no debería ser bloqueante, es decir si mientras imprimimos alguien cambia algo, no debería influir en nuestro proceso. Y si llega al final, cada vez que se inserte debería notificarnos. 

Otra cosa muy buena, sería poder suscribir a un cambio (esto desplazaría a los triggers). Deberíamos poder suscribir al cambio de un registro o de todos los registros de una tabla o la estructura de una tabla o etc. Por ejemplo vamos a suscribir un proceso que se llame cuanto eliminen un registro : 

Preparestatement ps = con.createPreparestatement(“select * from Persona p where p.id = 33”); 

ps.subscribe(“delete”, rs => System.out.println(rs.getString(“name”); );

ponele, me estoy suscribiendo y cuando se borre esta fila, la base de datos debería, notificarnos. 

Como se deben haber dado cuenta una base de datos reactiva no solo es un repositorio donde consulto datos, sino que es un sistema el cual conversa con nuestra aplicación y nos notifica de los cambios. Esto favorecería increíblemente las comunicaciones, supongamos que tenemos 2 sistemas que escriben en una base de datos, según lo que venimos razonando podríamos suscribirnos a la inserción de nuevos datos. Ect...

En fin, no conozco nada parecido, alguien conoce algo similar??

Dejo link: 

https://rdbc.io/

https://r2dbc.io/

https://www.reactivemanifesto.org/es

ReactiveX parte 2

Continuando con el post anterior...

En el modelo ReactiveX, Observable le permite tratar flujos de eventos asincrónicos con el mismo tipo de operaciones simples y componibles que se utilizan para colecciones. Lo libera de redes enredadas de devoluciones de llamada (como los callbacks) y, por lo tanto, hace un código sea más legible y menos propenso a errores.

Las técnicas como Java Futures son fáciles de usar para un solo nivel de ejecución asincrónica, pero comienzan a agregar una complejidad no trivial cuando están anidadas.

Es difícil usar Futures para componer de manera óptima flujos de ejecución asincrónicos condicionales (o imposible, ya que las latencias de cada solicitud varían en tiempo de ejecución). Esto se puede hacer, por supuesto, pero rápidamente se vuelve complicado (y por lo tanto propenso a errores) o se bloquea prematuramente en Future.get (), lo que elimina el beneficio de la ejecución asincrónica.

Los Observables de ReactiveX, están destinados a componer flujos y secuencias de datos asincrónicos.

ReactiveX Observables admite no solo la emisión de valores escalares únicos (como lo hacen los futuros), sino también secuencias de valores o incluso flujos infinitos. Observable es una única abstracción que puede usarse para cualquiera de estos casos de uso. Un Observable tiene toda la flexibilidad y elegancia asociadas a el Iterable:

ReactiveX no está sesgado hacia alguna fuente particular de concurrencia o asincronía. Los observables se pueden implementar utilizando grupos de subprocesos, bucles de eventos, I/O sin bloqueo, actores (como de Akka) o cualquier implementación que se adapte a sus necesidades, su estilo o su experiencia. El código del cliente trata todas sus interacciones con Observables como asíncronas, ya sea que su implementación subyacente sea bloqueante o no.

ReactiveX proporciona una colección de operadores con los que puede filtrar, seleccionar, transformar, combinar y componer Observables. Esto permite una ejecución y composición eficientes.

Se Puede pensar en la clase Observable como un equivalente a Iterable. Con un Iterable, el consumidor extrae valores del productor y los bloques de subprocesos hasta que lleguen esos valores. Por el contrario, con un Observable, el productor introduce valores al consumidor cuando los valores están disponibles. Este enfoque es más flexible, porque los valores pueden llegar sincrónicamente o asincrónicamente.

El tipo Observable agrega dos semánticas faltantes al patrón Observador de la Banda de los Cuatro, para que coincida con las que están disponibles en el tipo Iterable:

• la capacidad del productor de indicarle al consumidor que no hay más datos disponibles (un bucle foreach en un Iterable se completa y regresa normalmente en tal caso; un Observable llama al método onCompleted de su observador)
• la capacidad del productor de indicarle al consumidor que se ha producido un error (un Iterable genera una excepción si se produce un error durante la iteración; un Observable llama al método onError de su observador)

Con estas adiciones, ReactiveX armoniza los tipos Iterable y Observable. La única diferencia entre ellos es la dirección en la que fluyen los datos. Esto es muy importante porque ahora cualquier operación que pueda realizar en un Iterable, también puede realizarla en un Observable.

Dejo link : http://reactivex.io

ReactiveX

Hace tiempo que existe este framework y es muy raro que no haya escrito de él antes, tal vez porque se utiliza muchísimo en Angular y no soy un experto en esta tecnología. 

Pero bueno, todo llega y vamos a hablar de ReactiveX que en su pagina web dice que ReactiveX es una combinación de buenas ideas: el patrón Observer, el patrón Iterator y la programación funcional.

Patrones y programación funcional, temas que tocamos todo el tiempo en el blog, que raro que no lo vi antes o si lo vi, le reste importancia. Me paso lo mismo con typescript. 

ReactiveX sigue el patrón Reactor. Que si vamos a la wikipedia podemos leer : 

"El patrón de diseño reactor es un patrón de programación concurrente para manejar los pedidos de servicio entregados de forma concurrente a un manejador de servicio desde una o más entradas. El manejador de servicio demultiplexa los pedidos entrantes y los entrega de forma sincrónica a los manejadores de pedidos asociados."

y

"Este patrón separa completamente al código específico de la aplicación de la implementación del reactor, permitiendo que los componentes de la aplicación puedan ser divididos en módulos reutilizables. Además, la llamada síncrona de los manejadores de pedidos permite concurrencia, de grano grueso, sin agregar la complejidad de múltiples hilos en el sistema."

A la vez ReactiveX utiliza los conceptos de programación reactiva. Pero que sería la programación reactiva?? 

Esto es más fácil explicarlo con un ejemplo, supongamos que tenemos que hacer una aplicación que tiene que calcular una serie de montos, el monto 1 se ingresa, el monto 2 es un porcentaje del monto 1, el monto 3 se ingresa, el monto 4, es la suma del montos. Si programaste aplicaciones seguro que te encontraste con un problema similar. Si ingresa el monto 1 debemos refrescar todos los montos calculados y si ingresan el monto 3 solo el 4. Podemos atacamos este problema poniendo un botón que refresque los valores, el tema es que más allá que es poco práctico, no esta bueno que si modificamos el monto 3, se refresque todo (ya que es innecesario)

Excel o una hoja de calculo, la hace más fácil, cuando modificamos la celda, refresca automáticamente todos los valores que la usan esta celda para su calculo, este es el concepto de reactividad. Y es mucho más eficiente. 

Pero ahora volvamos a reactiveX que básicamente implementa lo que acabo de explicar, con diferentes conceptos : observador y suscripción. 

Por lo tanto ReactiveX es una librería para componer programas asincrónicos y basados en eventos mediante el uso de secuencias observables.

Extiende el patrón de observador para admitir secuencias de datos y/o eventos y agrega operadores que le permiten componer secuencias juntas de manera declarativa, mientras abstrae preocupaciones sobre cosas como subprocesos de bajo nivel, sincronización, seguridad de subprocesos, estructuras de datos concurrentes y no bloqueo de I/O.

ReactiveX es multilenguaje y multiplataforma, talvez la versión más utilizada es la de javascript, ya que viene con Angular y otros frameworks webs. Pero se puede utilizar en diferentes plataformas y lenguajes. 

Les dejo la lista: 

Languages

• Java: RxJava
• JavaScript: RxJS
• C#: Rx.NET
• C#(Unity): UniRx
• Scala: RxScala
• Clojure: RxClojure
• C++: RxCpp
• Lua: RxLua
• Ruby: Rx.rb
• Python: RxPY
• Go: RxGo
• Groovy: RxGroovy
• JRuby: RxJRuby
• Kotlin: RxKotlin
• Swift: RxSwift
• PHP: RxPHP
• Elixir: reaxive
• Dart: RxDart

ReactiveX for platforms and frameworks

• RxNetty
• RxAndroid
• RxCocoa

Y como me quedo muy largo el post, voy a seguir en otros...

Dejo link: 

http://reactivex.io/

https://github.com/ReactiveX

Que hay de nuevo en MongoDB 4.4 ?

MongoDB 4.4 se viene con todo!!! 

El resultado de este release es una base de datos que le permite crear aplicaciones transaccionales, operativas y analíticas más rápido que cualquier otra, para escalarlas globalmente, con la flexibilidad de definir y refinar la distribución de datos en cualquier momento a medida que evolucionan sus requisitos. Todo mientras nos brinda controles de latencia y seguridad más sofisticados.

Esta version mejora las consultas de tal modo que se puede combinar datos de múltiples colecciones para una exploración y análisis más profundos.

Expresiones de agregación personalizadas para ampliar MongoDB con nuestras propias funciones, ejecutadas como parte de una canalización de agregación.

Lectura y escritura para configurar el aislamiento en todo el clúster y las garantías de durabilidad de escritura.

Nuevos controladores Rust y Swift.

MongoDB va ser un webbinar para explicar todo esto, un tanto mejor que yo, te dejo el link:

https://www.mongodb.com/webinar/nuevas-funcionalidades-en-mongodb-44?utm_source=facebook&utm_medium=ps_paid_social&utm_campaign=jf_fb_ww_spanish_dg_flighted_whatsnewmdb45_web_dev_prospecting&utm_content=prospecting_devinterestsandjobtitles_spanish_fbig_dynamicmessaging_image_na&utm_term=prospecting_devinterestsandjobtitles_spanish_fbig&fbclid=IwAR2fsO4TSCzhcwAxl9IfIBBgar6qk8YK4GAdJdWzmJrxz0l0HOFd8i-Enfw

A la vez dejo link del release : https://www.mongodb.com/collateral/mongodb-4.4-guide

The Truffle Language Implementation Framework

Graal es un super proyecto, que en su paraguas contiene muchos subproyectos. Tal vez el más famoso es pasar a nativa una aplicación java con las imagenes, que se hizo famoso por mejorar mucho la performance de aplicaciones java. 

Pero no voy a hablar de eso ahora, si no de otro subproyecto que permite implementar cualquier lenguaje a en la maquina virtual de graal. Truffle representa un avance significativo en la tecnología de implementación de lenguaje de programación dinámicos en la maquina virtual Graal.

Para hacerla corta Truffle nos permite implementar de forma sencilla un lenguaje dinámico en la maquina virtual GraalVM, con lo cual podemos llevar un programa escrito en un lenguaje dinámico a una imagen nativa. Haciendo que sea super rapido (comparado con su versión no nativa). Y a la vez nos brinda herramientas comunes para debugear diferentes lenguajes. 

Además provee un lenguaje simple como ejemplo. SimpleLanguage es un lenguaje de demostración creado con la API Truffle. El proyecto SimpleLanguage proporciona un escaparate sobre cómo usar las API de Truffle para escribir su propio Lenguaje. Su objetivo es utilizar la mayoría de las funciones del marco Truffle disponibles y documenta su uso ampliamente con la documentación fuente en línea.

Truffle es desarrollado y mantenido por Oracle Labs y el Institute for System Software de la Universidad Johannes Kepler de Linz.

Dejo link: 

https://github.com/oracle/graal/tree/master/truffle

Relaciones en MongoDB

Es común que la información que almacenamos en nuestra base de datos esté conectada entre sí. Esto se denomina relaciones.  En una base de datos podemos encontrar distintos tipos de relaciones, mismas que clasificamos por la cantidad de información que se conecta entre sí. Por ejemplo, cuando un curso puede tener muchos vídeos, decimos que es una relación de uno a muchos, cuando un usuario puede tener un registro de configuración, podemos decir que es una relación uno a uno.

Las relaciones son un problema por sí mismas, y son aún más difíciles de comprender en el contexto de una base de datos como la de MongoDB a la que usualmente nos referimos como una base de datos no relacional.

La primer regla que tienes que considerar es que si en tu información existen muchas relaciones, quizás debas considerar utilizar un motor de bases de datos hecho para éstos casos como una base de datos relacional.

La segunda regla es que sí puedes tener relaciones en una base de datos noSQL como la de MongoDB, pero existen ciertas consideraciones importantes, para entenderlas necesitas saber que existen dos formas principales a través de las cuales puedes definir una relación en MongoDB.

Campos de referencia : este enfoque es el más parecido a las relaciones en una base de datos SQL donde se establece un campo que indica con qué otro registro está conectada la información, este es un campo especial, una llave foránea.

Dicho campo modifica el comportamiento interno de la tabla y ofrece una serie de optimizaciones y beneficios al momento de consultar las relaciones.

En una base de datos no relacional también podemos definir un campo que conecte con otro, sin embargo, este campo no es igual a una llave foránea en una base de datos relacional. Aunque a través de este campo podemos establecer y consultar relaciones, no existen modificaciones de rendimiento interno.

El mayor beneficio de usar este enfoque es que es el más sencillo de usar si tienes experiencia previa con bases de datos relacionales.

Subdocumentos : La mayor ventaja del uso de un motor no relacional como el de MongoDB, es que el rendimiento de lectura es mucho mayor en comparación con el de un motor relacional. Esta diferencia se logra a través de la eliminación de operaciones costosas, entre ellas las operaciones JOIN que nos permiten relacionar información.

La manera en que podemos solucionar este problema, respetando el enfoque no relacional del motor es a través del uso de subdocumentos.

Es importante recordar que, a diferencia del trabajo con bases de datos relacinoales, en una base de datos noSQL como la de MongoDB, no hay un proceso de normalización, en términos prácticos: la información puede estar repetida.

Este punto es clave para entender el uso de subdocumentos, donde al registrar un dato que puede estar relacionado con otro, además de registrar el documento en su colección correspondiente, podemos duplicarlo y agregarlo como un subdocumento del documento con el que está relacionado.

En un ejemplo práctico, el documento Curso podría contener una propiedad vídeos donde se guarden todos los documentos con los registros de los vídeos del curso. Si por alguna razón necesitamos listar todos los vídeos, podríamos duplicar estos documentos en una colección distinta a la de cursos.

Es importante recordar que MongoDB nos permite guardar colecciones o arreglos dentro de un documento, de hecho, existen operaciones hechas para el trabajo con arreglos.

El enfoque de los subdocumentos conserva los beneficios en rendimiento de una base de datos no relacional, por lo que es recomendable usarlos. Por otro lado, cuando la información es redundante, es decir está repetida, debemos mantenerla sincronizada en muchos puntos, si un vídeo se elimina de los subdocumentos del Curso, también debemos eliminarlo de la colección de Vídeos, por citar un ejemplo.

Rust es orientado a objeto?

Antes que nada vamos a aclarar que que un lenguaje sea orientado a objeto ni es bueno, ni es malo. Yo en lo personal opino que es mejor que un lenguaje no sea orientado a objeto, que lo soporte parcialmente. 

Rust está influenciado por muchos paradigmas de programación, incluyendo POO; por ejemplo, con características de la programación funcional. Podría decirse que los lenguajes POO comparten ciertas características comunes, a saber, objetos, encapsulación y herencia.

El libro Design Patterns: Elements of Reusable Object-Oriented Software de Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides (Addison-Wesley Professional, 1994) coloquialmente conocido como el libro The Gang of Four, es un catálogo de libros orientados a objetos patrones de diseño. Y define POO de esta manera: Los programas orientados a objetos están formados por objetos. Un objeto empaqueta tanto los datos como los procedimientos que operan en esos datos. Los procedimientos generalmente se denominan métodos u operaciones.

Usando esta definición, Rust está orientado a objetos: las estructuras y las enumeraciones tienen datos, y los bloques implementados proporcionan métodos en estructuras y enumeraciones. Aunque las estructuras y enumeraciones con métodos no se denominan objetos, proporcionan la misma funcionalidad, según la definición de objetos de la Banda de los Cuatro.

Otro aspecto comúnmente asociado con POO es la idea de encapsulamiento, lo que significa que los detalles de implementación de un objeto no son accesibles para el código que usa ese objeto. Por lo tanto, la única forma de interactuar con un objeto es a través de su API pública o interfaz; el código que usa el objeto no debería poder alcanzar las partes internas del objeto y cambiar los datos o el comportamiento directamente. Esto permite que el programador cambie y refactorice las partes internas de un objeto sin necesidad de cambiar el código que usa el objeto.

En Rust podemos usar la palabra clave pub para decidir qué módulos, tipos, funciones y métodos en nuestro código deben ser públicos, y por defecto todo lo demás es privado. Por ejemplo, podemos definir una estructura AveragedCollection que tiene un campo que contiene un vector de valores i32. La estructura también puede tener un campo que contenga el promedio de los valores en el vector:

pub struct AveragedCollection {

    list: Vec<i32>,

    average: f64,

}

La estructura está marcada como pub para que otro código pueda usarla, pero los campos dentro de la estructura permanecen privados. Esto es importante en este caso porque queremos asegurarnos de que siempre que se agregue o elimine un valor de la lista, el promedio también se actualice. Hacemos esto implementando métodos de adición, eliminación y promedio en la estructura:

impl AveragedCollection {

    pub fn add(&mut self, value: i32) {

        self.list.push(value);

        self.update_average();

    }

    pub fn remove(&mut self) -> Option<i32> {

        let result = self.list.pop();

        match result {

            Some(value) => {

                self.update_average();

                Some(value)

            }

            None => None,

        }

    }

    pub fn average(&self) -> f64 {

        self.average

    }

    fn update_average(&mut self) {

        let total: i32 = self.list.iter().sum();

        self.average = total as f64 / self.list.len() as f64;

    }

}

Los métodos públicos add, remove y average son las únicas formas de acceder o modificar datos en una instancia de AveragedCollection. Cuando se agrega un elemento a la lista usando el método add o se elimina usando el método remove, las implementaciones de cada llamada llaman al método privado update_average que también maneja la actualización del campo promedio.

Dejamos la lista y los campos promedio privados para que no haya forma de que el código externo agregue o elimine elementos al campo de la lista directamente; de lo contrario, el campo promedio podría no estar sincronizado cuando cambie la lista. El método promedio devuelve el valor en el campo promedio, permitiendo que el código externo lea el promedio pero no lo modifique.

Debido a que hemos encapsulado los detalles de implementación de la estructura AveragedCollection, podemos cambiar fácilmente aspectos, como la estructura de datos, en el futuro. Por ejemplo, podríamos usar un HashSet <i32> en lugar de un Vec <i32> para el campo de lista. Mientras las firmas de los metodos agregar, eliminar y los métodos públicos promedio permanezcan igual, no será necesario cambiar el código que usa AveragedCollection. Si hiciéramos pública la lista, este no sería necesariamente el caso: HashSet <i32> y Vec <i32> tienen diferentes métodos para agregar y eliminar elementos, por lo que el código externo probablemente tendría que cambiar si modificara la lista directamente.

Si la encapsulación es un aspecto requerido para que un lenguaje se considere orientado a objetos, entonces Rust cumple con ese requisito. La opción de usar pub o no para diferentes partes del código permite la encapsulación de los detalles de implementación.

La herencia es un mecanismo mediante el cual un objeto puede heredar de la definición de otro objeto, obteniendo así los datos y el comportamiento del objeto principal sin que tenga que definirlos nuevamente.

Si un lenguaje debe tener herencia para ser un lenguaje orientado a objetos, entonces Rust no es uno. No hay forma de definir una estructura que herede los campos de la estructura principal y las implementaciones de métodos. Sin embargo, si está acostumbrado a tener herencia en su caja de herramientas de programación, puede usar otras soluciones en Rust, dependiendo de su razón para buscar la herencia en primer lugar.

Eliges la herencia por dos razones principales: 

• Una es para la reutilización del código: puede implementar un comportamiento particular para un tipo, y la herencia le permite reutilizar esa implementación para un tipo diferente. En su lugar, puede compartir el código Rust utilizando implementaciones de métodos predeterminados de trait. 
• La otra razón para usar la herencia se relaciona con el sistema de tipos: para permitir que un tipo secundario se use en los mismos lugares que el tipo primario. Esto también se llama polimorfismo, lo que significa que puede sustituir varios objetos entre sí en tiempo de ejecución si comparten ciertas características.

Para muchas personas, el polimorfismo es sinónimo de herencia. Pero en realidad es un concepto más general que se refiere al código que puede funcionar con datos de múltiples tipos. Para la herencia, esos tipos son generalmente subclases.

En su lugar, Rust usa genéricos para abstraer sobre diferentes tipos posibles y límites de rasgos para imponer restricciones sobre lo que esos tipos deben proporcionar. Esto a veces se llama polimorfismo paramétrico acotado.

La herencia ha caído recientemente en desgracia como una solución de diseño de programación en muchos lenguajes de programación porque a menudo corre el riesgo de compartir más código del necesario. Las subclases no siempre deben compartir todas las características de su clase principal, sino que lo harán con la herencia. Esto puede hacer que el diseño de un programa sea menos flexible. También introduce la posibilidad de llamar a métodos en subclases que no tienen sentido o que causan errores porque los métodos no se aplican a la subclase. Además, algunos lenguajes solo permitirán que una subclase herede de una clase, lo que restringirá aún más la flexibilidad del diseño de un programa.

Por estas razones, Rust adopta un enfoque diferente, utilizando objetos de trait en lugar de herencia. 

Dejo link: 

https://doc.rust-lang.org/book/ch17-01-what-is-oo.html