Bueno podes utilizar paiza. Que es una pagina donde podemos correr código en diferentes lenguajes:
Bash, C, C#, C++, Clojure, Cobol, CoffeeScript, D, Elixir, Erlang, F#, Go, Haskell, Java, JavaScript, Kotlin, MySQL, Nadesiko, Objective-C, Perl, PHP, Python2, Python3, R, Ruby, Rust, Scala, Scheme, Swift, TypeScript, VB
Dejo link: https://paiza.io/
.jpg)
Uno de los requerimientos no funcionales es que se pueda agregar una serie nueva fácilmente.
Vamos a desarrollar este juego en Clojure:
Empecemos desarrollo de la serie, la serie tiene como responsabilidad generarse y si lo hacemos de esta manera podemos utilizar la potencia del polimorfismo, para que no quede acoplado la generación de la serie con el desarrollo del juego:
(ns secuencia-clojure.core
(:gen-class))
(import '(java.util Scanner))
(def scan (Scanner. *in*))
(defn generateSecEven []
(def seed (rand-int 30))
(for [x (range seed (+ seed 4))] (* x 2))
)
(defn generateSecOdd []
(def seed (rand-int 30))
(for [x (range seed (+ seed 4))] (+ (* x 2) 1))
)
(defn generateSecFibo []
(def seed (rand-int 30))
(def seed2 (* seed 2))
(def seed3 (* seed 3))
(list seed seed seed2 seed3)
)
Bueno, todo tiene un principio y vamos a empezar a crear un proyectito de consola con Clojure y Leiningen
$ lein new app my-project
Fijate vos que si queres utilizar nombre de proyecto con mayuscula, no te deja, ojo ahi.
Ahora vamos a ejecutarlo :
$ lein run
podemos generar un jar con :
$ lein jar
Si estamos trabajando en un proyecto de aplicación, Leiningen nos brinda la posibilidad de construir lo que se llama un uberjar. Este es un archivo JAR que contiene el proyecto en sí y todas las dependencias y está configurado para permitir que se ejecute tal cual.
$ lein uberjar
Compiling secuencia-clojure.core
$ java -jar target/uberjar/el-jar-standalone.jar
Pedestal es un framework web desarrollado en Clojure que se enfoca en la construcción de aplicaciones web escalables y de alto rendimiento. A diferencia de algunos otros frameworks web, Pedestal no se basa en el paradigma de controladores y vistas, sino que se centra en la manipulación de datos y el flujo de información. Esto lo convierte en una opción ideal para aplicaciones modernas que requieren manejo eficiente de datos en tiempo real.
Las caracteristicas claves son:
La integración de Pedestal con Clojure es perfectamente natural, ya que ambos comparten la misma plataforma de ejecución (JVM) y una filosofía similar centrada en la simplicidad y la eficiencia. Al aprovechar las capacidades funcionales de Clojure, Pedestal puede manejar de manera elegante la manipulación de datos y el flujo de información en las aplicaciones web.
Vamos a hacer un hola mundo, para ello vamos a crear el proyecto con Leiningen :
lein new pedestal-app hello-world
Dejo link: https://github.com/pedestal/pedestal
Me gustaría contar un poco mi evolución y mis altibajos para que la gente que sabe me aconseje y los que no saben puedan aprender de mis exitos y derrotas.
Bueno, todo empezó con un curso de scala de coursera y quede encantado con el lenguaje y la programación funcional. De a poco tambien me interiorice en otros lenguajes como erlang, haskell, Clojure, Elixir, F#, etc ... pero siempre en la volvía a Scala por gusto nomas. Y me iba bastante bien...
Hasta que empece a quedarme corto en scala, quería progresar y decidí ver algunos framework funcionales, leí un libro de Cats y la verdad es que si bien esta bueno, me frustre mucho... porque no sabia porque se hacían ciertas cosas, no entendía porque tan complejo o si bien entendía desconfiaba ( no hay otra forma de hacerlo más fácil) y bueno ...
Cambie a Akka, y me pareció bueno y me sentí más en mi mundo, pero justo justo cuando volvia el entuciasmo, cambio de licencia y bueno... Se fue el entusiasmo, ahora sé que existe un fork open source llamado pekko (https://github.com/apache/incubator-pekko) y es de apache. Pero lo veo verde, y no sé cuanto va a crecer ...
Y ahora estoy con ZIO y por ahora todo va bien, por ende la conclusión es si quieren progresar en su conocimiento en Scala, y no vienen del mundo funcional como Haskell, ZIO esta bueno.
Si son nuevos en el mundo funcional y scala, yo haría lo siguiente:
1. Estudiar Scala (curso de scala de coursera, el libro rojo de programación funcional en scala, etc ...)
2. Leer y estudiar ZIO
3. Leer y estudiar Cats
Pero no perder de vista Pekko, para ver como progresa.
Que opinan?
Por otro lado, a diferencia de Java, Kotlin no requiere que especifiques el tipo de cada variable explícitamente en tu código fuente. En muchos casos, el tipo de una variable se puede determinar automáticamente a partir del contexto, lo que le permite omitir la declaración de tipo. Aquí está el ejemplo más simple posible de esto:
val x = 1
Estás declarando una variable y, como se inicializa con un valor entero, Kotlin determina automáticamente que su tipo es Int. La capacidad del compilador para determinar tipos a partir del contexto se denomina inferencia de tipos.
Los siguientes son algunos de los beneficios del tipado estático:
Gracias a la compatibilidad de Kotlin con la inferencia de tipos, la mayor parte de la verbosidad adicional asociada con la escritura estática desaparece porque no es necesario declarar los tipos explícitamente.
Si observa los detalles del sistema de tipos de Kotlin, encontrará muchos conceptos familiares. Las clases, las interfaces y los genéricos funcionan de manera muy similar a Java, por lo que la mayor parte de su conocimiento de Java debería transferirse fácilmente a Kotlin. Sin embargo, algunas cosas son nuevas.
El más importante de ellos es el soporte de Kotlin para tipos anulables, lo que le permite escribir programas más confiables al detectar posibles excepciones de puntero nulo en el momento de la compilación.
Otra cosa nueva en el sistema de tipos de Kotlin es su soporte para tipos de funciones. Para ver de qué se trata, veamos las ideas principales de la programación funcional y veamos cómo se admite en Kotlin.
Programación funcional y orientada a objetos: Como desarrollador de Java, sin duda estamos familiarizado con los conceptos básicos de la programación orientada a objetos, pero la programación funcional puede ser nueva para desarrolladores Java. Los conceptos clave de la programación funcional son los siguientes:
¿Qué beneficios puede obtener al escribir código en el estilo funcional? Primero, concisión. El código funcional puede ser más elegante y sucinto en comparación con su contraparte imperativa, porque trabajar con funciones como valores le brinda mucho más poder de abstracción, lo que le permite evitar la duplicación en su código.
Imagine que tiene dos fragmentos de código similares que implementan una tarea similar (por ejemplo, buscar un elemento coincidente en una colección) pero difieren en los detalles (cómo se detecta el elemento coincidente). Puede extraer fácilmente la parte común de la lógica en una función y pasar las partes diferentes como argumentos. Esos argumentos son en sí mismos funciones, pero puede expresarlos usando una sintaxis concisa para funciones anónimas llamadas expresiones lambda:
fun findAlice() = findPerson { it.name == "Alice" }
fun findBob() = findPerson { it.name == "Bob" }
El segundo beneficio del código funcional es el subprocesamiento múltiple seguro. Una de las mayores fuentes de errores en los programas de subprocesos múltiples es la modificación de los mismos datos de varios subprocesos sin la sincronización adecuada. Si usa estructuras de datos inmutables y funciones puras, puede estar seguro de que tales modificaciones inseguras no ocurrirán y no necesita idear esquemas de sincronización complicados.
Finalmente, la programación funcional significa pruebas más fáciles. Las funciones sin efectos secundarios se pueden probar de forma aislada sin necesidad de una gran cantidad de código de configuración para construir todo el entorno del que dependen.
En términos generales, el estilo funcional se puede usar con cualquier lenguaje de programación, incluido Java, y muchas partes del mismo se recomiendan como un buen estilo de programación. Pero no todos los lenguajes brindan el soporte sintáctico y de biblioteca necesario para usarlo sin esfuerzo; por ejemplo, este soporte faltaba en su mayoría en las versiones de Java anteriores a Java 8. Kotlin tiene un amplio conjunto de características para admitir la programación funcional desde el principio. Estos incluyen lo siguiente:
Kotlin le permite programar en el estilo funcional pero no lo impone. Cuando lo necesite, puede trabajar con datos mutables y escribir funciones que tienen efectos secundarios sin tener que pasar por obstáculos adicionales. Y, por supuesto, trabajar con marcos que se basan en interfaces y jerarquías de clases es tan fácil como con Java. Al escribir código en Kotlin, puede combinar los enfoques funcional y orientado a objetos y utilizar las herramientas más apropiadas para el problema que está resolviendo.
Gratuito y open source: El lenguaje Kotlin, incluido el compilador, las bibliotecas y todas las herramientas relacionadas, es completamente de código abierto y de uso gratuito para cualquier propósito. Está disponible bajo la licencia Apache 2; el desarrollo ocurre abiertamente en GitHub (http://github.com/jetbrains/kotlin), y las contribuciones de la comunidad son bienvenidas. También puede elegir entre tres IDE de código abierto para desarrollar sus aplicaciones de Kotlin: IntelliJ IDEA Community Edition, Android Studio y Eclipse son totalmente compatibles. (Por supuesto, IntelliJ IDEA Ultimate también funciona).
Los de n tipos de tecnologías es mentiroso solo 2 framework use por ahora Spring boot y micronaut y a decir verdad use un 80% de spring boot pero quiero escribir un post tipo draft, por las dudas si me canso y nunca termino.
Por ende, vamos a ver como me fue con Spring boot y diferentes lenguajes y luego hablo de micronaut.
Java: Bueno, esta es la tupla más utilizada y creo que ustedes saben que anda muy bien. No sé si puedo agregar algo más que no sepan.
Kotlin: Me encanto, por varias razones me parece mejor que java. Kotlin es un lenguaje, muy bueno y muy compatible con java lo que lo hace una opción super fácil de usar y no se sufre nada con la compatibilidad con spring boot.
Groovy: Igual que Java, no encuentro una buena razón para elegir este lenguaje, esta bueno, pero el tipado dinamico, no ofrece mayor ventaja y si lo usamos con tipando estático, es similar a java o kotlin.
Scala: Un infierno de incompatibilidad, no le recomiendo utilizar spring boot con scala, tenes que estar siempre cambiando tipos, de tipos de Scala a Java y de Java a Scala. No es una opción práctica...
Clojure: Otro infierno, no solo por los tipos, sino tambien por la generación de clases con anotaciones. Muy trabajoso, al final cuando te funciona una Api, no te acordas para que la querías.
Micronaut lo utilice muy poco con Groovy y Java y me fue muy bien, casi casi puedo decir que me gusta más que spring boot. Y ahora sigo con Micronaut y Quarkus.
Veamos un ejemplo
(defproject ejemplo "0.1.0-SNAPSHOT"
:description "FIXME: write description"
:url "http://example.com/FIXME"
:license {:name "EPL-2.0 OR GPL-2.0-or-later WITH Classpath-exception-2.0"
:url "https://www.eclipse.org/legal/epl-2.0/"}
:dependencies [[org.clojure/clojure "1.10.3"],
... ]
:java-source-paths ["src-java"]
:main com.assembly.ejemplo.core
:aot :all
:target-path "target/%s"
:profiles {:uberjar {:aot :all
:jvm-opts ["-Dclojure.compiler.direct-linking=true"]}})
Y listo!!
Primero hacemos un proyecto hello word con Leiningen (ojo tienen que tener Leiningen instalado, esta bueno instalarlo con sdkman, así : sdk install leiningen)
lein new app ejemplo
Luego agregamos las dependencias de spring boot al proyecto, para que quede algo así:
Y ahora hacemos un endpoint, en este ejemplo voy a hacer un hola mundo :
(ns com.assembly.exanple.controller.greet
(:import (org.springframework.web.bind.annotation PathVariable RequestMapping RequestMethod RestController)
(org.springframework.http ResponseEntity))
)
(gen-class
:name ^{RestController {}
RequestMapping {:value ["/v1/greet"]}} com.assembly.exanple.controller.greet.GreeterEndPoint
:methods [[^{RequestMapping {:value ["/hello"]
:method [RequestMethod/GET]}} sayHello [] Object ]
[^{RequestMapping {:value ["/helloto/{name}"]
:method [RequestMethod/GET]}} sayHelloTo [^{PathVariable {:value "name"}} String] Object ]
]
:state injected
:init init
)
(defn -init
"Initialize the class by setting the state to an empty map, which can be populated with injected dependencies."
[]
[[] (atom {})])
(defn -sayHello
[this]
(ResponseEntity/ok "Hello"))
(defn -sayHelloTo
[this name]
(ResponseEntity/ok (str "Hello " name)))
Y listo, si corremos el main, vamos a levantar el tomcat embebido de spring y vamos a :
http://localhost:8080/v1/greet/hello
y veremos como nos saluda spring boot con clojure!!
As of April 2022, according to the TIOBE Index[1] of the top 100 programming languages, the top JVM languages are:
Lo que me sorprendio no fue la información sino que la wikipedia este tan actualizada.
Otra cosa que me llamo la atención es que groovy le gane a scala o a clojure, pense que era diferente.
Y bueno, eso es todo, no me critiquen porque pegue algo en ingles en un blog en español, es de la wikipedia, no voy andar cambiando la fuente.
Dejo link : https://en.wikipedia.org/wiki/List_of_JVM_languages
(defn create-session []
(let [snippets (repeatedly promise)
translations (delay (map translate
(strings->sentences (map deref snippets))))]
(new-session {:snippets snippets :translations translations})))
Seguimos usando una secuencia perezosa infinita de promesas para representar los fragmentos entrantes y un mapa sobre esa secuencia para representar las traducciones, pero ahora ambos están almacenados en una sesión.
A continuación, debemos modificar accept-snippet y get-translation para buscar :snippets o :translations dentro de una sesión:
(defn accept-snippet [session n text]
(deliver (nth (:snippets session) n) text))
(defn get-translation [session n]
@(nth @(:translations session) n))
(def last-session-id (atom 0))
(defn next-session-id []
(swap! last-session-id inc))
(def sessions (atom {}))
(defn new-session [initial]
(let [session-id (next-session-id)]
(swap! sessions assoc session-id initial)
session-id))
(defn get-session [id]
(@sessions id))
Creamos una nueva sesión pasando un valor inicial a new-session, que obtiene una nueva ID de sesión y la agrega a las sesiones llamando a swap!. Recuper una sesión con get-session es una simple cuestión de buscarlo por su ID.
Si no vamos a aumentar continuamente la cantidad de memoria que usamos, necesitaremos alguna forma de eliminar las sesiones cuando ya no estén en uso. Nosotros podría hacer esto explícitamente (quizás con una función de eliminación de sesión), pero dado que estamos escribiendo un servicio web en el que no necesariamente podemos confiar en que los clientes limpien correctamente, vamos a implementar la caducidad de la sesión (expiry) en su lugar. Esto requiere un pequeño cambio en el código anterior:
(def sessions (atom {}))
(defn now []
(System/currentTimeMillis))
(defn new-session [initial]
(let [session-id (next-session-id)
session (assoc initial :last-referenced (atom (now)))]
(swap! sessions assoc session-id session)
session-id))
(defn get-session [id]
(let [session (@sessions id)]
(reset! (:last-referenced session) (now))
session))
Ahora que cada sesión tiene una entrada :last-referenced, podemos caducar sesiones verificando periódicamente si alguna no ha sido referenciada por más de un cierto período de tiempo:
(defn session-expiry-time []
(- (now) (* 10 60 1000)))
(defn expired? [session]
(< @(:last-referenced session) (session-expiry-time)))
(defn sweep-sessions []
(swap! sessions #(remove-vals % expired?)))
(def session-sweeper
(schedule {:min (range 0 60 5)} sweep-sessions))
user=> (def non-negative (atom 0 :validator #(>= % 0)))
#'user/non-negative
user=> (reset! non-negative 42)
42
user=> (reset! non-negative -1)
IllegalStateException Invalid reference state
El validador se llama antes de que se haya cambiado el valor del átomo y, al igual que la función que se pasa a swap!. Por lo tanto, los validadores tampoco deben tener efectos secundarios.
Los átomos también pueden tener observadores asociados con ellos:
user=> (def a (atom 0))
#'user/a
user=> (add-watch a :print #(println "Changed from " %3 " to " %4))
#<Atom@542ab4b1: 0>
user=> (swap! a + 2)
Changed from 0 to 2
2
Las estructuras de datos persistentes son invaluables para la programación concurrente porque una vez que un subproceso tiene una referencia a una estructura de datos, no verá cambios realizados por ningún otro subproceso. Las estructuras de datos persistentes separan la identidad del estado. ¿Cuál es el nivel de combustible en su automóvil? En este momento, podría estar medio lleno. Algún tiempo después estará casi vacío, y unos minutos después de eso (después de que te detengas para llenar) estará lleno. La identidad "nivel de combustible en su automóvil" es una cosa, cuyo estado cambia constantemente. El “nivel de combustible en su automóvil” es en realidad una secuencia de diferentes valores: el 23/02/2012 a las 12:03 era 0,53; en 2012-02-23 14:30 era 0.12; y en 2012-02-23 14:31 era 1.00.
Una variable en un lenguaje imperativo completa (entrelaza, interconecta) la identidad y el estado: una única identidad solo puede tener un único valor, lo que hace que sea fácil perder de vista el hecho de que el estado es realmente una secuencia de valores a lo largo del tiempo. Las estructuras de datos persistentes separan la identidad del estado: si recuperamos el estado actual asociado con una identidad, ese estado es inmutable e muatble, sin importar lo que suceda con la identidad de la que recuperamos en el futuro.
Heráclito lo expresó así: No podías meterte dos veces en el mismo río; porque otras aguas están siempre fluyendo sobre ti.
La mayoría de los lenguajes se aferran a la falacia de que el río es una sola entidad consistente; Clojure reconoce que está en constante cambio.
Debido a que Clojure es funcional, los átomos pueden no tener bloqueo; internamente, utilizan el método compareAndSet() en java.util.concurrent.AtomicReference. Eso significa que son muy rápidos y no se bloquean (por lo que no hay peligro de interbloqueo). Pero también significa ese intercambio necesita manejar el caso en el que el valor del átomo ha sido cambiado por otro hilo entre llamar a la función para generar un nuevo valor e intentar cambiar ese valor.
Si eso sucede, volverá a intentarlo. Descartará el valor devuelto por la función y lo llamará de nuevo con el nuevo valor del átomo. Ya vimos algo muy similar a esto cuando usamos ConcurrentHashMap. Esto significa que es esencial que la función pase a swap! no tiene efectos secundarios; si los tuviera, entonces esos efectos secundarios podrían ocurrir más de una vez. Afortunadamente, aquí es donde la naturaleza funcional de Clojure vale la pena: el código funcional naturalmente no tiene efectos secundarios.
Las estructuras de datos persistentes, no tiene nada que ver con la persistencia en el disco o dentro de una base de datos. En cambio, se refiere a una estructura de datos que siempre conserva su versión anterior cuando se modifica, lo que permite que el código tenga una vista consistente de los datos ante modificaciones.
Podemos ver esto fácilmente en el REPL:
user=> (def mapv1 {:name "paul" :age 45})
#'user/mapv1
user=> (def mapv2 (assoc mapv1 :sex :male))
#'user/mapv2
user=> mapv1
{:age 45, :name "paul"}
user=> mapv2
{:age 45, :name "paul", :sex :male}
Las estructuras de datos persistentes se comportan como si se hiciera una copia completa cada vez que se modifican. Si esa fuera la forma en que se implementaron realmente, sería muy ineficiente y, por lo tanto, de uso limitado
Afortunadamente, la implementación es mucho más inteligente que eso y hace uso de la estructura compartida.
La estructura de datos persistentes más fácil de entender es la lista. Aquí hay una lista simple:
user=> (def listv1 (list 1 2 3))
#'user/listv1
user=> listv1
(1 2 3)
Y aquí hay un diagrama de cómo se ve en la memoria:
Ahora vamos a crear una versión modificada con cons, que devuelve una copia de la lista con un elemento agregado al frente:
user=> (def listv2 (cons 4 listv1))
#'user/listv2
user=> listv2
(4 1 2 3)
Finalmente, creemos otra versión modificada:
user=> (def listv3 (cons 5 (rest listv1)))
#'user/listv3
user=> listv3
(5 2 3)
Veamos un ejemplo que muestra cómo las estructuras de datos persistentes de Clojure significan que el estado mutable no puede escapar como lo hace en Java.
(def players (atom ()))
(defn list-players []
(response (json/encode @players)))
(defn create-player [player-name]
(swap! players conj player-name)
(status (response "") 201))
Esto define un par de rutas: una solicitud GET a /players recuperará una lista de los jugadores actuales (en formato JSON) y una solicitud PUT a "/players/:player-name" agregará un jugador a esa lista. El servidor Embedded Jetty es multiproceso, por lo que nuestro código deberá ser seguro para subprocesos.
Veámoslo en acción. Podemos ejecutarlo desde la línea de comandos con curl:
$ curl localhost:3000/players
[]
$ curl -X put localhost:3000/players/john
$ curl localhost:3000/players
["john"]
$ curl -X put localhost:3000/players/paul
$ curl -X put localhost:3000/players/george
$ curl -X put localhost:3000/players/ringo
$ curl localhost:3000/players
["ringo","george","paul","john"]
Todo esto parece muy simple (y lo es), pero algo podría estar preocupándote algo al respecto. Tanto las funciones de listar jugadores como las de crear jugadores acceden a los jugadores. ¿Por qué este código no sufre el mismo problema que el código Java? ¿Qué sucede si un subproceso agrega una entrada a la lista de reproductores mientras otro lo itera y lo convierte a JSON? Este código es seguro para subprocesos porque las estructuras de datos de Clojure son persistentes.
Y que significa que sea persistente? y en el próximo post te cuento.
Si bien la programación funcional funciona increíblemente bien para algunos problemas, algunos tienen la modificación del estado como un elemento fundamental de la solución. Aunque puede ser posible crear una solución funcional a tales problemas, es más fácil pensar en ellos de una manera más tradicional.
Un lenguaje funcional puro no proporciona soporte para datos mutables en absoluto. Clojure, por el contrario, es impuro: proporciona varios tipos diferentes de variables mutables conscientes de la concurrencia, cada una de las cuales es adecuada para diferentes casos de uso. Estos, en conjunto con las estructuras de datos persistentes de Clojure (vamos a cubriremos lo que significa persistente en este contexto más adelante) nos permiten evitar muchos de los problemas que tradicionalmente afligen a los programas concurrentes con estado mutable compartido.
La diferencia entre un lenguaje funcional impuro y un lenguaje imperativo es de énfasis. En un lenguaje imperativo, las variables son mutables por defecto y el código idiomático las modifica con frecuencia. En un lenguaje funcional impuro, las variables son inmutables por defecto y el código idiomático modifica aquellas que no lo son solo cuando es absolutamente necesario. Como veremos, las variables mutables de Clojure nos permiten manejar los efectos secundarios del mundo real sin dejar de ser seguros y consistentes.
Veremos cómo las variables mutables de Clojure funcionan en conjunto con las estructuras de datos persistentes para separar la identidad del estado. Esto permite que varios subprocesos accedan a variables mutables simultáneamente sin bloqueos (y el peligro asociado de interbloqueo) y sin ninguno de los problemas de estado mutable escapado u oculto. Comenzaremos por lo que podría decirse que es el más simple de los tipos de variables mutables de Clojure, el átomo.
Un átomo es una variable atómica (los átomos de Clojure están construidos sobre java.util.concurrent.atomic). A continuación, se muestra un ejemplo de cómo crear y recuperar el valor de un átomo:
user=> (def my-atom (atom 42))
#'user/my-atom
user=> (deref my-atom)
42
user=> @my-atom
42
RxJava es un framwork que implementa los conceptos de ReactiveX en Java. Veamos un ejemplo RxJava:
List<Integer> input = Arrays.asList(1, 2, 3, 4, 5);
Observable.from(input).filter(new Func1() {
@Override
public Boolean call(Integer x) {
return x % 2 == 0;
}
})
o usando lambda :
Observable.from(input).filter(x -> x % 2 == 0);
La biblioteca RxJava se creó en Netflix como una alternativa más inteligente a Java Futures y devoluciones de llamada. Tanto los futuros como las devoluciones de llamada son fáciles de usar cuando solo hay un nivel de ejecución asincrónica, pero son difíciles de administrar cuando están anidados.
El siguiente ejemplo muestra cómo se maneja el problema de las devoluciones de llamada anidadas en RxJava.
Suponga que necesita llamar a una API remota para autenticar a un usuario, luego a otra para obtener los datos del usuario y a otra API para obtener los contactos de un usuario. Normalmente, tendría que escribir llamadas a API anidadas y hacer complejos callbacks. Pero con RxJava se puede hacer así :
serviceEndpoint.login().doOnNext(accessToken -> storeCredentials(accessToken)).flatMap(accessToken -> serviceEndpoint.getUser()).flatMap(user -> serviceEndpoint.getUserContact(user.getId()))
Deben haber pensado: y los test, donde están los test?
Bueno, vamos a hacer una pequeña función cuadrado por ejemplo :
Esto es muy fácil hacemos así :
$ lein new app nombreDeLaApp
Generating a project called nombreDeLaApp based on the 'app' template.
