sábado, 10 de septiembre de 2022

Los modificadores public, protected, y private en Kotlin se conservan al compilar en el código de bytes de Java. Utiliza tales declaraciones de Kotlin del código Java como si se declararan con la misma visibilidad en Java. La única excepción es una private class: está compilada en una declaración de paquete privado bajo el capó (no puede hacer que una clase sea private en Java).

Pero, puede preguntarse, ¿qué sucede con el modificador internal? No hay un análogo directo en Java. La visibilidad privada del paquete es algo totalmente diferente: un módulo generalmente consta de varios paquetes, y diferentes módulos pueden contener declaraciones del mismo paquete. Por lo tanto, un modificador internal se vuelve public en el código de bytes.

Esta correspondencia entre las declaraciones de Kotlin y sus análogos de Java (o su representación de código de bytes) explica por qué a veces puedes acceder a algo desde el código de Java a lo que no puedes acceder desde Kotlin. Por ejemplo, puede acceder a una clase internal o una declaración de nivel superior del código Java en otro módulo, o un miembro protected del código Java en el mismo paquete (similar a cómo lo hace en Java).

Pero tenga en cuenta que los nombres de los miembros internal de una clase están alterados. Técnicamente, los miembros internos se pueden usar desde Java, pero se ven feos en el código de Java. Eso ayuda a evitar conflictos inesperados en las anulaciones cuando extiende una clase de otro módulo y evita que use accidentalmente clases internal.

martes, 6 de septiembre de 2022

Modificadores de visibilidad en Kotlin

Al restringir la visibilidad de los detalles de implementación de una clase, nos aseguramos de poder cambiarlos sin el riesgo de romper el código que depende de la clase. Básicamente, los modificadores de visibilidad en Kotlin son similares a los de Java. Tiene los mismos modificadores public, protected y private. Pero la visibilidad predeterminada es diferente: si omite un modificador, la declaración se vuelve pública.

La visibilidad predeterminada en Java, paquete privado, no está presente en Kotlin. Kotlin usa paquetes solo como una forma de organizar el código en espacios de nombres; no los usa para el control de visibilidad. Como alternativa, Kotlin ofrece un nuevo modificador de visibilidad, internal, que significa “visible dentro de un módulo”. Un módulo es un conjunto de archivos Kotlin compilados juntos. Puede ser un módulo IntelliJ IDEA, un proyecto Eclipse, un proyecto Maven o Gradle, o un conjunto de archivos compilados con una invocación de una tarea Ant.

La ventaja de la visibilidad interna es que proporciona una encapsulación real para los detalles de implementación de su módulo. Con Java, la encapsulación se puede romper fácilmente, porque el código externo puede definir clases en los mismos paquetes utilizados por su código y, por lo tanto, obtener acceso a sus declaraciones privadas de paquetes.

Otra diferencia es que Kotlin permite el uso de visibilidad privada para declaraciones de nivel superior, incluidas clases, funciones y propiedades. Dichas declaraciones son visibles solo en el archivo donde se declaran. Esta es otra forma útil de ocultar los detalles de implementación de un subsistema.

public: Por defecto y se puede ver en todos lados
internal: Visible en el modulo
protected: Visible en las subclases
private: Visible solo en la clase y en el archivo.

Veamos un ejemplo. Cada línea de la función giveSpeech intenta violar las reglas de visibilidad. Se compila con un error.

internal open class TalkativeButton : Focusable {

private fun yell() = println("Hey!")

protected fun whisper() = println("Let's talk!")

}

fun TalkativeButton.giveSpeech() {

yell()

whisper()

}

Kotlin te prohíbe hacer referencia al tipo menos visible TalkativeButton (interno, en este caso) desde la función pública giveSpeech. Este es un caso de una regla general que requiere que todos los tipos usados en la lista de tipos base y parámetros de tipo de una clase, o la firma de un método, sean tan visibles como la clase o el método mismo. Esta regla garantiza que siempre tenga acceso a todos los tipos que pueda necesitar para invocar la función o ampliar una clase. Para resolver el problema, puede hacer que la función sea interna o que la clase sea pública.

Tenga en cuenta la diferencia de comportamiento del modificador protected en Java y en Kotlin. En Java, puede acceder a un miembro protegido desde el mismo paquete, pero Kotlin no lo permite. En Kotlin, las reglas de visibilidad son simples y un miembro protegido solo es visible en la clase y sus subclases. También tenga en cuenta que las funciones de extensión de una clase no obtienen acceso a sus miembros privados o protegidos.

Una diferencia más en las reglas de visibilidad entre Kotlin y Java es que una clase externa no ve miembros privados de sus clases internas (o anidadas) en Kotlin.

domingo, 4 de septiembre de 2022

Metals, una ide para scala basada en visual code

Estuve probando Metals que es un plugin de vs code y quede muy conforme.

Como es de esperar en un plugin de vs code es muy fácil su instalación y provee un sin numero de ventajas. Nada en especial, lo esperable de una ide, auto completado, navegación por el código, etc.

Veamos unas pantallas:

Dejo link : https://scalameta.org/metals/

viernes, 2 de septiembre de 2022

[O’Reilly eBook] Load Balancing in the Cloud

Migrating to software load balancing doesn’t mean you have to own and operate all the software yourself. Cloud services provide an alternative way to consume software infrastructure.

Cloud services greatly reduce the cost and hassle of provisioning redundant equipment and load balancers and enable you to handle separate network, application, and client-side loads. This ebook by author Derek DeJonghe is a practical guide to load balancing services in the cloud, including the NGINX software load balancer with AWS Network Load Balancer (AWS NLB) and global load balancing with Amazon Route 53.

Download this ebook to:

Learn how load balancing capabilities have evolved in just the past few years
Explore the features, portability, scaling, and autoscaling capabilities of the NGINX software load balancer
Understand the advantages of using AWS NLB with NGINX Plus, and learn ways to monitor AWS NLB as well as NGINX and NGINX Plus deployments
Use infrastructure management best practices to scale, secure, and monitor your application

DOWNLOAD HERE

Related Resources

NGINX: High-Performance Load Balancing
Learn the essential elements and best practices for load balancing your applications with NGINX and NGINX Plus in this on-demand webinar.

Deploying NGINX Plus and AWS Network Load Balancer
Learn about the all-active, high availability NGINX solution that takes advantage of the AWS NLB to improve the performance, reliability, and scalability of web applications.

jueves, 1 de septiembre de 2022

Mónadas en Cats parte 22

El poder de la mónada State proviene de la combinación de instancias. Los métodos map y flatMap enhebran el estado de una instancia a otra. Cada instancia individual representa una transformación de estado atómico, y su combinación representa una secuencia completa de cambios:

val step1 = State[Int, String]{ num =>

val ans = num + 1

(ans, s"Result of step1: $ans")

}

val step2 = State[Int, String]{ num =>

val ans = num * 2

(ans, s"Result of step2: $ans")

}

val both = for {

a <- step1

b <- step2

} yield (a, b)

val (state, result) = both.run(20).value

// state: Int = 42

// result: (String, String) = ("Result of step1: 21", "Result of step2 : 42")

El estado final es el resultado de aplicar ambas transformaciones en secuencia. El estado se entrelaza paso a paso, aunque no interactuamos con él.

El modelo general para usar la mónada State es representar cada paso de un cálculo como una instancia y componer los pasos usando los operadores de mónada estándar. Cats proporciona varios constructores de conveniencia para crear pasos primitivos:

• get extrae el estado como resultado;

• set actualiza el estado y devuelve unit como resultado;

• pure ignora el estado y devuelve un resultado proporcionado;

• inspect extrae el estado a través de una función de transformación;

• modify actualiza el estado utilizando una función de actualización.

val getDemo = State.get[Int]

// getDemo: State[Int, Int] = cats.data.IndexedStateT@796af713

getDemo.run(10).value

// res1: (Int, Int) = (10, 10)

val setDemo = State.set[Int](30)

// setDemo: State[Int, Unit] = cats.data.IndexedStateT@f9e66fa

setDemo.run(10).value

// res2: (Int, Unit) = (30, ())

val pureDemo = State.pure[Int, String]("Result")

// pureDemo: State[Int, String] = cats.data.IndexedStateT@439e3ee4

pureDemo.run(10).value

// res3: (Int, String) = (10, "Result")

val inspectDemo = State.inspect[Int, String](x => s"${x}!")

// inspectDemo: State[Int, String] = cats.data.IndexedStateT@77263be4

inspectDemo.run(10).value

// res4: (Int, String) = (10, "10!")

val modifyDemo = State.modify[Int](_ + 1)

// modifyDemo: State[Int, Unit] = cats.data.IndexedStateT@44ddcbfc

modifyDemo.run(10).value

// res5: (Int, Unit) = (11, ())

Podemos ensamblar estos bloques de construcción usando una comprensión. Por lo general, ignoramos el resultado de las etapas intermedias que solo representan transformaciones en el estado:

import cats.data.State

import State._

val program: State[Int, (Int, Int, Int)] = for {

a <- get[Int]

_ <- set[Int](a + 1)

b <- get[Int]

_ <- modify[Int](_ + 1)

c <- inspect[Int, Int](_ * 1000)

} yield (a, b, c)

// program: State[Int, (Int, Int, Int)] = cats.data.IndexedStateT@42c9d44a

val (state, result) = program.run(1).value

// state: Int = 3

// result: (Int, Int, Int) = (1, 2, 3000)

sábado, 27 de agosto de 2022

Enums en Scala 3

Todavia no estoy a full con todos los cambios en scala 3. Pero sin duda algo que me llamaba la atención es que scala 2 no soporte enums. Si necesitabamos algo similar teniamos que hacer lo siguiente:

object Permissions extends Enumeration {

val READ, WRITE, EXEC, NONE = Value

}

Pero esto ya no es más así y ahora tenemos enums :

enum Permissions {

case READ, WRITE, EXEC

}

Y para utilizarlo hacemos :

val read: Permissions = Permissions.READ

A la vez podemos utilizar toda la potencia de los enums como en java, por ejemplo tener argumentos :

enum PermissionsWithBits(bits: Int) {

case READ extends PermissionsWithBits(4) // binary 100

case WRITE extends PermissionsWithBits(2) // binary 010

case EXEC extends PermissionsWithBits(1) // binary 001

case NONE extends PermissionsWithBits(0)

//Podemos tener metodos :

def toHex: String = Integer.toHexString(bits) // the java way of impl

}

Como es de esperar tambien tenemos un conjunto de propiedades que nos brinda el lenguaje, similares a java :

val indexOfRead = Permissions.READ.ordinal //saber el orden

val allPermissions = Permissions.values // Todos los valores

val readPermission = Permissions.valueOf("READ") //Pasar de string a enum

viernes, 26 de agosto de 2022

Migrar a la nube garantiza agilidad y seguridad para tus datos

HBR: Migrar a la nube garantiza agilidad y seguridad para tus datos

Conoce cómo la migración puede aumentar la eficiencia operativa y, además, mejorar la experiencia de tus clientes.

Descargar informe

Hola Emanuel,

¿Ya has considerado acercar tus datos a quienes logren extraer todo su potencial? ¿Ya has pensado en desarrollar aplicaciones nativas de la nube, que proporcionen más agilidad y seguridad? Bueno, eso ya debería convertirse en una realidad.

En nuestro nuevo informe, elaborado junto con Harvard Business Review, encontrarás insights innovadores sobre la migración a la nube pública, además de información sobre las ventajas posteriores a la migración, prácticas recomendadas y datos alentadores, como:

Mayor agilidad para implementar nuevas funcionalidades en tus aplicaciones
Más flexibilidad a la hora de administrar tus datos
Más seguridad en el funcionamiento de las aplicaciones nativas de la nube

Descubre más beneficios de migrar tus datos hacia nuestras herramientas en nuestro informe realizado junto con Harvard Business Review.

Descargar informe

Nos vemos en la nube,
Equipo de Google Cloud

martes, 23 de agosto de 2022

Modificadores en Kotlin

En Kotlin, como en Java, puede declarar una clase abstracta y no se pueden crear instancias de dichas clases. Una clase abstracta generalmente contiene miembros abstractos que no tienen implementaciones y deben anularse en las subclases. Los miembros abstractos siempre están abiertos, por lo que no necesita usar un modificador de apertura explícito:

abstract class Animated {

abstract fun animate()

open fun stopAnimating() { }

fun animateTwice() { }

}

Veamos los diferentes tipos de modificadores:

final: esta por defecto en las clases y no se puede sobreescribir el método
open: no esta por defecto las clases salvo que sea un método abstracto o interfaz y se puede sobreescribir
abstract: se debe sobreescribir y puede ser usado solo en clases abstractas
override: indica que estamos sobreescribiendo un método y es open por defecto salvo que le pongamos final.

En las interfaces, no se usa final, open o abstract. Un miembro en una interfaz siempre está abierto; no puedes declararlo como definitivo o final. Es abstracto si no tiene cuerpo, pero no se requiere la palabra clave.

lunes, 22 de agosto de 2022

Sobre escribir métodos en Kotlin

Java permite crear subclases de cualquier clase y anular cualquier método, a menos que se haya marcado explícitamente con la palabra clave final. Esto a menudo es conveniente, pero también es problemático.

El llamado problema de la clase base frágil ocurre cuando las modificaciones de una clase base pueden causar un comportamiento incorrecto de las subclases porque el código modificado de la clase base ya no coincide con los supuestos en sus subclases. Si la clase no proporciona reglas exactas sobre cómo debe subclasificarse (qué métodos se supone que deben anularse y cómo), los clientes corren el riesgo de anular los métodos de una manera que el autor de la clase base no esperaba. Debido a que es imposible analizar todas las subclases, la clase base es "frágil" en el sentido de que cualquier cambio en ella puede provocar cambios inesperados en el comportamiento de las subclases.

Kotlin sigue la filosofía "diseñe y documente para herencia o, de lo contrario, prohíbalo". Mientras que las clases y los métodos de Java están abiertos de forma predeterminada, los de Kotlin son definitivos de forma predeterminada. Si desea permitir la creación de subclases de una clase, debe marcar la clase con el modificador open. Además, debe agregar el modificador open a cada propiedad o método que se pueda anular.

open class RichButton : Clickable {

fun disable() {}

open fun animate() {}

override fun click() {}

}

Si anula un miembro de una clase o interfaz base, el miembro anulado también se abrirá de forma predeterminada. Si desea cambiar esto y prohibir que las subclases de su clase anulen su implementación, puede marcar explícitamente el miembro anulado como final:

open class RichButton : Clickable {

final override fun click() {}

}

viernes, 19 de agosto de 2022

Kubernetes: El futuro de los datos está en los contenedores

Conoce una nueva forma de administrar tus datos, con seguridad y eficacia, de la mano de Google Cloud.

Descargar informe

Hola Emanuel,

¿Sabías que es posible que tú y tu empresa no estén aprovechando al máximo todo el potencial de la nube? ¿Sabías, también, que quizás estés pagando por algo que no necesitas?

En nuestro nuevo informe, descubrirás cómo la administración de datos en contenedores digitales, a través de Google Kubernetes Engine, puede mejorar el rendimiento de tus máquinas virtuales. Además, podrás conocer cómo: