Translate

miércoles, 23 de septiembre de 2020

Por qué GraalVM?


Lo único malo que veo en GraslVM es el marketing que están llevando. Dado que GraalVM es un proyecto paraguas donde hay varios proyectos. Entre los que tenemos una maquina virtual más rápida, la capacidad de compilar nuestras aplicaciones de forma nativa o diferentes plataformas o ejecutar varios lenguajes. 

Lo que hace que cuando hablemos de GraalVM, estemos hablando de cosas diferentes, todo a la vez. 

GraalVM es un maquina virtual java de alto rendimiento que proporciona mejoras significativas en el rendimiento y la eficiencia de la aplicación, lo que es ideal para microservicios. Está diseñado para aplicaciones escritas en Java, JavaScript, lenguajes basados ​​en LLVM como C y C++, y otros lenguajes dinámicos. Elimina el aislamiento entre lenguajes de programación y habilita la interoperabilidad en un tiempo de ejecución compartido. Puede ejecutarse de forma independiente o en el contexto de OpenJDK, Node.js u Oracle Database.

Para las aplicaciones Java existentes, GraalVM puede proporcionar beneficios al ejecutarlas más rápido, brindar extensibilidad a través de lenguajes de secuencias de comandos o crear imágenes nativas compiladas.

GraalVM se puede ejecutar en el contexto de OpenJDK para hacer que las aplicaciones Java se ejecuten más rápido con una nueva tecnología de compilación jit. GraalVM se hace cargo de la compilación del byte code de Java en código de máquina. En particular, para otros lenguajes basados ​​en JVM como Scala, esta configuración puede lograr beneficios, como por ejemplo, lo experimentó Twitter al ejecutar GraalVM en producción.

GraalVM permite ejecutar JavaScript, R, Python, Ruby, LLVM IR y Web Assembly en el contexto de aplicaciones Java. Ofrece la capacidad de exponer las estructuras de datos de Java a esos lenguajes con filtros de acceso de host detallados. La integración es independiente del lenguaje, es decir, una integración para JavaScript también se puede utilizar en un punto posterior para ejecutar cualquier otro lenguaje basado en GraalVM. Los mecanismos de proxy permiten simular objetos dinámicos de estructuras de datos Java y exponerlos a los scripts integrados. 

La ejecución de su aplicación dentro de una máquina virtual Java conlleva costos de inicio y de espacio. GraalVM tiene una función para crear imágenes nativas para aplicaciones existentes basadas en JVM. El proceso de generación de imágenes emplea análisis estático para encontrar cualquier código accesible desde el método principal de Java y luego realiza una compilación completa con anticipación (AOT). El binario nativo resultante contiene todo el programa en forma de código máquina para su ejecución inmediata. Se puede vincular con otros programas nativos y, opcionalmente, puede incluir el compilador GraalVM para soporte de compilación complementaria Just-In-Time (JIT) para ejecutar cualquier lenguaje basado en GraalVM con alto rendimiento. Para obtener un rendimiento adicional, se pueden crear imágenes nativas con optimizaciones guiadas por perfiles recopiladas en una ejecución anterior de la aplicación. Vea un ejemplo de cómo crear imágenes nativas aquí.

GraalVM puede ejecutarse en el contexto de Node.js reemplazando V8 con GraalVM para ejecutar JavaScript. Los principales beneficios de hacerlo es habilitar aplicaciones políglotas (por ejemplo, usar bibliotecas Java, R o Python), ejecutar Node.js con configuraciones de montón grandes y recolectores de basura de Java, o usar la interoperabilidad de GraalVM para definir estructuras de datos en C / C ++ y utilícelos desde JavaScript.

GraalVM permite el uso de bibliotecas Java existentes o frameworks Java (como Spark o Flink) directamente desde Node.js. Además, se puede usar, por ejemplo, R o Python para ciencia de datos o trazar directamente desde una aplicación JavaScript.

El motor de JavaScript V8 incluido en la distribución estándar de Node.js está optimizado para las configuraciones del navegador y diseñado para funcionar de manera efectiva en escenarios de almacenamiento pequeño. Habilitamos la ejecución de Node.js con la gestión de montón de la JVM, lo que abre la posibilidad de configuraciones de montón grandes y configuraciones adecuadas de recolección de basura. El tamaño máximo de pila configurable es de 32 Gb con punteros comprimidos de 32 bits, y se admiten terabytes de pila en la configuración de puntero de 64 bits.

GraalVM permite una combinación eficiente de código nativo (por ejemplo, escrito en C / C ++) y JavaScript. Se puede acceder directamente a las estructuras de datos nativas y el compilador puede integrarse a través de cualquier límite. Esto puede ser beneficioso en un escenario donde las estructuras de datos eficientes se administran y asignan en C mientras que otras partes de la aplicación están escritas en Node.js. 

Ruby, R, Python, WebAssembly son experimentales en el ecosistema GraalVM y no se recomiendan para uso de producción en este momento, pero estamos trabajando activamente en la estabilidad y el soporte para todos los módulos para esos lenguajes. En este momento, podemos ejecutar aplicaciones más simples de Ruby, R y Python, pero no tenemos la misma compatibilidad total que proporcionamos para las aplicaciones Java y Node.js. WebAssembly actualmente implementa la especificación WebAssembly MVP (producto mínimo viable) y es el lenguaje más reciente en el entorno GraalVM.

Además de los beneficios estándar de GraalVM, como la interoperabilidad de idiomas (por ejemplo, usar Java o JavaScript desde esas aplicaciones), GraalVM puede lograr altas velocidades de 10 veces o más para esos idiomas. Nos complace ayudarlo a hacer que las aplicaciones Ruby y R existentes funcionen con GraalVM, pero todavía no podemos garantizar la compatibilidad inmediata para estos idiomas.

GraalVM está diseñado para integrarse y se puede ejecutar en bases de datos. El prototipo de Oracle Database Multilingual Engine (MLE) está disponible. Permite a los usuarios de Oracle Database ejecutar JavaScript, utilizando browserify para ejecutar módulos Node.js y escribir extensiones en Python.

GraalVM Native Image, actualmente disponible como tecnología de pioneros, funciona con muchos marcos de microservicios Java diferentes. Varios proyectos ya han aceptado esta tecnología como plataforma para sus aplicaciones: Quarkus, Micronaut, Helidon. Para estos marcos, las imágenes nativas de GraalVM reducen significativamente los requisitos de memoria en tiempo de ejecución en comparación con la ejecución en HotSpot. Creemos que la tecnología GraalVM Native Image puede convertirse en la mejor manera de implementar aplicaciones nativas en la nube.



Fomentamos el desarrollo de incrustaciones de GraalVM similares a nuestras propias integraciones en Oracle Database, OpenJDK o Node.js. Junto con socios de colaboración de investigación, ya exploramos ideas de incrustación en Spark o Flink. Encuentre una descripción sobre cómo incrustar GraalVM en su aplicación nativa o basada en JVM existente aquí.

GraalVM es un ecosistema abierto e invitamos a los sistemas de terceros a participar conectando sus propios lenguajes de programación, herramientas o plataformas.

El marco de implementación de Truffle Language permite ejecutar lenguajes de programación de manera eficiente en GraalVM. Simplifica la implementación del lenguaje al derivar automáticamente código de alto rendimiento de los intérpretes. Puede encontrar detalles sobre el enfoque en este artículo de investigación.

Implementar su propio lenguaje usando GraalVM no solo le dará un alto rendimiento. Más importante aún, permite que su lenguaje se conecte con las herramientas enriquecidas proporcionadas por el ecosistema GraalVM. Además, permite que su lenguaje se ejecute en el contexto de cualquier incrustación de GraalVM.

Se Desarrollao un lenguaje de demostración llamado "SimpleLanguage" para mostrar el uso del marco de implementación del lenguaje de GraalVM. 

GraalVM proporciona un marco para crear herramientas independientes del lenguaje como depuradores, perfiladores u otras instrumentaciones. GraalVM proporciona una forma estandarizada de expresar y ejecutar código de programa que permite la investigación en varios idiomas y el desarrollo de herramientas que se desarrollan una vez y luego se pueden aplicar a cualquier idioma.

Dejo link: 
https://www.graalvm.org/docs/why-graal/

domingo, 20 de septiembre de 2020

Las Coroutines en python


El nombre Coroutines me suenan a go, será por las goroutines? Bueno, pero veamos como funciona esto en python. 

Las corrutinas son similares a los generadores con algunas diferencias. Las principales diferencias son:

  • los generadores son productores de datos
  • las corrutinas son consumidores de datos

En primer lugar, revisemos el proceso de creación del generador. Podemos hacer generadores como este:


def fib():

    a, b = 0, 1

    while True:

        yield a

        a, b = b, a+b


Luego lo usamos comúnmente en un bucle for como este:


for i in fib():

    print(i)


 Las corrutinas consumen valores que se le envían. Un ejemplo muy básico sería una alternativa grep en Python:


def grep(pattern):

    print("Searching for", pattern)

    while True:

        line = (yield)

        if pattern in line:

            print(line)


yield en este caso no contiene ningún valor, sino que le proporcionamos valores externamente. Suministramos valores mediante el método .send(). Aquí hay un ejemplo:


search = grep('coroutine')

next(search)

# Output: Searching for coroutine

search.send("I love you")

search.send("Don't you love me?")

search.send("I love coroutines instead!")

# Output: I love coroutines instead!


Es necesario para iniciar la corrutina, correr next. Al igual que los generadores, las corrutinas no inician la función de inmediato. En su lugar, lo ejecutan en respuesta a los métodos __next __ () y .send (). Por lo tanto, debe ejecutar next () para que la ejecución avance a la expresión yield.

Podemos cerrar una corrutina llamando al método .close ():

search = grep('coroutine')

# ...

search.close()

Y listo!!

Dejo link: https://book.pythontips.com/en/latest/coroutines.html

sábado, 19 de septiembre de 2020

Singleton Anti-Pattern

Singleton es un patrón muy muy enseñado, y creo que es solo porque es fácil de implementar. 


Pero este patrón nació en entornos no concurrentes y en procesos de desarrollo que no se utilizaba unit test. Por lo tanto, en ese entorno era bueno, pero el tiempo ha pasado y cada vez más todos los entornos son concurrentes y es imprescindible tener unit test en nuestro software. Lo que ha convertido al amigo Singleton en un Anti-Pattern. 

Por que no deberíamos utilizar Singleton: 

  • Que es singleton: El mayor problema con el patrón singleton (y por qué es, por lo tanto, un antipatrón de diseño en lugar de un patrón de diseño) es que la suposición de que alguna vez habrá solo una instancia a menudo se rompe durante la vida útil de un proyecto, y este patrón se estructura el código de una manera que requiere un esfuerzo muy significativo para refactorizar cuando esta suposición es inevitablemente incorrecta. Es decir, muchos casos demuestran la necesidad de garantizar que el código sea flexible en caso de que la suposición de unicidad resulte falsa, y este patrón hace que el código sea inflexible.
  • Dificulta las pruebas: Además de hacer que el código sea inflexible, el patrón singleton también dificulta mucho la prueba del código. Esto se debe a que el patrón singleton introduce una dependencia a través de un canal lateral que no se da explícitamente como parámetro a los constructores u otras funciones que lo utilizan. Incluso en el caso de que este canal lateral pueda ser reemplazado (y a menudo hacerlo es muy difícil), la necesidad de hacerlo es menos obvia y hace que las pruebas sean muy difíciles de entender. El otro problema es que se muy difícil de hacer un mock de este objeto. 
  • No es seguro a nivel de hilos o es un cuello de botella: Incluso ignorando los problemas anteriores (que son, creo, las razones más fuertes para evitar este patrón), el patrón singleton es especialmente difícil de implementar correctamente cuando se tiene en cuenta el subproceso múltiple. la aplicación requiere que el objeto singleton, en sí mismo, sea seguro para subprocesos; sin embargo, mover la propiedad singleton fuera del objeto permite crear implementaciones alternativas, algunas de las cuales son seguras para subprocesos y otras que no lo son, lo que permite a las aplicaciones que no son multiproceso crear instancias de una versión del objeto que no tiene la sobrecarga de la sincronización de subprocesos al tiempo que permite que las aplicaciones multiproceso creen una instancia de la versión segura para subprocesos.

Si tienen más curiosidad dejo link: https://www.michaelsafyan.com/tech/design/patterns/singleton

viernes, 18 de septiembre de 2020

Corre Groovy en tu browser con Grooscript


Si existe Scala.js por que no puede existir un Groovy que corra en el browser. Y existe y se llama Grooscript. 

Grooscript es todo lo que has soñado y si no lo soñaste te cuento. Este es un lenguaje muy similar a groovy que compila a javascript. 

Y se puede utilizar en framework como node, veamos un ejemplo: 

//DSL using Node.js with Express

server {
    get('/') {
        render 'Hello World!'
    }
    get('/spanish') {
        render 'Hola Mundo!'
    }
    get('/salute/:name') {
        render "Hello ${req.params.name}!"
    }
}.start(3000)


Para poder utilizarlo debemos instalar node y groovy y luego instalar con npm grooscript : 

> npm install grooscript


Luego de instalada podemos crear nuestros archivos groovy, por ejemplo : 

class Hello {

  def methodMissing(String name, args) {

    println "Hello ${name}!"

  }

}

def hello = new Hello()

hello.Groovy()

hello.Javascript()

hello.grooscript()


Luego tenemos que compilar este script groovy a javascript : 

 @Grab('org.grooscript:grooscript:1.2.2')

import org.grooscript.GrooScript


def conversionOptions = [:]

conversionOptions['initialText'] = "var gs = require('grooscript');"

GrooScript.convert 'source.groovy', '.', conversionOptions


luego con este último script, compilamos el script inicial de la siguiente forma : 

groovy convert.groovy

con este paso obtenemos el source.js, que podemos ejecutarlo así  : 

> node source.js

Hello Groovy!

Hello Javascript!

Hello grooscript!

Y listo, se ve que esta tecnología esta en pañales pero agárrate typescript!!



lunes, 14 de septiembre de 2020

for/else de python


Hay muchas cosas que no sé y llego tarde, una es esta. Existe en python el for/else. 

Como es esto? La cláusula else se ejecuta después de que el ciclo se completa normalmente. Esto significa que el bucle no encontró una declaración de interrupción o break.

Por ejemplo : 

 for item in container:

    if search_something(item):

        # Found it!

        process(item)

        break

else:

    # Didn't find anything..

    not_found_in_container()

Esto nos libra de tener una variable bandera para saber si salio del for por el break o porque completo el for. Muy útil, muy fácil, y listo!


domingo, 13 de septiembre de 2020

Rosetta code


Encontré una pagina, que hace siglos que esta en Internet pero yo no la había visto antes, y como para mi es noticia. La quiero compartir con ustedes. 

Es una pagina donde hay código de muchos lenguajes, casi todos.  La idea es presentar soluciones a la misma tarea en tantos lenguajes diferentes como sea posible, demostrando cómo los lenguajes son similares y diferentes, y ayudar a una persona con una base en un enfoque de un problema para aprender otro. Rosetta Code tiene actualmente 1.067 tareas, 206 borradores de tareas y 800 lenguajes.

Dejo link: http://www.rosettacode.org/wiki/Rosetta_Code

sábado, 12 de septiembre de 2020

Utilizar valores implícitos atenta contra la legibilidad del código?


El Zen de Python dice : Explicit is better than implicit o Explícito es mejor que implícito. Cosa que me ha dejado pensando porque no aplica siempre. Por ejemplo: 

boolean b;

if (b == true) then: ...

b por defecto es false, pero no se lo estamos diciendo, en este caso yo particularmente prefiero ser explicito, es decir dejar claro cual es el valor de la variable: 

boolean b = false

pero me choca y me disgusta (es que ya estoy viejo) el if , es como que el programador no tiene en cuenta que b es un dato. Y ese dato lo podemos comprobar, prefiero: 

if (b) then: ...

Pero hay cosas implicitas en los lenguajes que a mi modo de ver las cosas, atentan contra la legibilidad. 

El caso más fácil de ejemplificar es que valores de otros tipos sean false o true, eso hace más fácil a vida del experto pero sin duda no deja tan clara las cosas. Por ejemplo: 

if (typeof(some_variable) != 'undefined' && some_variable != null)

{

    // Do something with some_variable

}

por : 

if (some_variable)

{

    // Do something with some_variable

}

Claro que la ultima es más corto, pero que diablos hace? Si sabes javascript es fácil, pero lo puede entender todo el mundo? 

Que opinan?

Feliz Día!!


Dice la wikipedia: El Día de los Programadores es un día festivo profesional oficial en algunos países del mundo.[¿cuál?] Se celebra el 256º día de cada año (13 de septiembre durante los años normales y el 12 de septiembre durante los bisiestos)

Por lo tanto, Feliz día!!!!

jueves, 10 de septiembre de 2020

Libros gratuitos de Java Code Geeks

 

Download IT Guides!

 

Microservices for Java Developers

Microservices are a software development technique – a variant of the service-oriented architecture (SOA) structural style – that arranges an application as a collection of loosely...

 
 

JMeter Tutorial

JMeter is an application that offers several possibilities to configure and execute load, performance and stress tests using different technologies and protocols. It allows simulating...

 
 

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...

 
 

Elasticsearch Tutorial

Elasticsearch is a search engine based on Lucene. It provides a distributed, multitenant-capable full-text search engine with an HTTP web interface and schema-free JSON documents....

 

miércoles, 9 de septiembre de 2020

Por qué AdoptOpenJDK te pregunta sobre utilizar OpenJ9 o HotSpot?

Una JDK debe proporcionar :

  • Un compilador de lenguaje de programación Java para crear archivos de código de bytes de Java .class a partir de sus archivos de código fuente .java.
  • Una máquina virtual de Java (JVM) que puede, en tiempo de ejecución, interpretar y / o compilar esos archivos de código de bytes de Java, convirtiéndolos en código ejecutable que puede ejecutarse en los núcleos de la computadora host utilizando el conjunto de instrucciones nativo de esa CPU.
  • Un entorno de ejecución que conecta las aplicaciones Java con los recursos de la máquina host, como el sistema de archivos y la instalación de red.
  • Un conjunto obligatorio de bibliotecas de clases de Java (java.util, java.time, etc.).
  • Una implementación de Java tiene la opción de proporcionar un compilador / optimizador Just-In-Time (JIT) como parte de la JVM. El proyecto OpenJDK incluye código fuente para HotSpot JIT.

Las personas que proporcionan compilaciones o instaladores para la plataforma Java son libres de usar HotSpot o de elegir otra tecnología de compilación JIT. OpenJ9 en uno de esos JIT alternativos, desarrollado en IBM, ahora de código abierto a través de la Fundación Eclipse, y se proporciona de forma gratuita. En el pasado, otro JIT alternativo era JRockit, propiedad de Oracle. Partes de JRockit se han fusionado en la versión actual de HotSpot.


El proyecto AdoptOpenJDK ofrece la opción entre el motor HotSpot proporcionado por Oracle a través del proyecto OpenJDK o el motor OpenJ9 alternativo proporcionado por Eclipse Foundation.

Con cualquiera de las opciones, obtiene las mismas bibliotecas de clases de la base de código OpenJDK, las mismas herramientas que incluyen Mission Control y Flight Recorder de OpenJDK, y las mismas utilidades de OpenJDK. Solo el JIT / JVM es diferente si elige HotSpot u OpenJ9.


AdoptOpenJDK es sólo uno de los varios proveedores que ofrecen distribuciones de tecnología Java como binarios / instaladores. La mayoría de estos se basan principalmente, si no completamente, en las versiones del código fuente del proyecto OpenJDK. A continuación, se muestra un diagrama de flujo que muestra los distintos proveedores.



Y aquí hay una lista de posibles motivaciones a considerar al seleccionar un proveedor.



domingo, 6 de septiembre de 2020

Agda


 Agda es un lenguaje funcional con dependently typed. Pero que es dependently typed? 

Te lo explico en este post : https://emanuelpeg.blogspot.com/2016/03/dependently-typed-languages.html

Pero si te da fiaca ir, te cuento: 

Dependent type es un concepto de la programación pero también de la lógica; Dependent type es un tipo que depende de un valor. En la programación funcional se utiliza para prevenir errores, al permitir un sistema de tipo extensivo.

Dependent type añaden complejidad a un sistema de tipos. Es decir, para saber un tipo en algunos casos se deben realizar cálculos o ejecutar sentencias; esto hace bastante complejo el proceso de chequeo de tipos; y en algunos casos imposible. Pero algunos aspectos del comportamiento de un programa se pueden especificar con precisión en el tipo.

Que ventajas trae Dependently typed:

  • Se pueden encontrar más errores en tiempo de compilación
  • Editores que nos ayuden más
  • Puede checkear que los elementos de tu programa estén bien.
Agda se basa en la teoría de tipos intuicionista, un sistema fundamental para las matemáticas constructivas desarrollado por el lógico sueco Per Martin-Löf. Tiene muchas similitudes con otros lenguajes basados en dependently typed, como Coq, Epigram, Matita y NuPRL.

Agda es de código abierto y disfruta de las contribuciones de muchos autores. El centro del desarrollo de Agda es el grupo Programming Logic en Chalmers y la Universidad de Gotemburgo. Los principales desarrolladores son Ulf Norell, Nils Anders Danielsson, Andreas Abel y Jesper Cockx.

Vamos un pequeño ejemplo, definimos un tipo y luego la suma : 

data Nat : Set where
zero : Nat
suc : Nat -> Nat

_+_ : Nat -> Nat -> Nat
zero + m = m
suc n + m = suc (n + m)

y multiplicar : 

_*_ : Nat -> Nat -> Nat
zero * m = zero
suc n * m = m + n * m

Dejo link : 

Manejo de errores en Go vs Rust



Sin duda alguna si hablamos de lenguajes de sistemas los que están haciendo más ruido hoy en día son Go y Rust. 

Son lenguajes que se pensaron para la performance y son de más bajo nivel que Java o Python. Pero a pesar de eso son lenguajes modernos que tienen una especial visión de los errores. 

Go utiliza valores de error para indicar un estado anormal. Por ejemplo, la función os.Open devuelve un valor de error que no es nulo cuando no puede abrir un archivo.

func Open(name string) (file *File, err error)

Por lo tanto si queremos ver si ocurrio un error podemos hacer : 

f, err := os.Open("filename.ext")

if err != nil {

    log.Fatal(err)

}

Lo interesante de esta visión es que nos alejamos del pensamiento o la filosofía de Java en el que el error es un valor especial que debe ser lanzado o tratado, y no es necesario utilizar secuencias try-catch. 

En cambio Rust tiene una visión más funcional, maneja los errores como Haskell. Es decir, devuelve algo llamado Result.

El tipo Result <T, E> es una enumeración que tiene dos variantes: Ok (T) para valor exitoso o Err (E) para valor de error:

enum Result<T, E> {

   Ok(T),

   Err(E),

}

Devolver errores en lugar de lanzarlos es un cambio de paradigma en el manejo de errores y es similar a lo que hace Go, pero en este caso me gusta mucho más porque funciona muy bien con pattern matching pero vamos de a poco.

Si necesitamos ignorar el manejo de errores, no sé porque estamos seguros que no va a pasar o solo porque somos inconscientes podemos utilizar unwrap, por ejemplo : 

use std::fs;

fn main() {

  let content = fs::read_to_string("./Cargo.toml").unwrap();

  println!("{}", content)

}

Aunque sabemos que el archivo estaría presente, el compilador no tiene forma de saberlo. Entonces usamos unwrap para decirle al compilador que confíe en nosotros y devuelva el valor. Si la función read_to_string devuelve un valor Ok (), desenvolver obtendrá el contenido y lo asignará a la variable de contenido. Si devuelve un error, el programa entrará en pánico. Panic termina el programa o sale del hilo actual. (en otro post voy a hablar de panic!) 

expect es lo mismo que unwrap pero nos permite agregar un mensaje de error adicional.

use std::fs;

fn main() {

  let content = fs::read_to_string("./Cargo.toml").expect("Can't read Cargo.toml");

  println!("{}", content)

}

También tenemos varios métodos que nos permiten hacer algo si sale un error cuando desenvolvemos un valor, como unwrap_or_else, unwrap_or_default, veamos un ejemplo : 

use std::env;

fn main() {

  let port = env::var("PORT").unwrap_or("3000".to_string());

  println!("{}", port);

}

Muy elegante, me gusta mucho en Go deberíamos hacer : 

port, ok := os.LookupEnv("PORT")

if !ok {

port = 3000

En Rust tambien podemos utilizar pattern matching que lo hace un tanto más fácil de leer, veamos un ejemplo:

fn main() {
  match fxParaLeerData() {
    Ok(data) => println!("pudimos leer {}!!", data),
    Err(e) => eprintln!("Hubo un problema  {}", e),
  }
}

La verdad que me gusta mucho más el concepto de try-catch es como que separa más la lógica de el manejo de problemas o errores. Más allá de esta opinión creo que una visión más elegante fue la que tomo Rust. Por favor dejen su opinión. 

Hasta acá llego el post pero seguro que va a ver parte 2 ... 


jueves, 3 de septiembre de 2020

Rust 1.46.0 fue liberada


La versión 1.46.0 de Rust fue liberada. Esta versión trae mejoras a las habilidades de escritura const fn, estabiliza el # [track_caller] que promete un mejor manejo de errores y múltiples adiciones o estabilizaciones a las bibliotecas estándar. La lista completa de características está aquí: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1460-2020-08-27

Las características del lenguaje central que se pueden usar en contextos estáticos se acaban de ampliar, por lo que a partir de esta versión se pueden usar operadores condicionales (if, if let y match), bucles (while, while let y loop) y operadores bit a bit (&& y | |) en contextos estáticos. También es posible lanzar y coaccionar un corte o incluso usar mem :: transmute. Aunque estas características de lenguaje no son nuevas, su principal beneficio está en el espacio de rendimiento, por ejemplo, durante un ejercicio en Microsoft, trajo una mejora de 40 veces en los enlaces de Microsoft WinRT para Rust en comparación con la implementación de C ++. Siguiendo la misma idea, también el método std :: mem :: olvide ahora es una constante fn.

Ahora pueden usar enlaces dinámicos para las plataformas Apple iOS y tvOS. Esto es posible al permitir como target cdylib en las plataformas Apple iOS y tvOS.

También en el lado de la estabilidad, en el lado de la API, Option :: zip y vec :: Drain :: as_slice se estabilizaron en la versión actual. Mientras que en el lado de las bibliotecas, también ocurrieron cambios, entre los cuales String implementa From <char> que permite la escritura de la siguiente construcción:

fn char_to_string() -> String {

  'a'.into()

}

Dejo link:

https://blog.rust-lang.org/2020/08/27/Rust-1.46.0.html

miércoles, 2 de septiembre de 2020

Que es Inyección de dependencia y como funciona en Asp.net con .net core?


Empecemos por el principio, .net Core es un Framework de código abierto creado por Microsoft, que nos proporciona herramientas para el desarrollo de aplicaciones multiplataforma lo que significa que podemos desarrollar y ejecutar una aplicación en varios sistemas operativos, como Linux, Windows, iOS. Se pueden desarrollar en .net Core: aplicaciones de escritorio, aplicaciones web, aplicaciones móviles, juegos, inteligencia artificial, etc.

ASP.NET Core es un marco de trabajo para desarrollar aplicaciones web multiplataforma compilado con .Net Core.

Una técnica muy utilizada en java y tambien en .net es la inyección de dependencias que es una técnica en la que un objeto suministra las dependencias de otro. Está técnica nos permite evitar la creación de objetos, para lograr legibilidad y reuso de código.

Cualquier aplicación no trivial está formada por dos o más clases que colaboran entre sí para realizar alguna lógica. Tradicionalmente cada objeto se hacía cargo de obtener sus propias referencias a los objetos a los cuales colaboraba (sus dependencias). Esto lleva a código acoplado y difícil de probar.

Cuando se aplica inyección de dependencia le decimos a una entidad externa que provea las dependencias a los objetos. Esto nos resuelve el problema del acoplamiento.

El acoplamiento es un mal necesario ya que sin él los objetos no podrían interactuar para resolver problemas, pero cuan menor sea el acoplamiento es más reutilizable, comprobable y flexible.

La ventaja clave de inyección de dependencia es el acoplamiento débil. Si un objeto solo conoce sus dependencias mediante su interfaz (no su implementación o como fueron definidos) entonces la dependencia puede intercambiarse con una implementación diferente sin que el objeto dependiente sepa la diferencia.

La inyección de dependencias es una de las maneras de implementar Inversión de Control o IoC.

Netcore posee soporte nativo para Inyección de Dependencias, el cual es utilizado en Asp.net

Para injectar objetos, debemos utilizar los constructores de la clase. En los constructores indicamos que debe injectar el contenedor de .net, por ejemplo :

   public class EjemploService

    {                

        public EjemploService(UnRepositorio repository)

        {

            ...

        }

    }

En el ejemplo se puede ver que se esta inyectando un UnRepositorio al servicio EjemploService y el contenedor puede saber que inyectar, dado que busca en la clase Startup que instancia debe injectar según el tipo. Esto se indica con esta linea :

services.AddTransient<UnRepositorio, UnRepositorioImpl>();

En la clase Startup.

Algo que no dije es que UnRepositorio debe ser una interfaz.De esta forma desacopamos la implementación. 

La clase Startup esta contenida en el archivo Startup.cs en la carpeta raíz del proyecto.

Las aplicaciones ASP.NET Core debe incluir esta clase. Como su nombre indica, se ejecuta primero cuando se inicia la aplicación. Y tiene como objetivo brindar un conjunto de configuraciones para que nuestra aplicación pueda funcionar.

El método ConfigureServices es un lugar donde se registran las clases dependientes en el contenedor IoC o injección de dependencia. Después de registrar la clase dependiente, se puede usar en cualquier lugar de la aplicación. Solo necesita incluirlo en el parámetro del constructor de una clase donde desea usarlo y el contenedor de IoC lo inyectará automáticamente.

El método Configure es un lugar donde puede configurar la canalización de solicitudes de aplicaciones para su aplicación utilizando la instancia IApplicationBuilder que proporciona el contenedor IoC.


viernes, 28 de agosto de 2020

Que lenguaje de programación debo aprender?


Este es un post de opinión no me apoyo en ninguna encuesta o nada, es opinión de lo que voy leyendo. A la vez ya hice post similares pero lo actualice a 2020. 

Dicho esto, me pongo a opinar. Si queres aprender un lenguaje de programación, lo que primero que debes hacer es pensar a que te queres dedicar. Dado que la programación tiene varios objetivos y si bien hay lenguajes que son buenos para todo pero no son populares en todo, por lo tanto, dependiendo a que te queres dedicar es el lenguaje que debes aprender. 

Voy a listar temas y poniendo los lenguajes. 

Backend : Java, C#, Kotlin, Scala, Groovy, PHP, Python, Haskell, Go, SQL, Ruby

Frontend : Javascript, Typescript, Elm

Mobile : Java, Kotlin, C#, Dart

Data science : SQL, Python, Julia, R

Sistemas (bajo nivel) : Rust, Go, C

Sistemas concurrentes : Rust, Go, Scala, Haskell, Erlang, Elixir

Juegos : C, C++, Rust, Go, Lua, Elm, C#