Translate

miércoles, 14 de septiembre de 2022

Test with Scala check properties

 

I want to test this function : 

def fx(n: Int) : Long = if (n == 0 || n == 1) 1 else fx(n - 1) + fx(n - 2) 


I can write tests in a devilish way, to know if it's ok or I can use Scala check properties.


First I import the scala check :


libraryDependencies += "org.scalameta" %% "munit-scalacheck" % "0.7.29" % Test


It is better if I use the most current version in the version parameter.

Now I can write a test by property :


import munit.ScalaCheckSuite

import org.scalacheck.Prop._


class FxSuite extends ScalaCheckSuite {

  val domain: Gen[Int] = Gen.choose(3, 47) 

  property("Fx(n) is Fx(n -1) + Fx(n -2)") {

    forAll { (n: Int) =>

      fx(n) == fx(n -1) + fx(n -2)

    }

  }

}


And with this we can prove that this property of this function is fulfilled, in the code, we can see the definition of the domain, that is, with this, it will test from 3 to 47.

In conclusion, we can say that a property can be any behavioral characteristic of a method or object that should be fulfilled in any situation. Property-based testing comes from the functional programming community: Haskell's QuickCheck

Link: https://scalameta.org/munit/docs/integrations/scalacheck.html

lunes, 12 de septiembre de 2022

Properties scala tests


Tengo una función tipo : 

def fx(n: Int) : Long = if (n == 0 || n == 1) 1 else fx(n - 1) + fx(n - 2) 


Puedo escribir test de forma endemoniada, para saber si esta bien o puedo utilizar properties de Scala check. 


Primero importo scala check : 

libraryDependencies += "org.scalameta" %% "munit-scalacheck" % "0.7.29" % Test


En el parametro version, mejor si utlizo, la más actual. 

Ahora puedo escribir una property : 


import munit.ScalaCheckSuite

import org.scalacheck.Prop._


class FxSuite extends ScalaCheckSuite {

  val domain: Gen[Int] = Gen.choose(3, 47) 

  property("Fx(n) is Fx(n -1) + Fx(n -2)") {

    forAll { (n: Int) =>

      fx(n) == fx(n -1) + fx(n -2)

    }

  }

}


Y con esto podemos probar que esta propiedad de esta función se cumpla, en el código podemos ver la definición del dominio, es decir con esto va a probar desde 3 a 47. 

Como conclusión podemos decir que una propiedad puede ser cualquier característica de comportamiento de un método u objeto que debería cumplirse en cualquier situación. Pruebas basadas en propiedades viene de la comunidad de programación funcional: QuickCheck de Haskell

Dejo link : https://scalameta.org/munit/docs/integrations/scalacheck.html

sábado, 10 de septiembre de 2022

Un recuento de recursos de Scala

Platforms


Community

Coding Tools:

IDES / Programming Environments

Build Tools

Code Formatting / Linting

Free Books, Tutorials and Guides:

Non-free Books:

Advanced!:

Free Scala Courses: * Functional Programming Principles in Scala
Functional Program Design in Scala
Parallel Programming * Big Data Analysis with Scala and Spark
Introduction to Programming with Dependent Types in Scala (advanced)

Non-Free Courses:

Scala Conferences: * Functional Scala (UK/Remote)
LambdaConf (USA) * Typelevel Summits (Misc.) * Scala by the Bay (USA) * flatMap (Norway) * Scala Up North (Canada) * Scala Days (USA, Europe)
Scala World (UK)
Scala Swarm (Portugal)
Scala.io (France)
Scalar (Central Europe) * Scala Sphere (Poland)
nescala (USA)
LX SCALA (South-West Europe)
ScalaConf (Russia)

Podcasts:

Scala Jobs:

Scala Libraries:

Web Development and Microservices
ZIO HTTP * Caliban (https://github.com/ghostdogpr/caliban) * Play
Akka HTTP
Lagom * Sttp (HTTP Client) * http4s * Finch * Udash - Frontend and Backend
Lift
Scalatra
Skinny
Vert.x
Sangria - GraphQL

Web Front End (Scala.js)

Database Access

Functional Programming

Concurrency / Parallelism

Mathematics

Distributed Computing

Blockchain

Miscellaneous:

Open Source Applications written in Scala

Want your library here? Message the moderators!

Related Communities:

Blogs/Periodicals:

miércoles, 7 de septiembre de 2022

Los modificadores de visibilidad de Kotlin y Java



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

 
twitterIcon.pngyoutubeIcon.pnglinkedinIcon.png
nginx-favicon.png
Contact us
nginx-inquiries@nginx.com
1-800-915-9122
© 2022 F5, Inc. ⋅ 795 Folsom Street, San Francisco, CA 94107

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