Translate

viernes, 24 de julio de 2020

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: 

martes, 21 de julio de 2020

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


sábado, 18 de julio de 2020

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

ReactiveX for platforms and frameworks

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

Dejo link: 
http://reactivex.io/

viernes, 17 de julio de 2020

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:

martes, 14 de julio de 2020

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

domingo, 12 de julio de 2020

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

Libros de Java Code Geek

 

Java Design Patterns

A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into source or machine code

 
 

Android Programming Cookbook

Android is a mobile operating system developed by Google, based on the Linux kernel and designed primarily for touchscreen mobile devices such as smartphones and tablets. Android's user interface is mainly based on direct manipulation,

 

viernes, 10 de julio de 2020

Análisis usando Parsec

Vamos a construir un analizador simple usando la biblioteca Parsec en Haskell.

La función polimórfica show devuelve una representación de una estructura de datos a cadena. La forma más fácil de hacer que un tipo de datos pueda ser parámetro de show es utilizar la cláusula deriving:

    show :: Show a => a -> String
    data D = D ... deriving (Show)
    d :: D
    d = D ...
    str :: String
    str = show d 

Vamos a hacer un parse a XML

    parseShow :: String -> String
    xml = parseShow $ show res

Primero creamos un tipo de datos PersonRecord

data PersonRecord  = MkPersonRecord {
    name :: String,
    address :: Address,
    id :: Integer,
    labels :: [Label]    
} deriving (Show)

Y los tipos Address y Label se definen de la siguiente manera:

data Address = MkAddress {
    line1 :: String,
    number :: Integer,
    street :: String,
    town :: String,
    postcode :: String
} deriving (Show)

data Label = Green | Red | Blue | Yellow deriving (Show)

Derivamos Show usando la cláusula deriving. El compilador creará automáticamente la función show para este tipo de datos. Nuestro analizador analizará la salida de esta función show derivada automáticamente.

Luego creamos algunas instancias de PersonRecord:

rec1 = MkPersonRecord 
    "Wim Vanderbauwhede" 
    (MkAddress "School of Computing Science" 17 "Lilybank Gdns" "Glasgow" "G12 8QQ")
    557188
    [Green, Red]

rec2 = MkPersonRecord 
    "Jeremy Singer" 
    (MkAddress "School of Computing Science" 17 "Lilybank Gdns" "Glasgow" "G12 8QQ")
    42
    [Blue, Yellow]

Podemos probar esto muy fácilmente:

main = putStrLn $ show [rec1,rec2]    

Este programa produce el siguiente resultado:

[MkPersonRecord {name = "Wim Vanderbauwhede", address = MkAddress {line1 = "School of Computing Science", number = 17, street = "Lilybank Gdns", town = "Glasgow", postcode = "G12 8QQ"}, id = 557188, labels = [Green,Red]},
MkPersonRecord {name = "Jeremy Singer", address = MkAddress {line1 = "School of Computing Science", number = 17, street = "Lilybank Gdns", town = "Glasgow", postcode = "G12 8QQ"}, id = 42, labels = [Blue,Yellow]}]

Show muestra la información de la siguiente manera:

Listas: [... elementos separados por comas ...]
Registros: {... pares clave-valor separados por comas ...}
Strings: "..."
Tipos de datos algebraicos: nombre del tipo de variante

Creamos un módulo ShowParser que exporta una sola función parseShow:

module ShowParser ( parseShow ) where
Some boilerplate:
    import Text.ParserCombinators.Parsec
    import qualified Text.ParserCombinators.Parsec.Token as P
    import Text.ParserCombinators.Parsec.Language

El módulo Parsec.Token proporciona varios analizadores básicos. Cada uno de estos toma como argumento un lexer, generado por makeTokenParser usando una definición de lenguaje. Aquí usamos emptyDef del módulo Language.

Es conveniente crear un nombre más corto para los analizadores predefinidos que desea usar, p.

    parens = P.parens lexer
    -- and similar

La función parseShow toma el resultado de show (una cadena) y produce el correspondiente XML (también una cadena). Está compuesto por el analizador real showParser y la función run_parser que aplica el analizador a una cadena.

    parseShow :: String -> String
    parseShow = run_parser showParser

    showParser :: Parser String

    run_parser :: Parser a -> String -> a
    run_parser p str =  case parse p "" str of
        Left err -> error $ "parse error at " ++ (show err)
        Right val  -> val  


Definimos un formato XML para una estructura de datos genérica de Haskell. Utilizamos algunas funciones auxiliares para crear etiquetas XML con y sin atributos.

Header:
<?xml version="1.0" encoding="utf-8"?>
    xml_header =  "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n"
Tags:
<tag> ... </tag>
    otag t = "<"++t++">"
    ctag t = "</"++t++">"
    tag t v = concat [otag t,v,ctag t]
Attributes:
<tag attr1="..." attr2="...">
    tagAttrs :: String -> [(String,String)] -> String -> String 
    tagAttrs t attrs v = 
        concat [
            otag (unwords $ [t]++(map (\(k,v) -> concat [k,"=\"",v,"\""]) attrs))
            ,v
            ,ctag t
            ]

También utilizamos algunas funciones para unir cadenas. Del Preludio tomamos:

    concat :: [[a]] -> [a] -- join lists
    unwords :: [String] -> String -- join words using spaces

También definimos una función para unir cadenas con caracteres de nueva línea:

    joinNL :: [String] -> String -- join lines using "\n"

Veamos las diferencias entre show y nuestro parse XML : 

Lists
[ ..., ..., ... ]

XML :

<list>
<list-elt>...</list-elt>
...
</list>

    list_parser = do
        ls <- brackets $ commaSep showParser 
        return $ tag "list" $ joinNL $ map (tag "list-elt") ls

Tuples

 ( ..., ..., ... )

XML:

<tuple>
<tuple-elt>...</tuple-elt>
...
</tuple>

tuple_parser = do
    ls <- parens $ commaSep showParser 
    return $ tag "tuple" $ unwords $ map (tag "tuple-elt") ls

Record types

Rec { k=v, ... }

XML:

<record>
<elt key="k">v</elt>
...
</record>

key-value pairs: k = v -- v can be anything
record_parser = do
    ti <- type_identifier
    ls <- braces $ commaSep kvparser
    return $ tagAttrs "record" [("name",ti)] (joinNL ls)

kvparser = do
    k <- identifier
    symbol "="
    t <- showParser
    return $ tagAttrs "elt" [("key",k)] t
    
type_identifier = do
    fst <- oneOf ['A' .. 'Z']
    rest <- many alphaNum
    whiteSpace
    return $ fst:rest    

Algebraic data types

e.g. Label

XML:

<adt>Label</adt>

adt_parser = do
    ti <- type_identifier 
    return $ tag "adt" ti

Cadenas y números 

quoted_string = do
    s <- stringLiteral
    return $ "\""++s++"\""

number = do
    n <- integer
    return $ show n

Combine todos los analizadores utilizando el combinador de elección <|>.

    showParser :: Parser String 
    showParser =
        list_parser <|> -- [ ... ]
        tuple_parser <|> -- ( ... )
        try record_parser <|> -- MkRec { ... }
        adt_parser <|> -- MkADT ...
        number <|>    -- signed integer
        quoted_string <?> "Parse error"

Parsec probará todas las opciones en orden de ocurrencia.

Main program
Import the parser module

    import ShowParser (parseShow)

    rec_str =  show [rec1,rec2]    
    main = putStrLn $ parseShow rec_str

Si probamos esto :

[wim@workai HaskellParsecTutorial]$ runhaskell test_ShowParser.hs 
<?xml version="1.0" encoding="UTF-8"?>
<list><list-elt><record name="MkPersonRecord"><elt key="name">"Wim Vanderbauwhede"</elt>
<elt key="address"><record name="MkAddress"><elt key="line1">"School of Computing Science"</elt>
<elt key="number">17</elt>
<elt key="street">"Lilybank Gdns"</elt>
<elt key="town">"Glasgow"</elt>
<elt key="postcode">"G12 8QQ"</elt></record></elt>
<elt key="id">557188</elt>
<elt key="labels"><list><list-elt><adt>Green</adt></list-elt>
<list-elt><adt>Red</adt></list-elt></list></elt></record></list-elt>
<list-elt><record name="MkPersonRecord"><elt key="name">"Jeremy Singer"</elt>
<elt key="address"><record name="MkAddress"><elt key="line1">"School of Computing Science"</elt>
<elt key="number">17</elt>
<elt key="street">"Lilybank Gdns"</elt>
<elt key="town">"Glasgow"</elt>
<elt key="postcode">"G12 8QQ"</elt></record></elt>
<elt key="id">42</elt>
<elt key="labels"><list><list-elt><adt>Blue</adt></list-elt>
<list-elt><adt>Yellow</adt></list-elt></list></elt></record></list-elt></list>

 
Parsec facilita la creación de potentes analizadores de texto a partir de bloques de construcción utilizando analizadores y combinadores de analizadores predefinidos.

La estructura básica de un analizador Parsec es bastante genérica y reutilizable.

El ejemplo muestra cómo analizar texto estructurado (salida de Show) y generar un documento XML que contenga la misma información.

Dejo link: 

martes, 7 de julio de 2020

Qué es Mongoose ???


Mongoose es una librería para Node.js que nos permite escribir consultas para una base de datos de MongooDB, con características como validaciones, construcción de queries, middlewares, conversión de tipos y algunas otras, que enriquecen la funcionalidad de la base de datos.

La parte central del uso de Mongoose está en la definición de un esquema donde se indica la configuración de los documentos para una colección de MongoDB. Y aunque MongoDB es una base de datos nosql, donde los documentos se almacenan sin un esquema predefinido, el uso de un esquema te permite normalizar tu información, sin sacrificar la flexibilidad. Además, hace que la transición de sql a nosql, sea más sencilla.

En el esquema mencionado especificamos los campos que pertenecen a un documento, validaciones y configuraciones especiales para su consulta. El esquema es, además, el lugar que nos permite enriquecer de funcionalidad de nuestros documentos de mongoose, ya sea vía la definición de campos virtuales, middlewares, métodos especiales para los objetos, entre otros.

Mongoose funciona como una capa adicional sobre MongoDB a través de la cuál se implementan y automatizan muchas de las tareas habituales de trabajar con una base de datos.

Mongoose además, abre las puertas a una comunidad con la posibilidad de crear plugins que puedes usar para automatizar tareas comunes, tales como el encriptado de información, paginación, consultas adicionales, y más.

Veamos un ejemplo de uso de mongoose :

const mongoose = require('mongoose');
mongoose.connect('mongodb://localhost:27017/test', {useNewUrlParser: true, useUnifiedTopology: true});

const Cat = mongoose.model('Cat', { name: String });

const kitty = new Cat({ name: 'Zildjian' });
kitty.save().then(() => console.log('meow'));

Cuando nos referimos a la información que se almacena en una base de datos MongoDB, podemos distinguir dos conceptos importantes, colecciones y documentos. Los documentos son los registros que almacenamos, estos pueden contener propiedades.

Si comparamos con una base de datos SQL, estos documentos son similares a las filas que almacenamos en una tabla. Son similares en que representan los registros guardados, sin embargo, mientras que una tabla tiene una serie de columnas predefinidas, en un documento podemos guardar la información que necesitemos, sin una estructura definida.

Y así, mientras las filas se guardan en tablas, los documentos se guardan en colecciones. Las colecciones representan un grupo de documentos similares entre sí, de manera que si necesitas guardar usuarios, tu colección sería de usuarios y cada documento un usuario distinto.

Decimos que Mongoose es un ODM, un Object Document Mapper, lo que significa que aunque en la base de datos tenemos documentos, estos se representan como objetos cuando usamos Mongoose. La parte de mapper hace referencia a como un documento es representado por un objeto, y otro documento por un objeto distinto.

Los ODM son similares a los ORM, que usamos en bases de datos relacionales, su objetivo como el de Mongoose es el de proveer una capa adicional de abstracción entre nuestro código y el motor de la base de datos, esta abstracción permite que librerías como Mongoose extiendan la funcionalidad del motor de la base de datos y nos permiten trabajar de manera más productiva y expresiva con la base de datos.

Entre las cosas muy buenas que tiene el framework, me gusto su uso de promises , lo que ayuda a tener un código mucho más elegante. Veamos un ejemplo: 

// Using queries with promise chaining
Model.findOne({ name: 'Mr. Anderson' }).
  then(doc => Model.updateOne({ _id: doc._id }, { name: 'Neo' })).
  then(() => Model.findOne({ name: 'Neo' })).
  then(doc => console.log(doc.name)); // 'Neo'

// Using queries with async/await
const doc = await Model.findOne({ name: 'Neo' });
console.log(doc.name); // 'Neo'

Sin más dejo link: https://mongoosejs.com/

domingo, 5 de julio de 2020

El estado del ecosistema del desarrollador 2020


Como en el 2019 la empresa jetbrains  compartido los resultados de su encuesta anual. Me gusto mucho el resumen : 


Sé que me quedo chico puden verlo en la pagina original...

Python viene creciendo como un campeón pero creo que es porque esta creciendo la ciencia de datos, no lo veo que amenace otros ecosistemas. Igual es mi opinión, si no la comparten, dejen su comentario. 

¿Por qué las goroutines no son threads?


En el post anterior dije que las Fibras de java son como las goroutines y me quede pensando en esto, y como no sé bien porque es esto... me puse a investigar. 

Go está ganando una popularidad increíble. Una de las razones principales es la concurrencia simple y liviana en forma de goroutines y chanels que ofrece.

Pero porque las gorutines son livianas, simple porque no son threads. A ver, a ver, vamos por parte, porque un thread es pesado o mejor qué es un thread? 

La concurrencia ha existido desde hace mucho tiempo en forma de hilos o threads que se utilizan en casi todas las aplicaciones en estos días.  Un hilo es solo una secuencia de instrucciones que un procesador puede ejecutar independientemente. Los threads son más ligeros que el proceso, por lo que puede generar muchos de ellos.

Un servidor web generalmente está diseñado para manejar múltiples solicitudes al mismo tiempo. Y estas solicitudes normalmente no dependen unas de otras.

Por lo tanto, se puede crear un thread (o un pool de threads) y se pueden delegar cada request a un thread para lograr la concurrencia.

Los procesadores modernos pueden ejecutar varios threads a la vez (multi-threading) y también alternar entre threads para lograr paralelismo. 

Los threads pueden verse como algo liviano, dado que: 

  • Los threads comparten memoria y no necesitan crear un nuevo espacio de memoria virtual cuando se crean y, por lo tanto, no requieren un cambio de contexto MMU (unidad de administración de memoria)
  • La comunicación entre threads es más simple ya que tienen una memoria compartida, mientras que los procesos requieren varios modos de IPC (comunicaciones entre procesos) como semáforos, colas de mensajes, tuberías, etc.
Esto no siempre garantiza un mejor rendimiento que los procesos en este mundo de procesadores multinúcleo. p.ej. Linux no distingue entre hilos y procesos y ambos se denominan tareas. Cada tarea puede tener un nivel mínimo a máximo de uso compartido cuando se clona. 

Hay tres cosas que hacen que los hilos sean lentos:
  • Los hilos consumen mucha memoria debido a su gran tamaño de pila (≥ 1 MB). Por lo tanto, crear miles de hilos significa que ya necesita 1 GB de memoria.
  • Los hilos necesitan restaurar muchos registros, algunos de los cuales incluyen AVX (extensión de vector avanzada), SSE (extensión SIMD de transmisión), registros de punto flotante, contador de programa (PC), puntero de pila (SP) que perjudica el rendimiento de la aplicación.
  • La configuración de los subprocesos y el desmontaje requieren una llamada al sistema operativo para obtener recursos (como la memoria) que es lento.
Goroutines existe solo en el espacio virtual del runtime de go y no en el sistema operativo. Por lo tanto, se necesita un planificador Go Runtime que gestione su ciclo de vida. Go Runtime mantiene tres estructuras C para este propósito:
  • La estructura G: representa una rutina única con sus propiedades, como el puntero de la pila, la base de la pila, su ID, su caché y su estado.
  • La estructura M: Esto representa un hilo del sistema operativo. También contiene un puntero a la cola global de goroutines ejecutables, la goroutine actual en ejecución y la referencia al planificador
  • La estructura programada: es una estructura global y contiene las colas libres y esperando gorutinas, así como subprocesos.
Entonces, en el inicio, go runtime inicia varias rutinas para GC, planificador y código de usuario. Se crea un subproceso OS para manejar estas gorutinas. Estos hilos pueden ser como máximo iguales a GOMAXPROCS.
 
Se crea una rutina con solo 2 KB iniciales de tamaño de pila. Cada función en go ya tiene una comprobación si se necesita más pila o no y la pila se puede copiar a otra región en la memoria con el doble del tamaño original. Esto hace que la gorutina sea muy liviana en recursos.

Si una rutina se bloquea en una llamada al sistema, bloquea su hilo en ejecución. Pero otro hilo se toma de la cola de espera de Scheduler (la estructura Sched) y se usa para otras goroutines ejecutables. Sin embargo, si te comunicas usando canales in go que solo existen en el espacio virtual, el sistema operativo no bloquea el hilo. Tales goroutinas simplemente van en estado de espera y otras goroutinas ejecutables (de la estructura M) están programadas en su lugar.

Runtime de go hace una programación cooperativa, lo que significa que otra rutina solo se programará si la actual está bloqueando o terminada. Algunos de estos casos son:
  • Operaciones de envío y recepción de canales, si esas operaciones se bloquean.
  • La declaración de Go, aunque no hay garantía de que la nueva rutina se programará de inmediato.
  • Bloqueo de llamadas al sistema como operaciones de archivos y redes.
  • Después de ser detenido por un ciclo de recolección de basura.

Más allá de un montón de tecnicismos un conjunto de go rutines puede vivir en un o varios hilos y todo esta manejado por el runtime de go que los administra. 

sábado, 4 de julio de 2020

Continuations y Fibers en el Proyecto Loom


Como continuación de https://emanuelpeg.blogspot.com/2020/07/proyecto-loom.html , vamos a analizar los Continuations y Fibers. 

Las fibers o fibras son hilos livianos, programados en la máquina virtual Java, y no en el sistema operativo. Lo que las hace más rápidas y permite que usemos mejor los recursos.  

Una Continuations o Continuación es un objeto de programa que representa un cálculo que puede suspenderse y reanudarse (también, posiblemente, clonado o incluso serializado).

En esencia, la mayoría de nosotros nunca usaremos un Continuations en el código de la aplicación. La mayoría de nosotros usaremos Fibras para mejorar nuestro código. Una definición simple sería:

Fibra = Continuación + Programador

Uno de los desafíos de cualquier nuevo enfoque es cuán compatible será con el código existente. El equipo de Project Loom ha hecho un gran trabajo en este frente, y Fiber puede tomar la interfaz Runnable. Para completar, tenga en cuenta que Continuations implementa Runnable.

Las mejoras que trae Project Loom son emocionantes. Han reducido el número de subprocesos en un factor de 5. Project Loom nos permite escribir código altamente escalable con un subproceso ligero por tarea. Esto simplifica el desarrollo, ya que no necesita usar programación reactiva para escribir código escalable. Otro beneficio es que muchos códigos heredados pueden usar esta optimización sin muchos cambios. Por lo tanto podemos decir que Project Loom ofrece una capacidad similar a la de las gorutinas y permite a los programadores de Java escribir aplicaciones a escala de Internet sin programación reactiva.

jueves, 2 de julio de 2020

Proyecto Loom


Hasta hace medianamente poco el mundo era manejado mediante hilos o Thread. Era el modo por defecto para encarar aplicaciones concurrentes. Un desarrollador inicia un hilo de Java en el programa, y las tareas se asignan a este hilo para ser procesadas. Los subprocesos pueden realizar una variedad de tareas, como leer desde un archivo, escribir en una base de datos, recibir información de un usuario, etc.

Java facilita la creación de nuevos subprocesos, y los programas crean más subprocesos de los que la CPU puede procesar en paralelo. Digamos que tenemos una carretera de dos carriles (dos núcleos de una CPU), y 10 autos quieren usar la carretera al mismo tiempo. Naturalmente, esto no es posible, pero piense en cómo se maneja actualmente esta situación. Los semáforos son unidireccionales. Los semáforos permiten que un número controlado de automóviles ingresen a la carretera y hacen que el tráfico use la carretera de manera ordenada.

En computadoras, este es un planificador. El planificador asigna el hilo a un núcleo de CPU para ejecutarlo. En el mundo moderno del software, el sistema operativo cumple esta función de programar tareas (o subprocesos) en la CPU.

En Java, cada subproceso se asigna a un subproceso del sistema operativo por la JVM (casi todas las JVM hacen eso). Con los hilos superando en número a los núcleos de CPU, se asigna un montón de tiempo de CPU para programar los hilos en el núcleo. Si un subproceso pasa al estado de espera (por ejemplo, esperando que responda una llamada de la base de datos), el subproceso se marcará como en pausa y se asignará un subproceso separado al recurso de la CPU. Esto se llama cambio de contexto (aunque se requiere mucho más para hacerlo). Además, cada subproceso tiene algo de memoria asignada y el sistema operativo solo puede manejar un número limitado de subprocesos.

Considere una aplicación en la que todos los hilos están esperando que responda una base de datos. Aunque la computadora de la aplicación está esperando la base de datos, se están utilizando muchos recursos. Con el auge de las aplicaciones a escala web, este modelo de subprocesos puede convertirse en el principal cuello de botella para la aplicación.

Una solución es hacer uso de la programación reactiva. Brevemente, en lugar de crear subprocesos para cada tarea concurrente (y tareas de bloqueo), un subproceso dedicado (llamado bucle de eventos) examina todas las tareas que se asignan a subprocesos en un modelo no reactivo y procesa cada uno de ellos en el mismo Núcleo de la CPU. Por lo tanto, si una CPU tiene cuatro núcleos, puede haber múltiples bucles de eventos pero sin exceder el número de núcleos de CPU. Este enfoque resuelve el problema del cambio de contexto, pero introduce mucha complejidad en el programa mismo. Este tipo de programa también se escala mejor, que es una razón por la que la programación reactiva se ha vuelto muy popular en los últimos tiempos. Vert.x es una de esas bibliotecas que ayuda a los desarrolladores de Java a escribir código de manera reactiva.

Por lo tanto, el modelo de subprocesos por tarea es fácil de implementar pero no escalable. La programación reactiva es más escalable, pero la implementación es un poco más complicada. Un gráfico simple que representa la complejidad del programa frente a la escalabilidad del programa se vería así:



Lo que necesitamos es un punto óptimo como se menciona en el diagrama anterior (el punto verde), donde obtenemos una escala web con una complejidad mínima en la aplicación. Y ese es Project Loom. 

En lugar de asignar un subproceso del sistema operativo por subproceso Java (modelo JVM actual), Project Loom proporciona que múltiples subprocesos puedan ser ejecutados por un proceso del sistema operativo. Este enfoque proporciona un mejor uso (los subprocesos del sistema operativo siempre funcionan y no esperan) y mucho menos el cambio de contexto.

Project Loom provee concurrencia ligera de alto rendimiento y fácil de usar y nuevos modelos de programación en la plataforma Java.

El núcleo del Proyecto Loom involucra Continuations and Fibers. Pero esa historia será contada en otro post ...

Dejo link: 
https://developers.redhat.com/blog/2019/06/19/project-loom-lightweight-java-threads/

miércoles, 1 de julio de 2020

Quarkus


No dejo de escuchar de Quarkus, pero que es quarkus? 

Quarkus es un framework Java integral y nativo de Kubernetes que se creó para las compilaciones nativas y las máquinas virtuales Java (JVM), el cual permite optimizar Java, especialmente para los contenedores y convertirla en una plataforma efectiva para entornos sin servidor, de nube y de Kubernetes.

Quarkus se diseñó para integrarse con Eclipse MicroProfile, Apache Kafka, RESTEasy (JAX-RS), Hibernate ORM (JPA), Spring, Infinispan, Camel y muchos más. 

La solución de inyección de dependencias de Quarkus se basa en CDI (inyección de dependencias y contextos) e incluye un marco de extensión para ampliar las funciones y configurar, iniciar e integrar un marco en las aplicaciones.Dado que agregar una extensión es tan sencillo como incorporar una dependencia, puede optar por esa opción o utilizar las herramientas de Quarkus.

Además, proporciona la información correcta a GraalVM (una máquina virtual universal para ejecutar aplicaciones escritas con varios lenguajes, incluidos Java y JavaScript) para la compilación nativa de las aplicaciones.

Quarkus se diseñó para que fuera fácil de utilizar desde el principio, y cuenta con características que funcionan correctamente con poca o ninguna configuración.

Los desarrolladores pueden elegir los frameworks de Java que deseen para sus aplicaciones, los cuales pueden ejecutarse en modo JVM o compilarse y ejecutarse en el modo original. 

Diseñado para que los desarrolladores lo disfruten, Quarkus también incluye las siguientes funciones:
  • Programación en vivo para que los desarrolladores puedan verificar de inmediato el efecto de los cambios en el código y solucionarlos rápidamente
  • Programación imperativa y reactiva unificada con un bus de eventos integrado y gestionado
  • Configuración unificada
  • Creación sencilla de archivos ejecutables nativos
Independientemente de que una aplicación se aloje en una nube pública o en un clúster de Kubernetes alojado internamente, las características como el inicio rápido y el poco consumo de memoria son importantes para mantener bajos los costos generales del host.

Quarkus se diseñó en torno a una filosofía que prioriza los contenedores, lo que significa que se encuentra optimizado para disminuir el uso de la memoria y acelerar los tiempos de inicio, a través de lo siguiente:
  • Respaldo de primer nivel para GraalVM y SubstrateVM
  • Procesamiento de metadatos en tiempo de compilación
  • Reducción en el uso del proceso de reflexión
  • Inicio previo de imágenes nativas
Por lo tanto, Quarkus compila aplicaciones que consumen un décimo de la memoria en comparación con Java tradicional, y ofrece tiempos de inicio hasta 300 veces más rápidos, lo cual reduce significativamente el costo de los recursos de la nube.

Quarkus está diseñado para combinar a la perfección la programación imperativa conocida con la reactiva sin bloqueos durante el desarrollo de aplicaciones. 

Esta característica resulta útil tanto para los desarrolladores de Java que suelen trabajar con el modelo imperativo y no desean cambiar las cosas, como para aquellos que trabajan con un enfoque reactivo/nativo de la nube. 

El modelo de desarrollo de Quarkus se adapta a cualquier aplicación en proceso de desarrollo.

Además, es una solución efectiva para ejecutar Java en este mundo nuevo de la arquitectura sin servidor, los microservicios, los contenedores, Kubernetes, la función como servicio (FaaS) y la nube, ya que se creó teniendo en cuenta todos estos elementos. 

Dejo link : https://quarkus.io/