Microservices Up and Running

 

EBOOK Hi Emanuel, Microservices architectures offer faster functional updates, better scalability, and cleaner, evolvable system designs. But implementing your first microservices architecture is difficult. This eBook, compliments of NGINX and O'Reilly Media, provides step-by-step guidance for building an effective microservices architecture. In this eBook you will learn: How to design an effective and explicit microservices system end-to-end About forming teams, assigning responsibilities, and working together How to establish the right functional boundaries between the microservices that make up an application About building a simple yet powerful CI/CD pipeline for infrastructure changes Download Now This email was sent by: F5 NGINX 801 5th Ave, Seattle, WA 98119 | (206) 272-5555 | nginx.com ©2022 F5, Inc. All rights reserved. Policies | Privacy | Trademarks | Preference Center | Unsubscribe

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

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

Un recuento de recursos de Scala

• Official Website
  
• Try Scala Online with
  Scastie or ScalaFiddle
  
• Contribute to Scala
• Scala Center (not-for-profit scala org)
• Documentation
  
• StackOverflow Recent Questions
  

Platforms

• JVM (main language site)
  
• Scala.js
  
• Scala Native

Community

• Official Scala Chat Server (Discord)
  
• Official Scala User Forum
  
• Official Scala Contributors Forum
  
• Ukrainian Scala Community In Telegram

Coding Tools:

IDES / Programming Environments

• IntelliJ with Scala Plugin
• Ammonite Scripting, REPL, System shell
  
• Metals (VSCode, Sublime, etc)
• ScalaIDE (Eclipse Plugin)

Build Tools

• SBT (Most used in community)
  
• Bloop
• Mill
• Maven
  
• Gradle (from Java ecosystem)

Code Formatting / Linting

• Scalafmt
  
• Scalafix (Linter/Refactorer)
  
• ZIO IntelliJ
• Wartremover

Free Books, Tutorials and Guides:

• Scala Exercises
• Twitter's Scala School
• Scala Tutorial
• Programming in Scala, First Edition
  
• Hands-on Scala.js
  
• Underscore.io books (many free books)
  
• 47Degrees Scala Exercises
  
• The Neophyte's Guide to Scala

Non-free Books:

• Programming in Scala, Third Edition
  
• Programming Scala (O'Reilley)
  
• Official book recommendations

Advanced!:

• Functional Programming in Scala (Manning)
  
• Mastering Advanced Scala
• Zionomicon

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 3 and Functional Programming Essentials

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:

• Corecursive
  
• Scala Love
  

Scala Jobs:

• Functional Jobs
• Lightbend Customer Postings
  
• Functional Works
  
• Scala Jobs

Scala Libraries:

• Scaladex: The Scala Library Index

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)

• ScalaJS-React
  
• Binding.scala
  
• React4s
  
• Slink
  

Database Access

• Anorm (RDBMS)
• ScalikeJDBC (RDBMS)
• Doobie (RDBMS)
• Quill (RDBMS + Cassandra)
• Phantom (Cassandra)
• ReactiveMongo (MongoDB)
• Elastic4s (ElasticSearch)
• Slick (RDBMS)

Functional Programming

• Typelevel
  large functional programming community
• ZIO - Solutions powered by Functional Programming
• Shapeless
• Cats
  

Concurrency / Parallelism

• Akka
  
• ZIO
• Monix

Mathematics

• Spire

Distributed Computing

• Apache Spark
  
• Apache Flink
  
• Apache Gearpump
  
• Apache Kafka
  

Blockchain

• Bitcoin-S

Miscellaneous:

• Scodec

Open Source Applications written in Scala

• Lichess (chess)
  
• Graphcool (GraphQL)
  
• Apache Kafka
  
• Gitbucket
  
• Crypto Coin Alerts
  
• Ore
  
• Hepek - Static Site Generator
  

Want your library here? Message the moderators!

Related Communities:

• /r/ScalaStudyGroup
  
• /r/ScalaConferenceVideos
• /r/Akka
  
• /r/ApacheSpark
  
• /r/ApacheKafka
  

Blogs/Periodicals:

• Official blog
• Rock the JVM
• Lihaoyi
• ZIO News
• SoftwareMill
  
• tpolecat
  
• Typelevel
  
• David Barri aka /u/japgolly
  
• Scala Times (weekly news)

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.

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.

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/

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

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

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)