K33G_ORG's blog

Programmation OnBoard sur Android avec Termux

Régulièrement je cherche des applications mobiles me permettant de faire du dev n’importe où 😜. Qui (chez nous les codeurs) ne sait pas retrouvé dans le train, le métro, une salle d’attente, … avec une idée de code à tester … mais pas de laptop?

Et ce mois ci je suis tombé sur Termux

Petite prise en main rapide

Installez Termux sur votre smartphone ou tablette
Lancez la bête

Insaller quelques outils

pkg install tree
pkg install curl
pkg install micro
pkg install nodejs

Remarque: micro est un éditeur de code un peu plsu évolué que nano ou pico et plus user friendly que vi

1er programme en JavaScript

Tapez:

micro hello.js

et saisissez un peu de code

Sauvegardez (Ctrl+s) puis quittez (Ctrl+q)

Remarque: sur un Smartphone, la touche Ctrl est “émulée” par Volume Bas

Lancez le programme:

C’est sympa, mais on peut faire encore mieux, on peut compiler!!!

Look Ma! I’m doing Rust on my phone!

Pour pouvoir installer Rust sous Termux, il faut déclarer un autre repository de packages avec cette commande:

curl -L https://its-pointless.github.io/setup-pointless-repo.sh | sh

Remarque: c’est pour cela que nous avons installé curl 😉 plus d’info ici https://wiki.termux.com/wiki/Package_Management#its-pointless_.28live_the_dream.29 et ici https://wiki.termux.com/wiki/Main_Page#Rust

Maintenant installons Rust et Cargo:

pkg install rustc cargo rust-docs

Créer un projet Rust

Tapez les commandes suivantes:

export USER=bob # ps: vous pouvez l'appeler autrement
cargo new hi --bin

Cargo va créer l’arborescence de projet nécessaire.

Allez ouvrir et modifier le fichier src/main.rs

Sauvegardez et Quittez (Ctrl+s puis Ctrl+q) et compilez:

cargo build # à la racine du projet

Lancez:

./target/debug/hi

Je pense que les possibilités de Termux sont nombreuses. Fini les longs repas de famille ennuyeux 😉

Je suis impatient de voir arriver le package Java, je pourrais enfin faure du Golo, en plus il y a la coloration syntaxique de Golo pour l’éditeur Micro https://github.com/zyedidia/micro/blob/master/runtime/syntax/golo.yaml

Have fun 👋

SOZU, le reverse-proxy magique, Partie 2

Sōzu, 1ers pas, 2ème partie

Dans un précédent article j’expliquais comment débuter avec Sōzu. (c’est par ici http://k33g.github.io/2017/07/29/SOZU-1-FR.html) avec plein de manipulations, de code, , de compilation, etc… à taper. Donc aujourd’hui je reviens avec une version démo un peu plus packagée pour que vous n’ayez presque rien à faire. Même la compilation de Sōzu se fera toute seule.

Pré-requis

Installer VirtualBox
Installer Vagrant
Clôner ce projet : https://github.com/k33g/sozu-vagrant-demo (faites ceci git clone git@github.com:k33g/sozu-vagrant-demo.git)

Lancement

cd sozu-vagrant-demo
vagrant up

Allez vous préparer un ☕️ (la 🍺 marche aussi).

1ers contacts

Donc quelques minutes

Normalement,vous avez 7 machines de lancées (faites un vagrant status pour voir)

webapp1         192.168.1.21:8080
webapp2         192.168.1.22:8080
webapp3         192.168.1.23:8080
webapp_new1     192.168.1.31:8080
webapp_new2     192.168.1.32:8080
webapp_new3     192.168.1.33:8080
sozuapp         192.168.1.99:8080

Remarques:

les 6 1ères VMs contiennent une application web Express démarrée

les VMS 1, 2, 3 contiennent la version 1 de l’application web

les VMS 4, 5, 6 contiennent la version 2 de l’application web

la dernière VM sozuapp contient rust, cargo et Sōzu compilé

vous pouvez diminuer le nombre de VM en modifiant le Vagrantfile

⚠️ J’ai aussi modifié mon fichier hosts en ajoutant ceci:

192.168.1.99 sozu.local

Donc pour se connecter au reverse proxy (Sōzu), vous utiliserez cette adresse: http://sozu.local:8080/

si vous regardez le fichier de configuration de Sōzu (demo.toml), il y a la rubrique [applications.webapp]:

hostname = "sozu.local"
frontends = [ "HTTP" ]
backends  = [ "192.168.1.21:8080", "192.168.1.22:8080", "192.168.1.23:8080"]

ce qui signifie que vous pouvez vous connecter via Sōzu à une des 3 webapps webapp1, webapp2 ou webapp3 (c’est Sōzu qui choisi), vous pouvez faire le test en ouvrant plusieurs navigateurs (le code source des webapps est le même mais il affiche un nom différent pour chacune)

Enlever des machines

Nous allons nosus connecter en ssh à la machine sozuapp, pour cela tapez la commande suivante:

vagrant ssh sozuapp

puis:

cd sozu-project/
sudo ./sozu/target/debug/sozuctl --config ./demo.toml  backend remove --id webapp --ip 192.168.1.21 --port 8080
sudo ./sozu/target/debug/sozuctl --config ./demo.toml  backend remove --id webapp --ip 192.168.1.22 --port 8080
sudo ./sozu/target/debug/sozuctl --config ./demo.toml  backend remove --id webapp --ip 192.168.1.23 --port 8080

Remarque: webapp correspond au titre de la rubrique [applications.webapp] du fichier demo.toml de configuration de Sōzu

Ajouter des machines

Si vous vous souvenez bien, en plus de la machine Sōzu il reste 3 machines supplémentaires qui “tournent”:

webapp_new1     192.168.1.31:8080
webapp_new2     192.168.1.32:8080
webapp_new3     192.168.1.33:8080

Nous allons les enregistrer (ajouter) dans Sōzu (sans re-démarrage):

vagrant ssh sozuapp # su vous n'êtes plus connecté

Puis:

cd sozu-project/
sudo ./sozu/target/debug/sozuctl --config ./demo.toml  backend add --id webapp --ip 192.168.1.31 --port 8080
sudo ./sozu/target/debug/sozuctl --config ./demo.toml  backend add --id webapp --ip 192.168.1.32 --port 8080
sudo ./sozu/target/debug/sozuctl --config ./demo.toml  backend add --id webapp --ip 192.168.1.33 --port 8080

Et cette fois ci Sōzu va vous rediriger vers les nouvelles applications:

C’est aussi simple que ça.

Pour arrêter et supprimer vos VMs:

vagrant halt; vagrant destroy -f
# pour recommencer: vagrant up

Prochaine démo d’ici une semaine ou deux (j’ai 2,3 trucs à apprendre avant)

👋

SOZU, le reverse-proxy magique

Jouer avec Sōzu - 1ers pas

Objectif de ce blog post: mettre en place un environnement pour pouvoir “jouer” avec Sōzu

Niveau: débutant

ce que j’écris n’engage que moi bien sûr 😃

le réseau n’est vraiment pas mon domaine 😖

Nous verrons (rapidement)

comment installer Sōzu

comment l’utiliser pour répartir la charge sur plusieurs VMs

comment l’utiliser pour déployer une nouvelle version de site Et tout cela de manière transparente mais à la main ✋🤚 pour mieux comprendre

1) Sōzu?

Sōzu est un reverse proxy HTTP développé chez https://www.clever-cloud.com/ qui peut changer sa configuration au runtime, sans re-démarrer. Le proxy expose une chaîne de communication (communication channel in 🇬🇧) et du coup on peut envoyer des commandes à chaud à Sōzu.

Si vous voulez savoir ce qu’est un reverse proxy parce que vous n’y connaissez rien ou presque sur le sujet, je vous conseille cette vidéo Comprendre le Proxy et le Reverse Proxy en 5 minutes par “Cookie connecté”.

Si vous voulez en savoir plus sur Sōzu, je vous conseille la lecture de ce blog post (le comment, le pourquoi de Sōzu): Hot reloading configuration: why and how? par Geoffroy Couprie le papa de Sōzu (à qui je n’ai rien fait relire 😜)

Et le repository GitHub est par ici: https://github.com/sozu-proxy/sozu

✨✨✨ Remerciements pour leurs explications

2) Mise en place du terrain de jeux

Nous aurons besoin de plusieurs VMs (virtual machines), j’ai choisi d’utiliser:
- VirtualBox https://www.virtualbox.org/
- Vagrant https://www.vagrantup.com/
- ℹ️ vous pouvez adapter avec vos outils, l’important c’est de pouvoir simuler plusieurs machines
- Les installations de VirtualBox et Vagrant sont très simples à faire
Il faudra “builder” Sōzu
- Nous devront donc installer Rust (car, je le rappelle Sōzu est codé en Rust).
- ⚠️ Sōzu est encore en 🚧 donc certaines choses peuvent changer

Qu’allons nous faire?: héberger un même code source de site web en NodeJS dans plusieurs VMs

Tout d’abord créez une arborescence pour héberger nos expérimentations:

sandbox
   ├── hello-earth-v1   # ici le code source de mon site web
   ├── vms              # le projet Vagrant pour générer et provisionner nos VM
   ├── sozu-demo        # ici nous builderons le projet sozu

A) Le code source du site web

J’ai utilisé ExpressJS. vous allez avoir besoin uniquement de 2 fichiers:

index.js

package.js

sandbox
   ├── hello-earth-v1   
   │   ├── index.js
   │   └── package.json   
   ├── vms              
   ├── sozu-demo

index.js

ℹ️ j’utilise la librairie 'project-name-generator' pour générer un nom de machine différent pour chacune des VMs.

const express = require("express");
const bodyParser = require("body-parser");
const generate = require('project-name-generator');

let port = process.env.PORT || 8080;

let app = express();
app.use(bodyParser.json())
app.use(bodyParser.urlencoded({extended: false}))

let machineName = generate({ words: 3, number: true }).dashed

app.disable('etag');

app.get('/', (req, res) => {
  res.send(`
    <!doctype html>
    <html>
      <head>
        <meta charset="utf-8">
        <meta http-equiv="x-ua-compatible" content="ie=edge">
        <title>WebApp</title>
        <meta name="description" content="">
        <meta name="viewport" content="width=device-width, initial-scale=1">

        <style>
        .container
        {
          min-height: 100vh;
          display: flex;
          justify-content: center;
          align-items: center;
          text-align: center;
        }
        .title
        {
          font-family: "Source Sans Pro", "Helvetica Neue", Arial, sans-serif;
          display: block;
          font-weight: 300;
          font-size: 40px;
          color: #35495e;
          letter-spacing: 1px;
        }
        .subtitle
        {
          font-family: "Source Sans Pro", "Helvetica Neue", Arial, sans-serif;
          font-weight: 300;
          font-size: 30px;
          color: #526488;
          word-spacing: 5px;
          padding-bottom: 15px;
        }
        </style>
      </head>
      <body>
        <section class="container">
          <div>
            <h1 class="title">
              👋 I am ${machineName}
            </h1>
            <h2 class="subtitle">
              Hello 🌍 v1
            </h2>
          </div>
        </section>
      </body>
    </html>
  `)
})

app.listen(port)
console.log(`🌍 ${machineName} is started - listening on `, port)

package.json

{
  "name": "hello-earth",
  "scripts": {
    "start": "node index.js"
  },
  "main": "index.js",
  "dependencies": {
    "body-parser": "^1.17.2",
    "express": "^4.15.3",
    "project-name-generator": "^2.1.3"
  }
}

B) Notre projet Vagrant

Dans le répertoire vms, allez créer un fichier Vagrantfile

sandbox
   ├── hello-earth-v1   
   │   ├── index.js
   │   └── package.json   
   ├── vms   
   │   └── Vagrantfile               
   ├── sozu-demo

Vagrantfile

Que fait le script?

je crée 3 VMs à partie d’une image bento/ubuntu-17.04

chaque VM aura une ip fixe et se nomme webappN:

webapp1 : 192.168.1.21

webapp2 : 192.168.1.22

webapp3 : 192.168.1.23

j’expose le port 8080 (vous pourrez donc accéder à la webapp par http://192.168.1.2N:8080/)

je copie le code source de /hello-earth-v1 dans le répertoire /hello-earth de la vm

j’installe NodeJS

j’installe les packages nécessaires pour faire fonctionner la webapp (npm install)

BOX_IMAGE = "bento/ubuntu-17.04"
NODE_COUNT = 3

Vagrant.configure(2) do |config|
  config.vm.box = BOX_IMAGE

  (1..NODE_COUNT).each do |i|
    config.vm.define "webapp#{i}" do |node|

      node.vm.network :forwarded_port, guest: 8080, host: 9090 + i
      node.vm.network "public_network", ip: "192.168.1.2#{i}", bridge: "en0: Wi-Fi (AirPort)"

      node.vm.provider "virtualbox" do |node|
        node.memory = 256
        node.cpus = 1
      end
      
      node.vm.synced_folder '.', '/vagrant', disabled: true
      node.vm.provision "file", source: "../hello-earth-v1", destination: "hello-earth"
      
      node.vm.provision :shell, inline: <<-SHELL
        echo "👋 Installing NodeJS..."
        apt-get install curl python-software-properties -y
        curl -sL https://deb.nodesource.com/setup_7.x | sudo bash -
        apt-get install nodejs -y
        cd hello-earth
        npm install
        echo "😜 bye! 👋👋👋"
      SHELL

    end
  end
end

Nous pouvons dès maintenant générer les VMs et les démarrer ainsi que les webapps. ℹ️ Mais, vous n`êtes pas obligés de le faire tout de suite.

Générer (et démarrer les VMs) les VM

C’est tout simple:

cd vms
vagrant up
# ⏳ patientez un peu, il faut tout de même récupérer l'image de l'OS

Démarrer les webapps

Il faut donc démarrer les webapps au sein de chaque VM, comme cela:

vagrant ssh webapp1 -c "cd hello-earth; npm start"&
vagrant ssh webapp2 -c "cd hello-earth; npm start"&
vagrant ssh webapp3 -c "cd hello-earth; npm start"&

Vous devriez obtenir cette sortie:

🌍 delirious-flagrant-expert-3862 is started - listening on  8080
🌍 stimulating-jazzy-spoon-4201 is started - listening on  8080
🌍 knotty-responsible-muscle-3315 is started - listening on  8080

ℹ️ je génère un nom aléatoire pour chaque application pour mieux les reconnaître.

Vous pouvez déjà tester l’accès aux applications:

Maintenant passons aux choses sérieuses 😉

C) Installation de Sōzu

Suivre les étapes suivantes (cela peut être un peu long selon a configuration de votre machine):

# Installer Rust et le tooling associé
curl https://sh.rustup.rs -sSf | sh
# wait... 🤔

# cloner Sōzu
cd sozu-demo
git clone https://github.com/sozu-proxy/sozu

# compiler Sōzu
cd sozu
cd ctl && cargo build; cd ../bin && cargo build
# wait... 🤔

Vous devrier avoir cette arborescence:

sandbox
   ├── hello-earth-v1   
   │   ├── index.js
   │   └── package.json   
   ├── vms   
   │   └── Vagrantfile               
   ├── sozu-demo  
   │   └── sozu

Dans le répertoire /sozu/demo nous allons créer:

un répertoire command_folder
un fichier vide state.json
un fichier 404.html
un fichier 503.html
un fichier demo.toml

404.html

HTTP/1.1 404 nope
Cache-Control: no-cache
Content-Type: text/html; charset=UTF-8
Connection: close
<!doctype html>
<html>
  <head>
    <meta charset="utf-8">
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta http-equiv="Pragma" content="no-cache">
    <style>
    .title
    {
      font-family: "Source Sans Pro", "Helvetica Neue", Arial, sans-serif;
      display: block;
      font-weight: 300;
      font-size: 60px;
      color: #35495e;
      letter-spacing: 1px;
    }
    </style>
  </head>
  <body>
    <h1 class="title">
      😡 Nope❗️
    </h1>
  </body>
</html>

503.html

HTTP/1.1 503 your application is in deployment
Cache-Control: no-cache
Content-Type: text/html; charset=UTF-8
Connection: close
<!doctype html>
<html>
  <head>
    <meta charset="utf-8">

    <style>
    .title
    {
      font-family: "Source Sans Pro", "Helvetica Neue", Arial, sans-serif;
      display: block;
      font-weight: 300;
      font-size: 60px;
      color: #35495e;
      letter-spacing: 1px;
    }
    </style>
  </head>
  <body>
    <h1 class="title">
      😢 Ouch...
    </h1>
  </body>
</html>

demo.toml

C’est le fichier de configuration utilisé par Sōzu

# sozu proxy simple demo config file

command_socket = "./command_folder/sock"
saved_state    = "./state.json"
log_level      = "info"
log_target     = "stdout"
command_buffer_size = 16384
worker_count = 2
handle_process_affinity = false

# you need this, but currently it`s not used
[metrics]
address = "192.168.59.103"
port = 8125

[http]
address = "127.0.0.1"
max_connections = 10
port = 9090
buffer_size = 16384
answer_404 = "./404.html"
answer_503 = "./503.html"


[applications]

[applications.webapp]
hostname = "localhost"
frontends = [ "HTTP" ] # list of proxy tags
backends  = [ "192.168.1.21:8080", "192.168.1.22:8080", "192.168.1.22:8080" ] # list of IP/port

Les 2 sections les plus importantes pour notre “POC” sont [http] et [applications.webapp]:

avec [http], vous pouvez déduire que vos allez accéder au reverse-proxy via l’ip 127.0.0.1 et le port http 9090
avec [applications.webapp], le nom de domaine pour accéder au proxy est "localhost" et vous serez redirigés vers une des machines comprises dans la liste des ip sur un port particulier
ℹ️ dans [applications.webapp] c’est vous qui donnez le nom webapp, vous l’appelez comme vous voulez

Maintenant vous devriez avoir cette arborescence:

sandbox
   ├── hello-earth-v1   
   │   ├── index.js
   │   └── package.json   
   ├── vms   
   │   └── Vagrantfile               
   ├── sozu-demo  
   │   ├── 404.html  
   │   ├── 503.html   
   │   ├── demo.toml   
   │   ├── state.json  
   │   ├── command_folder/       
   │   └── sozu/

3) On joue … Une 1ère fois!

Si vous ne l’avez pas déjà fait, générez vos VM et lancez les webapps

Dans un 1er templ, lancez Sōzu:

cd sozu-demo
./sozu/target/debug/sozu start -c ./demo.toml

A) 1er contact

Maintenant ouvrez 2 navigateurs différents (j’ai fait le test avec Chrome et FireFox) avec l’url http://localhost:9090/ et vous obtiendrez ceci:

Vous pouvez voir que Sōzu vous a redirigé sur des machines différentes (pour une seule et même url)

B) Tuons des VMs

Arrêtons 2 VMs:

# obtenir la liste des VMs
cd vms
vagrant status

# Vous allez obtenir ceci:
Current machine states:

webapp1                   running (virtualbox)
webapp2                   running (virtualbox)
webapp3                   running (virtualbox)

# arrêtons webapp2 et webapp3  ... et supprimons les
vagrant halt webapp2; vagrant destroy webapp2 -f
vagrant halt webapp3; vagrant destroy webapp3 -f

vagrant status
# nouveau status
webapp1                   running (virtualbox)
webapp2                   not created (virtualbox)
webapp3                   not created (virtualbox)

Raffraichissez vos navigateurs
Il va falloir attendre un peu: Sōzu dispose d’un circuit-breaker qui va tenter pendant un petit moment de joindre les 2 machines “disparues”
puis Sōzu va “se rabattre” sur la machine restante

Et vous devriez obtenir ceci (j’ai fait un test supplémentaire avec Safari):

Arrêtons la dernière VM

vagrant halt webapp1; vagrant destroy webapp1 -f

Raffraichissez vos navigateurs
Attendez un peu… (selon les navigateurs et leur cache, les comportements peuvent être variables)

Et vous devriez obtenir notre favuleuse page 503:

4) On relance les sites

Alors on recrée les VMs une nouvelle fois, on démarre les webapps:

cd vms
vagrant up

Et vous relancez la webapp ExpressJS de la 1ère VM:

vagrant ssh webapp1 -c "cd hello-earth; npm start"

Ensuite nous allons “expliquer” à Sozu que nous avons une nouvelle machine à nouveau disponible en lui passant la commande suivante:

cd sozu-demo
./sozu/target/debug/sozuctl --config ./demo.toml  backend add --id webapp --ip 192.168.1.21 --port 8080

Raffraichissez vos navigateurs
Attendez un peu…
Et 🥁🥁🥁

Et ceci sans redémarrer Sōzu 😍🤗

Relancez les autres webapps:

vagrant ssh webapp2 -c "cd hello-earth; npm start"&
vagrant ssh webapp3 -c "cd hello-earth; npm start"&

Expliquons à Sōzu qu’il y a nouveau des machines supplémentaires:

./sozu/target/debug/sozuctl --config ./demo.toml  backend add --id webapp --ip 192.168.1.22 --port 8080

puis

./sozu/target/debug/sozuctl --config ./demo.toml  backend add --id webapp --ip 192.168.1.23 --port 8080

Raffraichissez vos navigateurs
Et voilà:

5) On fait une mise à jour de site

J’ai créé une nouvelle version du site dans un répertoire /hello-earth-v2 avec une évolution majeure, j’ai modifié une partie du code html:

<body>
  <section class="container">
    <div>
      <h1 class="title">
        👋 I am ${machineName} I ❤️ 🐼
      </h1>
      <h2 class="subtitle">
        Hello 🌍 v2
      </h2>
    </div>
  </section>
</body>

A) Nouveau projet Vagrant

Je vais donc créer de nouvelles VMs dans un répéertoire /vms-new

sandbox
   ├── hello-earth-v1   
   │   ├── index.js
   │   └── package.json   
   ├── hello-earth-v2  
   │   ├── index.js
   │   └── package.json      
   ├── vms   
   │   └── Vagrantfile   
   ├── vms-new   
   │   └── Vagrantfile                 
   ├── sozu-demo       
   │   └── sozu/

… Avec un nouveau Vagrantfile

chaque VM aura une nouvelle ip fixe et se nomme webapp_newN:

webapp1 : 192.168.1.31

webapp2 : 192.168.1.32

webapp3 : 192.168.1.33

je copie le code source de /hello-earth-v2 dans le répertoire /hello-earth de la vm

BOX_IMAGE = "bento/ubuntu-17.04"
NODE_COUNT = 3

Vagrant.configure(2) do |config|
  config.vm.box = BOX_IMAGE

  (1..NODE_COUNT).each do |i|
    config.vm.define "webapp_new#{i}" do |node|

      node.vm.network :forwarded_port, guest: 8080, host: 9100 + i
      node.vm.network "public_network", ip: "192.168.1.3#{i}", bridge: "en0: Wi-Fi (AirPort)"

      node.vm.provider "virtualbox" do |node|
        node.memory = 256
        node.cpus = 1
      end
      
      node.vm.synced_folder '.', '/vagrant', disabled: true
      node.vm.provision "file", source: "../hello-earth-v2", destination: "hello-earth"
      
      node.vm.provision :shell, inline: <<-SHELL
        echo "👋 Installing NodeJS..."
        apt-get install curl python-software-properties -y
        curl -sL https://deb.nodesource.com/setup_7.x | sudo bash -
        apt-get install nodejs -y
        cd hello-earth
        npm install
        echo "😜 bye! 👋👋👋"
      SHELL

    end
  end
end

B) Création, provisionning et lancement

On provisionne donc les nouvelles machines:

vagrant up
# puis
vagrant ssh webapp_new1 -c "cd hello-earth; npm start"
vagrant ssh webapp_new2 -c "cd hello-earth; npm start"
vagrant ssh webapp_new3 -c "cd hello-earth; npm start"

On “👋 notifie” Sōzu de l’arrivée de nouvelles machines

./sozu/target/debug/sozuctl --config ./demo.toml  backend add --id webapp --ip 192.168.1.31 --port 8080
./sozu/target/debug/sozuctl --config ./demo.toml  backend add --id webapp --ip 192.168.1.32 --port 8080
./sozu/target/debug/sozuctl --config ./demo.toml  backend add --id webapp --ip 192.168.1.33 --port 8080

Ensuite on “👋 notifie” Sōzu du départ des anciennes machines (cette fois çi avec le mot-clé remove)

./sozu/target/debug/sozuctl --config ./demo.toml  backend remove --id webapp --ip 192.168.1.21 --port 8080
./sozu/target/debug/sozuctl --config ./demo.toml  backend remove --id webapp --ip 192.168.1.22 --port 8080
./sozu/target/debug/sozuctl --config ./demo.toml  backend remove --id webapp --ip 192.168.1.23 --port 8080

Raffraichissez vos navigateurs
Attendez un peu…
Et ✨🐿 le nouveau site a été déploté sans aucun arrêt relance 🕺

Voilà, c’est tout pour aujourd’hui. Sōzu évolue et de nouvelles fonctionnalités sont à venir. Et de mon côté je pense déjà au prochain tuto Sōzu avec des microservices Vert.x.

Développer son propre Service Discovery Backend en mode REST pour Vert.x avec Node et Express

Développer son propre Service Discovery Backend pour Vert.x avec Node et Express

Par défaut, le mode de recherche de services de Vert.x utilise une structure de données distribuée (http://vertx.io/docs/vertx-service-discovery/java/#_backend). Vert.x propose d’autres moyens de “découverte de services”, et notamment un backend s’appuyant sur Redis http://vertx.io/docs/vertx-service-discovery/java/#_redis_backend que j’utilise habituellement.

La documentation de Vert.x explique qu’il est possible d’implémenter son propre ServiceDiscoveryBackend SPI (SPI pour Service Provider Interface). J’ai donc décidé comme exercice de faire mon propre backend de discovery pour les microservices Vert-x. C’est très formateur, et je remercie au passage Clément Escoffier et Julien Viet qui ont eu la patience de répondre à mes questions.

Quel type de Service Discovery Backend?

Avec ma forte appétence pour le JavaScript, vous ne serez pas surpris, j’ai décidé d’enregistrer mes microservices (et de permettre de les rechercher) avec une application Express.

Un système de discovery de microservices Vert.x doit proposer les fonctionnalités suivante:

enregistrer un nouveau service
modifier un service
supprimer un service
donner la liste des services

Le code pour faire cela est extrêmement simple:

mon backend va écouter sur le port 8080
il va gérer la liste des microservices en mémoire dans let services = []

const express = require("express");
const bodyParser = require("body-parser");

let port = process.env.PORT || 8080;

let app = express();
app.use(bodyParser.json())
app.use(bodyParser.urlencoded({extended: false}))

let services = []

// update informations about the service
app.put('/update/:registration', (req, res) => {
  let service = services.find(service => service.registration == req.params.registration)
  let index = services.indexOf(service)
  services[index] = req.body
  console.log("Services updated", services[index])
  res.end()
})

// unregister a service
app.delete('/remove/:registration', (req, res) => {
  let service = services.find(service => service.registration == req.params.registration)
  services.splice(services.indexOf(service), 1)
  res.status(202).end(req.params.registration)

})

// get all the services
app.get('/records', (req, res) => {
  res.send(services);
})

// register a service
app.post('/register', (req, res) => {
  let serviceInformations = req.body
  services.push(serviceInformations)
  console.log("🐼 New service added", serviceInformations)
  res.end()
})

app.listen(port)
console.log("🌍 Discovery Server is started - listening on ", port)

vous trouverez le code complet du backend ici: https://github.com/botsgarden/ms-http-backend

Implémenter ServiceDiscoveryBackend

Maintenant que nous avons un backend qui tourne, il faut implémenter la classe qui va nous permettre d’interagir avec ce backend.

Pour cela, j’ai créer un projet Maven (dont vous trouverez le code complet ici: https://github.com/botsgarden/vertx-service-discovery-backend-http)

mon fichier pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>org.typeunsafe</groupId>
  <artifactId>vertx-service-discovery-backend-http</artifactId>
  <version>1.0-SNAPSHOT</version>

  <properties>
    <vertx.version>3.4.2</vertx.version>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.1</version>
        <configuration>
          <source>1.8</source>
          <target>1.8</target>
        </configuration>
      </plugin>
    </plugins>
  </build>

  <dependencies>
    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-core</artifactId>
      <version>${vertx.version}</version>
    </dependency>

    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-web-client</artifactId>
      <version>${vertx.version}</version>
    </dependency>

    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-service-discovery</artifactId>
      <version>${vertx.version}</version>
    </dependency>
  </dependencies>
</project>

Implémentation de `HttpBackendService`

Voici donc le code Java de l’implémentation du ServiceDiscoveryBackend:

package org.typeunsafe;

import io.vertx.core.AsyncResult;
import io.vertx.core.Future;
import io.vertx.core.Handler;
import io.vertx.core.Vertx;
import io.vertx.core.json.JsonArray;
import io.vertx.core.json.JsonObject;
import io.vertx.servicediscovery.Record;
import io.vertx.servicediscovery.spi.ServiceDiscoveryBackend;

import io.vertx.ext.web.client.WebClient;

import java.util.List;
import java.util.Objects;
import java.util.UUID;
import java.util.stream.Collectors;

ma classe doit implémenter l’interface ServiceDiscoveryBackend

public class HttpBackendService implements ServiceDiscoveryBackend {

  private Integer httpBackendPort;
  private String httpBackendHost;
  private String registerUri;
  private String removeUri;
  private String updateUri;
  private String recordsUri;
  private WebClient client;

au moment de l’initialisation du ServiceDiscoveryBackend, je passe les informations de configuration nécessaire pour accéder au backend REST (la partie en Node/Express). J’instancie un WebClient qui me permettra d’envoyer des requêtes à mon backend.

  @Override
  public void init(Vertx vertx, JsonObject configuration) {
    client = WebClient.create(vertx);

    httpBackendPort = configuration.getInteger("port");
    httpBackendHost  = configuration.getString("host");
    registerUri  = configuration.getString("registerUri"); 
    removeUri  = configuration.getString("removeUri");
    updateUri  = configuration.getString("updateUri");  
    recordsUri  = configuration.getString("recordsUri"); 

    System.out.println("🤖 HttpBackendService initialized");

  }

la méthode store est appelée lorsqu’un microservice s’enregistre dans le backend. Et donc mon client va faire une requête de type POST au backend en lui passant record qui contient les informations fournies par le microservice pour s’enregistrer et c’est là que l’on affecte un numéro unique d’enregistrement au microservice (record.setRegistration(uuid))

  @Override
  public void store(Record record, Handler<AsyncResult<Record>> resultHandler) {
    
    if (record.getRegistration() != null) {
      resultHandler.handle(Future.failedFuture("The record has already been registered"));
      return;
    }
    String uuid = UUID.randomUUID().toString();
    record.setRegistration(uuid);

    client.post(this.httpBackendPort, this.httpBackendHost, this.registerUri)
      .sendJsonObject(record.toJson(), ar -> {
        System.out.println("Hey Oh!!!");
        if (ar.succeeded()) {
          resultHandler.handle(Future.succeededFuture(record));
        } else {
          resultHandler.handle(Future.failedFuture(ar.cause()));
        }
      });
  }

la méthode remove va supprimer l’enregistrement de la liste des microservices maintenue par le backend (l’application Express)

  @Override
  public void remove(Record record, Handler<AsyncResult<Record>> resultHandler) {
    Objects.requireNonNull(record.getRegistration(), "No registration id in the record");
    remove(record.getRegistration(), resultHandler);
  }

  @Override
  public void remove(String uuid, Handler<AsyncResult<Record>> resultHandler) {
    Objects.requireNonNull(uuid, "No registration id in the record");

    client.delete(this.httpBackendPort, this.httpBackendHost, this.removeUri + "/" + uuid)
      .send(ar -> {
        if (ar.succeeded()) {
          resultHandler.handle(Future.succeededFuture(
            new Record(new JsonObject().put("registration",uuid))
          ));
        } else {
          resultHandler.handle(Future.failedFuture(ar.cause()));
        }
      });

  }

Il est tout à fait possible de modifier les informations relatives au microservice et de les mettre à jour par une requête de type PUT

  @Override
  public void update(Record record, Handler<AsyncResult<Void>> resultHandler) {
    Objects.requireNonNull(record.getRegistration(), "No registration id in the record");

    client.put(this.httpBackendPort, this.httpBackendHost, this.updateUri + "/" + record.getRegistration())
      .sendJsonObject(record.toJson(), ar -> {
        if (ar.succeeded()) {
          resultHandler.handle(Future.succeededFuture());
        } else {
          resultHandler.handle(Future.failedFuture(ar.cause()));
        }
      });
  }

Et enfin, avec getRecords je peux demander la liste des microservices enregistrés

  @Override
  public void getRecords(Handler<AsyncResult<List<Record>>> resultHandler) {
    client.get(this.httpBackendPort, this.httpBackendHost, this.recordsUri).send(resp -> {

      if(resp.succeeded()) {
        try {
          JsonArray entries = resp.result().bodyAsJsonArray();
          List<Record> records = entries.stream().map(item -> new Record(JsonObject.mapFrom(item)))
              .collect(Collectors.toList());
                    
          resultHandler.handle(Future.succeededFuture(records));
        } catch (Exception e) {
          e.printStackTrace();
        }

      } else {
        resultHandler.handle(Future.failedFuture(resp.cause()));
      }
    });
  }

  @Override
  public void getRecord(String uuid, Handler<AsyncResult<Record>> resultHandler) {
    // TODO
  }

}

Voilà, ce n’est pas plus compliqué que cela (ok, je fais le malin maintenant 😉 )

1ère utilisation de `HttpBackendService`, écrivons un test

Tout d’abord, il faut ajouter ceci au pom.xml:

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.12</version>
  <scope>test</scope>
</dependency>

<dependency>
  <groupId>com.jayway.awaitility</groupId>
  <artifactId>awaitility</artifactId>
  <version>1.7.0</version>
  <scope>test</scope>
</dependency>

Puis codons une classe de test HttpBackendServiceTest largement inspirée de https://github.com/vert-x3/vertx-service-discovery/blob/master/vertx-service-discovery/src/test/java/io/vertx/servicediscovery/spi/ServiceDiscoveryBackendTest.java

package org.typeunsafe;

import io.vertx.core.Vertx;
import io.vertx.core.json.JsonObject;
import io.vertx.servicediscovery.types.HttpEndpoint;
import io.vertx.servicediscovery.Record;
import org.junit.Before;
import org.junit.Test;
import junit.framework.TestCase;
import java.util.concurrent.atomic.AtomicReference;
import static com.jayway.awaitility.Awaitility.await;

public class HttpBackendServiceTest extends TestCase {
  Vertx vertx;
  HttpBackendService httpBackend;

  @Before
  public void setUp() {
    vertx = Vertx.vertx();

J’initialise mon nouveau HttpBackendService et lui passe les information nécessaires pour accéder au seveur Express

    httpBackend = new HttpBackendService();
    httpBackend.init(Vertx.vertx(), new JsonObject()
      .put("host", "localhost")
      .put("port", 8080)
      .put("registerUri", "/register")
      .put("removeUri", "/remove")
      .put("updateUri", "/update")
      .put("recordsUri", "/records"));
  }

Je crée un Record pour simuler l’enregistrement d’un microservice et enduite je m’enregistre dans le backend avec httpBackend.store(record, handler). await().until(() -> reference.get() != null); me permet d’attendre le retour de ma requête pour enfin faire mon assertion.

  @Test
  public void testServiceInsertion() throws Exception {
    // create the microservice record
    Record record = HttpEndpoint.createRecord(
      "000",
      "127.0.0.1",
      9090,
      "/api"
    );
    AtomicReference<Record> reference = new AtomicReference<>();
    httpBackend.store(record, res -> {
      if(!res.succeeded()) {
        res.cause().printStackTrace();
      }
      reference.set(res.result());
    });    

    await().until(() -> reference.get() != null);
    System.out.println(reference.get().getName());
    System.out.println(reference.get().getRegistration());
    assertEquals("000", reference.get().getName());
  }
}

⚠️ Avant de lancer un mvn test, n’oubliez pas de lancer le backend Express avec la commande npm start ou node index.js

Donc normalement, si tout va bien vous devez avoir un backend et un ServiceDiscoveryBackend fonctionnels. Il est donc temps d’implémenter les microservices qui vont utiliser tout cela.

Publier votre nouvelle librairie

Pour que votre librairie/jar soit utilisable et “reconnaissable” par Maven, vous avez besoin de la publier en local:

mvn install:install-file -Dfile=target/vertx-service-discovery-backend-http-1.0-SNAPSHOT.jar \
-DgroupId=org.typeunsafe \
-DartifactId=vertx-service-discovery-backend-http \
-Dversion=1.0-SNAPSHOT  \
-Dpackaging=jar

je vous laisse adapter les noms au besoin

Il est temps de développer un microservice qui va aller s’enregistrer dans notre nouveau backend

Mise en oeuvre d’un 1er microservice

Nous allons faire un microservice “réactif” car c’est plus joli 😉. Je vais à nouveau créer un projet Maven (vous trouverez le code complet par ici: https://github.com/botsgarden/simple-microservice)

Avant toute chose ⚠️

Pour que votre microservice sache utiliser votre nouveau ServiceDiscoveryBackend, dans votre projet vous devez ajouter:

un répertoire src/main/resources/META-INF/sevices
dans ce répertoire un ficier io.vertx.servicediscovery.spi.ServiceDiscoveryBackend
avec le contenu suivant: org.typeunsafe.HttpBackendService (votre implémentation de ServiceDiscoveryBackend)

Un fichier `pom.xml`

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>org.typeunsafe</groupId>
  <artifactId>simple-microservice</artifactId>
  <version>1.0-SNAPSHOT</version>

  <properties>
    <vertx.version>3.4.2</vertx.version>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <main.verticle>org.typeunsafe.Hey</main.verticle>
  </properties>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.1</version>
        <configuration>
          <source>1.8</source>
          <target>1.8</target>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-shade-plugin</artifactId>
        <version>2.3</version>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>shade</goal>
            </goals>
            <configuration>
              <transformers>
                <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                  <manifestEntries>
                    <Main-Class>io.vertx.core.Launcher</Main-Class>
                    <Main-Verticle>${main.verticle}</Main-Verticle>
                  </manifestEntries>
                </transformer>
                <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
                  <resource>META-INF/services/io.vertx.core.spi.VerticleFactory</resource>
                </transformer>
              </transformers>
              <artifactSet>
              </artifactSet>
              <outputFile>${project.build.directory}/${project.artifactId}-${project.version}-fat.jar
              </outputFile>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

  <dependencies>
    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-core</artifactId>
      <version>${vertx.version}</version>
    </dependency>

    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-web</artifactId>
      <version>${vertx.version}</version>
    </dependency>

    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-web-client</artifactId>
      <version>${vertx.version}</version>
    </dependency>

    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-service-discovery</artifactId>
      <version>${vertx.version}</version>
    </dependency>

ici nous avons la référence à notre nouvelle librairie de discovery

    <dependency>
      <groupId>org.typeunsafe</groupId>
      <artifactId>vertx-service-discovery-backend-http</artifactId>
      <version>1.0-SNAPSHOT</version>
    </dependency>
  </dependencies>
</project>

Nous sommes maintenant prêts à développer notre microservice

Microservice `Hey.java`

package org.typeunsafe;

import io.vertx.rxjava.core.AbstractVerticle;
import io.vertx.core.Future;
import io.vertx.rxjava.core.http.HttpServer;
import io.vertx.core.json.JsonObject;

import io.vertx.rxjava.ext.web.Router;
import io.vertx.rxjava.ext.web.handler.StaticHandler;
import io.vertx.rxjava.ext.web.handler.BodyHandler;

import io.vertx.rxjava.servicediscovery.types.HttpEndpoint;
import io.vertx.rxjava.servicediscovery.ServiceDiscovery;

import io.vertx.servicediscovery.ServiceDiscoveryOptions;
import io.vertx.servicediscovery.Record;

import java.util.Optional;

public class Hey extends AbstractVerticle {
  
  private ServiceDiscovery discovery;
  private Record record;

  private void setDiscovery() {
    ServiceDiscoveryOptions serviceDiscoveryOptions = new ServiceDiscoveryOptions();

    // how to access to the backend

ici je donne les informations pour se connecter au backend Express et je crée une umstance de ServiceDiscovery

    Integer httpBackendPort = Integer.parseInt(Optional.ofNullable(System.getenv("HTTPBACKEND_PORT")).orElse("8080"));
    String httpBackendHost = Optional.ofNullable(System.getenv("HTTPBACKEND_HOST")).orElse("127.0.0.1");
    
    // Mount the service discovery backend (my http backend)
    discovery = ServiceDiscovery.create(
      vertx,
      serviceDiscoveryOptions.setBackendConfiguration(
        new JsonObject()
          .put("host", httpBackendHost)
          .put("port", httpBackendPort)
          .put("registerUri", "/register")
          .put("removeUri", "/remove")
          .put("updateUri", "/update")
          .put("recordsUri", "/records")
      ));
  }

je définis les informations relatives à mon microservice

  private void setRecord() {
    // Settings to record the service
    String serviceName = Optional.ofNullable(System.getenv("SERVICE_NAME")).orElse("hey");
    String serviceHost = Optional.ofNullable(System.getenv("SERVICE_HOST")).orElse("localhost"); // domain name
    Integer servicePort = Integer.parseInt(Optional.ofNullable(System.getenv("SERVICE_PORT")).orElse("9091")); 
    String serviceRoot = Optional.ofNullable(System.getenv("SERVICE_ROOT")).orElse("/api");

    // create the microservice record
    record = HttpEndpoint.createRecord(
      serviceName,
      serviceHost,
      servicePort,
      serviceRoot
    );
    // add some meta data
    record.setMetadata(new JsonObject()
      .put("kind", "http")
      .put("message", "Hello 🌍")
      .put("uri", "/ping")
    );

  }

la méthode stop du microservice permet de le désenregistrer du backend quand on arrête le microservice

  public void stop(Future<Void> stopFuture) {
    System.out.println("Unregistration process is started ("+record.getRegistration()+")...");

    discovery
      .rxUnpublish(record.getRegistration())
      .subscribe(
        successfulResult -> {
          System.out.println("👋 bye bye " + record.getRegistration());
          stopFuture.complete();
        },
        failure -> {
          failure.getCause().printStackTrace();
          System.out.println("😡 Unable to unpublish the microservice: " + failure.getMessage());
        }
      );
  }

je définis la ou les routes de mon microservice

  private Router defineRoutes(Router router) {
    
    router.route().handler(BodyHandler.create());

    router.get("/api/ping").handler(context -> {
      context.response()
        .putHeader("content-type", "application/json;charset=UTF-8")
        .end(
          new JsonObject().put("message", "🏓 pong!").toString()
        );
    });

    // serve static assets, see /resources/webroot directory
    router.route("/*").handler(StaticHandler.create());

    return router;
  }

  public void start() {

    setDiscovery();
    setRecord();

    /* === Define routes and start the server === */
    Router router = Router.router(vertx);
    defineRoutes(router);
    Integer httpPort = record.getLocation().getInteger("port");
    // if you use container or VM the httpPort and the servicePort could be different
    HttpServer server = vertx.createHttpServer();

    server
      .requestHandler(router::accept)
      .rxListen(httpPort)
      .subscribe(
        successfulHttpServer -> {
          System.out.println("🌍 Listening on " + successfulHttpServer.actualPort());
          /* === publish the microservice to the discovery backend === */

une fois mon microservice démarré, je le publie sur le backend

          discovery
            .rxPublish(record)
            .subscribe(
              succesfulRecord -> {
                System.out.println("😃 Microservice is published! " + succesfulRecord.getRegistration());
              },
              failure -> {
                System.out.println("😡 Not able to publish the microservice: " + failure.getMessage());
              }
            );
        },
        failure -> {
          System.out.println("😡 Houston, we have a problem: " + failure.getMessage());
        }
      );
  }
}

Maintenant vous pouvez builder puis lancer votre microservice:

java  -jar target/simple-microservice-1.0-SNAPSHOT-fat.jar

Si tout se passe bien, côté microservice, dans votre console vous devriez obtenir quelaue chose conmme ceci:

🤖 HttpBackendService initialized
Jun 29, 2017 12:43:03 PM io.vertx.core.impl.BlockedThreadChecker
WARNING: Thread Thread[vert.x-eventloop-thread-0,5,main] has been blocked for 2886 ms,
time limit is 2000
Jun 29, 2017 12:43:04 PM io.vertx.core.impl.BlockedThreadChecker
WARNING: Thread Thread[vert.x-eventloop-thread-0,5,main] has been blocked for 3889 ms,
time limit is 2000
Jun 29, 2017 12:43:05 PM io.vertx.core.impl.BlockedThreadChecker
WARNING: Thread Thread[vert.x-eventloop-thread-0,5,main] has been blocked for 4892 ms,
time limit is 2000
Jun 29, 2017 12:43:06 PM io.vertx.core.impl.launcher.commands.VertxIsolatedDeployer
INFO: Succeeded in deploying verticle
🌍 Listening on 9091
😃 Microservice is published! a9165560-56f1-48be-a872-6954e244facc

Et côté du backend Express vous devriez voir apparaître ceci:

🐼 New service added { location:
   { endpoint: 'http://localhost:9091/api',
     host: 'localhost',
     port: 9091,
     root: '/api',
     ssl: false },
  metadata: { kind: 'http', message: 'Hello 🌍', uri: '/ping' },
  name: 'hey',
  registration: 'a9165560-56f1-48be-a872-6954e244facc',
  status: 'UP',
  type: 'http-endpoint' }

Maintenant, codons une webapp qui va utiliser le backend pour trouver le microservice et enfin l’utiliser

Mise en oeuvre d’une WebApp

Une fois de plus, j’ai créé un projet Maven. Vous trouverez l’ensemble du code source ici: https://github.com/botsgarden/call-simple-microservice

Avant toute chose ⚠️

comme pour le microservice, pour utiliser votre nouveau ServiceDiscoveryBackend, dans votre projet vous devez ajouter:

un répertoire src/main/resources/META-INF/sevices
dans ce répertoire un ficier io.vertx.servicediscovery.spi.ServiceDiscoveryBackend
avec le contenu suivant: org.typeunsafe.HttpBackendService (votre implémentation de ServiceDiscoveryBackend)

Un fichier `pom.xml`

Le fichier pom.xml est quasi identique au précédent (à part les noms d’artifcat et de classe)

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>org.typeunsafe</groupId>
  <artifactId>call-simple-microservice</artifactId>
  <version>1.0-SNAPSHOT</version>

  <properties>
    <vertx.version>3.4.2</vertx.version>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <main.verticle>org.typeunsafe.Hello</main.verticle>
  </properties>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.1</version>
        <configuration>
          <source>1.8</source>
          <target>1.8</target>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-shade-plugin</artifactId>
        <version>2.3</version>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>shade</goal>
            </goals>
            <configuration>
              <transformers>
                <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                  <manifestEntries>
                    <Main-Class>io.vertx.core.Launcher</Main-Class>
                    <Main-Verticle>${main.verticle}</Main-Verticle>
                  </manifestEntries>
                </transformer>
                <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
                  <resource>META-INF/services/io.vertx.core.spi.VerticleFactory</resource>
                </transformer>
              </transformers>
              <artifactSet>
              </artifactSet>
              <outputFile>${project.build.directory}/${project.artifactId}-${project.version}-fat.jar
              </outputFile>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

  <dependencies>
    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-core</artifactId>
      <version>${vertx.version}</version>
    </dependency>

    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-rx-java</artifactId>
      <version>${vertx.version}</version>
    </dependency>

    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-web</artifactId>
      <version>${vertx.version}</version>
    </dependency>

    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-web-client</artifactId>
      <version>${vertx.version}</version>
    </dependency>

    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-service-discovery</artifactId>
      <version>${vertx.version}</version>
    </dependency>

    <dependency>
      <groupId>org.typeunsafe</groupId>
      <artifactId>vertx-service-discovery-backend-http</artifactId>
      <version>1.0-SNAPSHOT</version>
    </dependency>
  </dependencies>
</project>

WebApplication `Hello.java`

Et donc le code de notre webapp sera le suivant:

package org.typeunsafe;

import io.vertx.rxjava.core.AbstractVerticle;
import io.vertx.rxjava.core.http.HttpServer;
import io.vertx.core.json.JsonObject;

import io.vertx.rxjava.ext.web.Router;
import io.vertx.rxjava.ext.web.handler.BodyHandler;

import io.vertx.rxjava.servicediscovery.ServiceDiscovery;
import io.vertx.servicediscovery.ServiceDiscoveryOptions;
import io.vertx.rxjava.servicediscovery.ServiceReference;
import io.vertx.rxjava.ext.web.client.WebClient;


import java.util.Optional;

public class Hello extends AbstractVerticle {

Comme pour le microservice, j’ai besoin des informations pour accéder au backend

  private ServiceDiscovery discovery;

  private void setDiscovery() {
    ServiceDiscoveryOptions serviceDiscoveryOptions = new ServiceDiscoveryOptions();

    // how to access to the backend
    Integer httpBackendPort = Integer.parseInt(Optional.ofNullable(System.getenv("HTTPBACKEND_PORT")).orElse("8080"));
    String httpBackendHost = Optional.ofNullable(System.getenv("HTTPBACKEND_HOST")).orElse("127.0.0.1");
    
    // Mount the service discovery backend (my http backend)
    discovery = ServiceDiscovery.create(
      vertx,
      serviceDiscoveryOptions.setBackendConfiguration(
        new JsonObject()
          .put("host", httpBackendHost)
          .put("port", httpBackendPort)
          .put("registerUri", "/register")
          .put("removeUri", "/remove")
          .put("updateUri", "/update")
          .put("recordsUri", "/records")
      ));
  }

  public void start() {
    
    setDiscovery();

    Router router = Router.router(vertx);

    Integer httpPort = Integer.parseInt(Optional.ofNullable(System.getenv("PORT")).orElse("9095"));
    HttpServer server = vertx.createHttpServer();
    router.route().handler(BodyHandler.create());

    server
      .requestHandler(router::accept)
      .rxListen(httpPort)
      .subscribe(
        successfulHttpServer -> {
          System.out.println("🌍 Listening on " + successfulHttpServer.actualPort());

une fois mon serveur http démarré, je recherche mon microservice (que j’ai appelé “hey”): avec ce filtre r -> r.getName().equals("hey")

si je le trouve, je crée un client web qui me permet d’appeler mon microservice

et je crée une route pour la webapp qui déclenchera l’appel du microservice (client.get("/api/ping").send(...))

vous n’avez qu’à tester dans votre navigateur en appelant http://localhost:9095/call/ping et vous obtiendrez {"message":"🏓 pong!"}

          discovery
            .rxGetRecord(r -> r.getName().equals("hey"))
            .subscribe(
              successfulRecord -> {
                ServiceReference reference = discovery.getReference(successfulRecord);
                WebClient client = reference.getAs(WebClient.class);
                
                router.get("/call/ping").handler(context -> {
                  client.get("/api/ping").send(resp -> {

                    context.response()
                      .putHeader("content-type", "application/json;charset=UTF-8")
                      .end(
                        resp.result().body()
                      );

                  });
                });

              },
              failure -> {
                System.out.println("😡 Unable to discover the services: " + failure.getMessage());
              }
            );
        },
        failure -> {
          System.out.println("😡 Houston, we have a problem: " + failure.getMessage());
        }
      );
  }

}

Et voilà c’est enfin terminé. Je vous l’accorde c’était un peu long, mais cela vous donne de la matière pour jouer avec les microservices et Vert-x.

N’hésitez pas à commenter ou poser des questions (et contribuer)

🐼

Microservices avec Vert-x en Scala

Je viens de passer 2 semaines très “microservices”:

J’ai enfin eu l’occasion de voir le talk de Quentin sur les microservices https://twitter.com/alexandrejomin/status/860443891971088384 lors de notre passage chez @Xee_FR à Lille (vous pouvez aussi voir aussi ceci à Devoxx France Problèmes rencontrés en microservice (Quentin Adam) et Comment maintenir de la cohérence dans votre architecture microservices (Clément Delafargue)).

J’ai lu l’excellent Building Reactive Microservices in Java par @clementplop, où Clément explique comment écrire des microservices en Vert-x. (à voir aussi: Vert.X: Microservices Were Never So Easy (Clement Escoffier)

J’ai pu assister à la présentation “MODERNISEZ VOS APPLICATIONS AVEC RXJAVA ET VERT.X” par Thomas Segismont.

Du coup, je n’ai plus le choix, il faut que je m’y mette sérieusement et que je prépare quelques démos MicroServices pour mon job. Et autant que je vous en fasse profiter. 🙀 J’ai décidé de le faire en Scala (mon auto-formation), mais je vais tout faire pour que cela reste le plus lisible possible.

Architecture de mon exemple

⚠️ note: cette “architecture” est pensée pour être le plus simple possible à comprendre - cela ne signifie pas que ce soit ce qu’il faut utiliser en production - l’objectif est d’apprendre simplement. (je vais faire des microservices http) - je ne traiterais pas de des “Circuit Breakers”, ou des “Health Checks and Failovers”.

Lorsque vous avez un ensemble de microservices, c’est bien d’avoir un système qui permetten de référencer ces microservices pour facilement les “trouver”. Une application qui “consomme” un microservice doit avoir moyen de le référencer et l’utiliser sans pour autant connaître à l’avance son adresse (par ex: l’url du microservice). On parle de “location transparency” et de pattern “service discovery”. C’est à dire qu’un microservice, doit être capable d’expliquer lui-même comment on peut l’appeler et l’utiliser et ces informations sont stockées dans une “Service Discovery Infrastructure”.

Vert.x Service Discovery

Vert.x fournit tout un ensemble d’outils pour faire ça et se connecter à un service Consul, Zookeeper, … Mais Vert.x fournit aussi un “Discovery Backend - Redis” qui vous permet d’utiliser une base Redis comme annuaire de microservices (cf. Discovery Backend with Redis). C’est ce que je vais utiliser pour mon exemple.

Donc pour résumer, je vais faire:

microservice qui se “déclare” au “Discovery Backend”
un “consumer” qui va aller interroger le “Discovery Backend” pour obtenir une référence au microservice et ensuite l’utiliser

Création du microservice

Préparation

Tout d’abord nous allons créer un projet calculator-vx-service

mkdir calculator-vx-service
cd calculator-vx-service
mkdir -p src/{main,test}/{java,resources,scala}
mkdir lib project target

Créez un fichier build.sbt à la racine du projet:

name := "calculator-vx-service"

version := "1.0"

scalaVersion := "2.12.2"

libraryDependencies += "io.vertx" %% "vertx-web-scala" % "3.4.1"
libraryDependencies += "io.vertx" %% "vertx-service-discovery-scala" % "3.4.1"
libraryDependencies += "io.vertx" %% "vertx-service-discovery-backend-redis-scala" % "3.4.1"

Créez un fichier project/build.properties

sbt.version = 0.13.15

Code

Ensuite créez un fichier src/main/scala/Calculator.scala:

import io.vertx.core.json.JsonObject
import io.vertx.scala.core.Vertx
import io.vertx.scala.ext.web.Router
import io.vertx.scala.servicediscovery.types.HttpEndpoint
import io.vertx.scala.servicediscovery.{ServiceDiscovery, ServiceDiscoveryOptions}
import scala.concurrent.ExecutionContext.Implicits.global
import scala.util.{Failure, Success}

object Calculator {

    val vertx = Vertx.vertx()

    def main(args: Array[String]): Unit = {

      val server = vertx.createHttpServer()
      val router = Router.router(vertx)

      val httpPort = sys.env.get ("PORT").getOrElse("8080").toInt

      router.get("/api/add/:a/:b").handler(context => {
        val res: Integer = context.request.getParam("a").get.toInt + context.request.getParam("b").get.toInt
        context
          .response()
          .putHeader("content-type", "application/json;charset=UTF-8")
          .end(new JsonObject().put("result", res).encodePrettily())
      })

      router.get("/api/multiply/:a/:b").handler(context => {
        val res: Integer = context.request.getParam("a").get.toInt * context.request.getParam("b").get.toInt
        context
          .response()
          .putHeader("content-type", "application/json;charset=UTF-8")
          .end(new JsonObject().put("result", res).encodePrettily())

      })

      // home page
      router.get("/").handler(context => {
        context
          .response()
          .putHeader("content-type", "text/html;charset=UTF-8")
          .end("<h1>Hello 🌍</h1>")
      })

      println(s"🌍 Listening on $httpPort  - Enjoy 😄")
      server.requestHandler(router.accept _).listen(httpPort)
    }
}

Si vous compilez et lancez vous avez votre microservice de calcul qui vous permet de faire des additions et des multiplications:

http://localhost:8080/api/add/40/2
http://localhost:8080/api/multiply/21/2

Maintenant, on souhaite que notre microservice soit “découvrable”

Rendre le service “découvrable”

Pour cela, nous allons ajouter une méthode à notre objet Calculator


def discovery = {
  // Settings for the Redis backend
  val redisHost = sys.env.get("REDIS_HOST").getOrElse("127.0.0.1")
  val redisPort = sys.env.get("REDIS_PORT").getOrElse("6379").toInt
  val redisAuth = sys.env.get("REDIS_PASSWORD").getOrElse(null)
  val redisRecordsKey = sys.env.get("REDIS_RECORDS_KEY").getOrElse("scala-records")

  // Mount the service discovery backend (Redis)
  val discovery = ServiceDiscovery.create(vertx, ServiceDiscoveryOptions()
    .setBackendConfiguration(
      new JsonObject()
        .put("host", redisHost)
        .put("port", redisPort)
        .put("auth", redisAuth)
        .put("key", redisRecordsKey)
    )
  )

  // Settings for record the service
  val serviceName = sys.env.get("SERVICE_NAME").getOrElse("calculator")
  val serviceHost = sys.env.get("SERVICE_HOST").getOrElse("localhost") // domain name
  val servicePort = sys.env.get("SERVICE_PORT").getOrElse("8080").toInt // set to 80 on Clever Cloud
  val serviceRoot = sys.env.get("SERVICE_ROOT").getOrElse("/api")

  // create the microservice record
  val record = HttpEndpoint.createRecord(
    serviceName,
    serviceHost,
    servicePort,
    serviceRoot
  )

  discovery.publishFuture(record).onComplete{
    case Success(result) => println(s"😃 publication OK")
    case Failure(cause) => println(s"😡 publication KO: $cause")
  }
  // discovery.close() // or not
}

Et vous allez appeler cette méthode discovery dans la méthode main de Calculator

def main(args: Array[String]): Unit = {

  val server = vertx.createHttpServer()
  val router = Router.router(vertx)

  // use redis backend to publish service informations
  discovery

  val httpPort = sys.env.get ("PORT").getOrElse("8080").toInt

  // etc...

Pour résumer, qu’avons nous fait?

Nous créons un ServiceDiscovery (on se connecte à la base Redis - que vous n’oubliez pas de lancer):

val discovery = ServiceDiscovery.create(vertx, ServiceDiscoveryOptions()
  .setBackendConfiguration(
    new JsonObject()
      .put("host", redisHost)
      .put("port", redisPort)
      .put("auth", redisAuth)
      .put("key", redisRecordsKey)
  )
)

Nous créons un Record qui décrit notre microservice:

// create the microservice record
val record = HttpEndpoint.createRecord(
  serviceName,  // calculator
  serviceHost,  // localhost
  servicePort,  // 8080
  serviceRoot   // /api
)

Et ensuite on publie les informations du microservice vers Redis:

discovery.publishFuture(record).onComplete{
  case Success(result) => println(s"😃 publication OK")
  case Failure(cause) => println(s"😡 publication KO: $cause")
}

Si vous lancez, vous pouvez vérifier que les données du microservice sont bien présentes dans la base Redis:

Maintenant, nous allons créer un consommateur de ce microservice.

Création du consommateur

Préparation

Nous allons créer un autre projet calculator-vx-invoke qui appellera les 2 opérations de notre microservice.

mkdir calculator-vx-invoke
cd calculator-vx-invoke
mkdir -p src/{main,test}/{java,resources,scala}
mkdir lib project target

Créez un fichier build.sbt à la racine du projet:

name := "calculator-vx-invoke"

version := "1.0"

scalaVersion := "2.12.2"

libraryDependencies += "io.vertx" %% "vertx-web-client-scala" % "3.4.1"
libraryDependencies += "io.vertx" %% "vertx-service-discovery-scala" % "3.4.1"
libraryDependencies += "io.vertx" %% "vertx-service-discovery-backend-redis-scala" % "3.4.1"

Créez un fichier project/build.properties

sbt.version = 0.13.15

Code

Ensuite créez un fichier src/main/scala/InvokeCalculator.scala:

import io.vertx.core.json.JsonObject
import io.vertx.scala.core.Vertx
import io.vertx.scala.ext.web.client.WebClient
import io.vertx.scala.servicediscovery.{ServiceDiscovery, ServiceDiscoveryOptions}
import scala.concurrent.ExecutionContext.Implicits.global
import scala.util.{Failure, Success}

object InvokeCalculator {

  val vertx = Vertx.vertx()

  def main(args: Array[String]): Unit = {

    // Settings for the Redis backend
    val redisHost = sys.env.get("REDIS_HOST").getOrElse("127.0.0.1")
    val redisPort = sys.env.get("REDIS_PORT").getOrElse("6379").toInt
    val redisAuth = sys.env.get("REDIS_PASSWORD").getOrElse(null)
    val redisRecordsKey = sys.env.get("REDIS_RECORDS_KEY").getOrElse("scala-records")

    val discoveryService = ServiceDiscovery.create(vertx, ServiceDiscoveryOptions()
      .setBackendConfiguration(
        new JsonObject()
          .put("host", redisHost)
          .put("port", redisPort)
          .put("auth", redisAuth)
          .put("key", redisRecordsKey)
      )
    )

    // search service by name
    discoveryService.getRecordFuture(new JsonObject().put("name", "calculator")).onComplete{
      case Success(result) => {
        val reference = discoveryService.getReference(result)
        val client = reference.getAs(classOf[WebClient])
        client.get("/api/add/40/2").sendFuture().onComplete{
          case Success(result) => {
            println(result.body())
          }
          case Failure(cause) => {
            println(cause)
          }
        }

        client.get("/api/multiply/2/21").sendFuture().onComplete{
          case Success(result) => {
            println(result.body())
          }
          case Failure(cause) => {
            println(cause)
          }
        }

      }
      case Failure(cause) => {
        println(cause)
      }
    }
  }
}

Qu’avons nous fait?

Nous avons une fois de plus créé un ServiceDiscovery (on se connecte à la base Redis - que vous n’oubliez toujours pas de lancer):

val discoveryService = ServiceDiscovery.create(vertx, ServiceDiscoveryOptions()

Puis nous avons recherché le service par son nom avec notre discoveryService:

discoveryService.getRecordFuture(new JsonObject().put("name", "calculator")).onComplete{...

Une fois le microservice trouvé, je vais créer une référence à ce microservice à partir de laquelle je vais pouvoir obtenir un client qui va me permettre d’invoquer les opérations du microservice “calculator”:

val reference = discoveryService.getReference(result)
val client = reference.getAs(classOf[WebClient])

Remarque: classOf[WebClient] car mon service est de type http.

Et maintenant si je veux faire une addition, il me suffit d’écrire ceci:

client.get("/api/add/40/2").sendFuture().onComplete{
  case Success(result) => {
    println(result.body())
  }
  case Failure(cause) => {
    println(cause)
  }
}

Ou ceci pour une multiplication:

client.get("/api/multiply/2/21").sendFuture().onComplete{
  case Success(result) => {
    println(result.body())
  }
  case Failure(cause) => {
    println(cause)
  }
}

Voilà, vous n’avez plus qu’à lancer pour vérifier que cela fonctionne. Ce n’est pas plus compliqué que ça de faire du microservice avec Vert-x. 😁

Astuce pour déployer chez Clever-Cloud

J’ai commencé à jouer avec les microservices parceque j’ai des démonstrations à préparer pour mon job. Du coup je vous donne juste la démarche à suivre pour déployer sur Clever-Cloud.

Variables d’environnement

Vous devez bien sûr avoir un add-on Redis qui va vous fournir les variables d’environnement nécessaire, comme par exemple:

REDIS_HOST	yopyop-redis.services.clever-cloud.com
REDIS_PASSWORD	pouyoupouyou
REDIS_PORT	3062
REDIS_URL	redis://:pouyoupouyou@yopyop-redis.services.clever-cloud.com:3062

Une application web chez Clever doit écouter sur le port 8080, et de l’extérieur vous attaquerez votre microservice avec le port 80

Ce qui veut dire que quand vous allez déclarer votre microservice au backend Redis, il faudra préciser 80 comme port:

val record = HttpEndpoint.createRecord(
  "calculator",
  "your.domain.name",
  80,
  "/api"
)

Mais faire écouter le service sur 8080 lorsque vous le lancez:

server.requestHandler(router.accept _).listen(8080)

Build

Il y a 2 petites choses à ajouter:

dans build.sbt ajouter la ligne packageArchetype.java_application
il vous faudra une fichier projet/plugins.sbt avec cette ligne addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "0.8.0")

Et vous avez tout ce qu’il faut pour héberger vos microservices chez Clever 😉.

Vous avez moins d'une journée pour faire un ChatBot et le déployer sur Clever-Cloud

Vous avez moins d’une journée pour faire un ChatBot et le déployer

Challenge accepté?

Pour cela nous allons utiliser Hubot le bot bien connu de chez GitHub (cf. https://hubot.github.com/), et voir comment le déployer sur la plateforme Clever-Cloud (https://www.clever-cloud.com/) et l’utiliser avec Slack (https://slack.com/).

Voici donc le mode d’emploi 😀

Initialisation du bot

Pour initialiser un bot Hubot, il faudra installer le générateur Hubot pour Yeoman:

npm install -g yo generator-hubot

Puis tapez les commandes suivantes:

mkdir bob
cd bob
yo hubot

Répondez à toutes les questions. ⚠️ Lorsque le “wizard” vous pose la question Bot adapter? saisissez slack

Maintenant, le yo generator a créé le squelette de bot nécessaire dans votre répertoire.

Réglages

package.json

Supprimez dans package.json:

"engines": {
  "node": "0.10.x"
},

Ajoutez cette rubrique à votre fichier package.json: (cela permettra de lancer le bot)

"scripts":{
  "start": "./bin/hubot -a slack"
}

⚠️ remarque: nous allons utiliser l’adapter pour Slack, mais sachez qu’il en existe d’autre ou que vous pouvez écrire le votre simplement.

Supprimez les lignes suivantes:

"hubot-google-images": "^0.2.6",
"hubot-google-translate": "^0.2.0",
"hubot-heroku-keepalive": "^1.0.2",
"hubot-maps": "0.0.2",
"hubot-redis-brain": "0.0.3"

⚠️ remarque: nous n’avons pas besoin de hubot-redis-brain pour notre exemple.

external-scripts.json

Dans le fichier external-scripts.json, supprimez les lignes suivantes:

"hubot-heroku-keepalive",
"hubot-google-images",
"hubot-google-translate",
"hubot-maps",
"hubot-redis-brain"

hubot-scripts.json

Supprimez tout simplement le fichier hubot-scripts.json

Ecrire le cerveau du bot

Vous êtes maintenant prêts à coder “l’intelligence” de votre bot:

Dans le répertoire /scripts, supprimez le fichier example.coffe et créez au même endroit un fichier bob.js:

// Description:
//   <description of the scripts functionality>
//   this is my clever bot
'use strict';

module.exports =  (robot) =>  {

  robot.hear(/hello bob/, (res) => {
    res.send(`bonjour ${res.message.user.name}`);
  });

  robot.hear(/flute|zut|💩/i, (res) => {
    res.send(`😡 ${res.message.user.name}`);
  });

  // ok bob ça roule
  robot.hear(/(?=.*ok)(?=.*bob)(?=.*roule)/i, (res) => {
    res.send(`😀 ${res.message.user.name}`);
  });

};

⚠️ remarque: laissez bien la remarque d’en-tête, sinon Hubot va vous afficher un warning en vous expliquant que vous n’avez pas documenté.

Tester le bot

Vous pouvez tester votre bot directement sur votre poste. Mais tout d’abord, supprimez le répertoire node_modules, le 1er chargement de Hubot, chargera les dépendances (n’oubliez pas que nous avons modifé le fichier package.json), puis dans un terminal, tapez la commande suivante:

./bin/hubot

Après le chargement des dépendances, vous allez obtenir le prompt suivant:

bob>

Avec lequel vous allez pouvoir tester votre ChatBot

bob> hello bob
bob> bonjour Shell
zut
bob> 😡 Shell
bob> 💩
bob> 😡 Shell
ok bob tout roule?
bob> 😀 Shell

Du côté de Slack

Maintenant que votre bot est vivant, vous allez préparer tout ce qu’il faut pour l’accueillir.

Il est donc temps maintenant de paramétrer un “Slack”

Pré-requis

Vous devez avoir créé une team dans Slack

Ajouter l’application Hubot

allez sur la page des intégration de votre team: https://le-nom-de-votre-team.slack.com/apps
dans la zone de recherche tapez hubot
vous allez arriver sur la page de l’application Hubot
clickez sur Install
choisissez un nom pour votre bot et clickez sur Add Hubot Integration
vous allez arriver ensuite sur la page de setup qui vous propose un token de ce type (⚠️ que vous copiez pour utiliser plus loin)

HUBOT_SLACK_TOKEN=xoxb-1734567674356-f38scAAAtvuweHXXXXPCUoBJ

Si vous modifiez quelque chose, n’oubliez pas de clicker sur Save Integration

Du côté de Clever-Cloud

Maintenant que Slack est prêt, nous allons déployer notre bot chez Clever-Cloud

Préparation

Dans le dossier de votre bot (sur votre poste) tapez les commandes suivantes (pour transformer notre répertoire en repository git):

git init
git add .
git commit -m "first version"

⚠️ Remarque: vous avez besoin d’un compte Clever-Cloud et d’avoir associé votre clé SSH cf. https://console.clever-cloud.com/users/me/ssh-keys

Déployer

Maintenant, connectez vous sur Clever-Cloud https://console.clever-cloud.com, puis dans l’administration, procédez aux actions suivantes:

sélectionnez Add an application
clickez sur le bouton CREATE A BRAND NEW APP
sélectionnez runtime Node
à l’étape Scalability, clickez sur le bouton NEXT
donnez un nom à votre application (bob par exemple) à l’étape Information
clickez sur le bouton CREATE
à l’étape Add-on creation Provider, clickez sur le bouton I DON’T NEED ANY ADD-ON
dans les variables d’environnement, ajoutez: HUBOT_SLACK_TOKEN avec la valeur du token slack et aussi EXPRESS_PORT=8080 (Hubot est une application Express)
clickez sur le bouton NEXT

Vous allez obtenir un message de ce type:

git remote add clever git+ssh://git@push-par-clevercloud-customers.services.clever-cloud.com/app_e7a90a22-accc-4dc9-9b15-b4f9b11386a5.git
git push -u clever master

Tapez ces commandes dans le terminall à la racine de votre projet, et le déploiement va commencer (le code est publié chez Clever-Cloud, et cela va ensuite déclencher le déploiement).

Une fois le déploiement réussi, vous verrez apparaître Bob dans votre team (dans Slack). Il ne vous reste plus qu’à “inviter” Bob dans un “channel” et à discuter avec lui.

C’est tout

Disclaimer: Je bosse chez Clever-Cloud 😊

How to deploy Golo and Vert-x web app on Clever-Cloud

Today, I explain how to create quickly a web application with Golo and Vert-x, and then how to deploy it easyly on Clever-Cloud.

You need to install Golo (http://golo-lang.org/)

Create a Golo project

In a terminal, type this commands:

golo new vertx.golo.demo --type maven
cd vertx.golo.demo

The Golo CLI has generated a Golo project:

.
├── pom.xml
├── src
│   └── main
│       └── golo
│           └── main.golo

Update the pom.xml file

In order to compile correctly the project, you have to update the pom.xml file:

Change the Golo version

Replace:

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <golo.version>3.2.0-SNAPSHOT</golo.version>
  </properties>

By:

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <golo.version>3.2.0-M6</golo.version>
    <vertx.version>3.4.1</vertx.version>
  </properties>

Remark: 3.2.0-M6 is the current version number of the Golo project, and we’ll need the Vert-x version number too.

Add some dependencies:

  <dependencies>
    <dependency>
      <groupId>org.eclipse.golo</groupId>
      <artifactId>golo</artifactId>
      <version>${golo.version}</version>
    </dependency>

    <dependency>
      <groupId>com.googlecode.json-simple</groupId>
      <artifactId>json-simple</artifactId>
      <version>1.1.1</version>
    </dependency>

    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-core</artifactId>
      <version>${vertx.version}</version>
    </dependency>

    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-web</artifactId>
      <version>${vertx.version}</version>
    </dependency>

  </dependencies>

Change the main.golo file

We are going to write a very simple Vert-x web application with Golo. For that, replace the content of /src/main/golo/main.golo with this:

module vertx.golo.demo

import io.vertx.core.Vertx
import io.vertx.core.http.HttpServer
import io.vertx.ext.web.Router
import io.vertx.ext.web.handler

import gololang.JSON

let vertx = Vertx.vertx()

function main = |args| {

  let server = vertx: createHttpServer()
  let router = Router.router(vertx)
  router: route(): handler(BodyHandler.create())

  let port =  Integer.parseInt(System.getenv(): get("PORT") orIfNull "8080")

  router: get("/"): handler(|context| {
    context: response(): putHeader("content-type", "text/html;charset=UTF-8")
    context: response(): end("<h1>Hello 🌍</h1>", "UTF-8")
  })

  router: get("/hi"): handler(|context| {
    context: response(): putHeader("content-type", "application/json;charset=UTF-8")
    context: response(): end(JSON.stringify(DynamicObject(): message("Hi 😛")), "UTF-8")
  })

  server: requestHandler(|httpRequest| -> router: accept(httpRequest)): listen(port)

  println("listening on " + port)
}

Running the web application

Before running the application, you have to build it:

mvn package

And then, you can launch the application:

mvn exec:java

Now, you can test your web application, by calling http://localhost:8080 and http://localhost:8080/hi

Deploying the web application on Clever-Cloud

⚠️ Remark: you need a Clever-Cloud account and you added your SSH key to https://console.clever-cloud.com/users/me/ssh-keys (eg: you can use cat ~/.ssh/id_rsa.pub to get your public key)

Prepare your project

You need to create in your project directory a clevercloud directory with the jar.json file:

{
  "build": {
    "type": "maven",
    "goal": "package"
  },
  "deploy": {
    "jarName": "target/vertx.golo.demo-0.0.1-SNAPSHOT-jar-with-dependencies.jar"
  }
}

Now, your project looks like that:

.
├── clevercloud
│   └── jar.json
├── pom.xml
├── src
│   └── main
│       └── golo
│           └── main.golo

Then, at the root of the project directory, type:

git init
git add .

If you type the command: git status, you shoud get this:

On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

	new file:   .gitignore
	new file:   clevercloud/jar.json
	new file:   pom.xml
	new file:   src/main/golo/main.golo

Then type:

git commit -m "first version"

Now you have to switch to the Clever-Cloud web administration console

Deploying

In the administration console of your Clever-Cloud account:

select Add an application
click on the CREATE A BRAND NEW APP button
select the Java + Maven runtime
in the Scalability step, click on the NEXT button
fill in the name of the application in the Information step (eg: Vert-x-Golo-Demo)
click on the CREATE button
in the Add-on creation Provider, click on the I DON’T NEED ANY ADD-ON button
don’t change anything in the Environment Variables tab and click on the NEXT button

You’ll get a message like that:

git remote add clever git+ssh://git@push-par-clevercloud-customers.services.clever-cloud.com/app_c57bf90a-239d-4b8a-9aa6-c6e1b13c0149.git
git push -u clever master

Type these commands in your terminal at the root of your project directory, and then the deployment will start.

Now, you can see in the applications list panel a new application: Vert-x-Golo-Demo, you can change its domain name in the Domain Names panel, eg: vertx.golo.demo and now you can access to the web application with this url http://vertx.golo.demo.cleverapps.io/.

And of course you can test the hi route: http://vertx.golo.demo.cleverapps.io/hi.

That’s all. 😊 You have seen that it’s very easy to create web application with Golo and Vert-x, and even easier to deploy it on the cloud.

Disclaimer: I’m working at Clever-Cloud.

Faire une lib en Golo pour Java

Je vais vous expliquer comment créer une librairie en Golo re-utilisable ensuite avec vos autres projets Golo, ou Java.

Nous allons créer une librairie qui nous aide à utiliser les emojis dans nos applications 😛

Rappel: Golo, le site, c’est par là http://golo-lang.org/

Créer une librairie avec Golo

Je pars du principe que vous avez installé Golo. Dans un terminal, tapez ceci:

golo new emoji --type maven

Golo va vous générer le squelette d’un projet Maven et vous allez obtenir cette arborescence:

.
└── emoji
    ├── LICENSE
    ├── README.md
    ├── pom.xml
    └── src
        └── main
            └── golo
                └── main.golo

Allez dans main.golo et modifiez le code:

module org.typeunsafe.emoji

function panda_face = -> "🐼"
function alien = -> "👽"
function rabbit = -> "🐰"

Build

Avant de builder notre librairie il faut aller modifier le fichier pom.xml:

Changer `mainClass`

Dans votre pom.xml vous avez 2 <mainClass>emoji</mainClass>, il faut les remplacer par :

<mainClass>org.typeunsafe.emoji</mainClass>

Remarque: juste avant je vous ai fait modifier le nom du module Golo qui est en fait une classe Java

Changez le numero de version de Golo si nécessaire

Et remplacez, si besoin (tout dépend de la version de Golo utilisée):

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <golo.version>3.2.0-SNAPSHOT</golo.version>
  </properties>

par

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <golo.version>3.2.0-M5</golo.version>
  </properties>

Remarque 1: 3.2.0-M5 est la release courante de Golo
Remarque 2: si vous avez une version snapshot (vous travaillez avec la version de dev), vous pouvez rencontrer des problèmes de gestion de dépendances au moment du build.

Fixez un “bug” 🐝 du pom

Allez vérifier si les sections repositories et pluginRepositories existent et si ce n’est pas le cas ajoutez les:

  <repositories>
    <repository>
      <id>bintray</id>
      <name>Bintray</name>
      <url>https://jcenter.bintray.com</url>
    </repository>
  </repositories>

  <pluginRepositories>
    <pluginRepository>
      <id>bintray</id>
      <name>Bintray</name>
      <url>https://jcenter.bintray.com</url>
    </pluginRepository>
  </pluginRepositories>

Remarque 1: ce sera fixé dans la prochaine release
Remarque 2: c’est fixé dans la version de développement 🙂

Buildez ❗️

Il suffit d’utiliser la commande:

mvn package

et maintenant vous obtenez votre librairie au format jar:

/target/emoji-0.0.1-SNAPSHOT-jar-with-dependencies.jar

Utiliser notre nouvelle librairie avec Golo

Préalable

Pour pouvoir l’utiliser dans vos autres projet, il va falloir installer votre librairie dans votre maven local avec la commande mvn install:install-file:

mvn install:install-file  -Dfile=./target/emoji-0.0.1-SNAPSHOT-jar-with-dependencies.jar -DgroupId=org.typeunsafe -DartifactId=emoji -Dversion=0.0.1-SNAPSHOT -Dpackaging=jar -DgeneratePom=true

Utiliser la librairie dans un projet Golo

Créez un nouveau fichier Golo: golo new golo.uses.emoji --type maven
modifiez le numero de version de Golo dans le fichier pom.xml
ajoutez les sections <repositories> et <pluginRepositories>

ajouter la dépendance à votre librairie:

  <dependency>
    <groupId>org.typeunsafe</groupId>
    <artifactId>emoji</artifactId>
    <version>0.0.1-SNAPSHOT</version>
  </dependency>

Modifier le code de `src/main/golo/main.golo`

module golo.uses.emoji

import org.typeunsafe.emoji

function main = |args| {
  println(panda_face())
  println(alien())
  println(rabbit())
}

Buildez / Lancez

mvn package
mvn exec:java
🐼
👽
🐰

Et pour utiliser avec Java?

Utiliser la librairie dans un projet Java

Alors je me suis créé un petit projet Java:

.
├── pom.xml
├── src
│   └── app
│       └── Application.java

avec ce pom.xml (⚠️ je ne suis pas un spécialiste Maven):

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>org.typeunsafe</groupId>
  <artifactId>myapp</artifactId>
  <version>1.0-SNAPSHOT</version>
  <build>
    <sourceDirectory>src</sourceDirectory>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.8</source>
          <target>1.8</target>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-assembly-plugin</artifactId>
        <version>2.2.2</version>
        <configuration>
          <descriptorRefs>
            <descriptorRef>jar-with-dependencies</descriptorRef>
          </descriptorRefs>

          <archive>
            <manifest>
                <mainClass>app.Application</mainClass>
            </manifest>
          </archive>

          <appendAssemblyId>false</appendAssemblyId>
          <outputDirectory>./</outputDirectory>
          <finalName>${project.artifactId}</finalName>
        </configuration>
      </plugin>

    </plugins>
  </build>

  <dependencies>
    <dependency>
      <groupId>org.typeunsafe</groupId>
      <artifactId>emoji</artifactId>
      <version>0.0.1-SNAPSHOT</version>
    </dependency>
  </dependencies>
</project>

⚠️: on n’oublie surtout pas la dépendance à notre librairie:

<dependency>
  <groupId>org.typeunsafe</groupId>
  <artifactId>emoji</artifactId>
  <version>0.0.1-SNAPSHOT</version>
</dependency>

Le code Java:

En Golo un module (compilé) correspond à une classe Java avec des méthodes statiques qui sont les fonctions. Donc, nous faisons référence à notre librairie comme ceci import static org.typeunsafe.emoji.*; et notre code va ressembler à ceci:

package app;

import static org.typeunsafe.emoji.*;

public class Application {
    public static void main(String[] args) {
      System.out.println(panda_face());
      System.out.println(alien());
      System.out.println(rabbit());
    }
}

Buildez / Lancez

mvn compile assembly:single
java -jar myapp.jar
🐼
👽
🐰

Et voilà, vu les possibilités de Golo en termes de Promises, Workers, etc ,,, Vous pouvez apporter une touche “Dynamique” à vos projets Java très simplement. 🐼

Vous pouvez trouver les exemples de code ici:

monet.js - Maybe Monad

MonetJS - Maybe Monad

Donc la dernière fois nous avons parlé de la monade Identity avec le framework monet.js (monet.js - Maybe Monad). Pour ce Dimanche matin, je vais faire une 2ème partie un peu plus courte où je vais vous parler de Maybe.

Maybe?

Qu’est-ce qu’une Maybe? Pensez à un type qui peut changer de type 😜 ou à un type qui a 2 sous types. En fait une Maybe est une “boîte” 📦 qui contient une valeur (comme un container donc), et elle (la boîte) peut être de type None, c’est à dire que sa valeur est nulle ou de type Some, c’est à dire que sa valeur n’est pas nulle. Concrètement la Maybe est faite pour aider à gérer les null(s) et nous éviter pas mal d’exceptions/erreur, … En fait c’est la même chose que le type Option en Scala ou Java.

Utilisation

Voici quelques exemples simples pour montrer le fonctionnement de base:

Constructor(s)

let maybe = monet.Maybe.Some(42)

console.log(
	maybe.isSome(), // == true
	maybe.isNone() // == false
)

ou bien:

let maybe = monet.Maybe.None()

console.log(
	maybe.isSome(), // == false
	maybe.isNone() // == true
)

Mais lorsque l’on ne sait pas à l’avance si l’on va avoir null ou pas on utilise fromNull (une factory de Maybe):

let maybe = monet.Maybe.fromNull(42)

console.log(
	maybe.isSome(), // == true
	maybe.isNone() // == false
)

Obtenir la valeur d’une Maybe: `orSome`

Une Maybe n’a pas de méthode get, à la place nous avons orSome:

let maybe = monet.Maybe.fromNull("😄")

console.log(
	maybe.orSome("😡") // maybe.orSome("😡") == 😄
)

ou dans le cas d’un None:

let maybe = monet.Maybe.fromNull(null)

console.log(
	maybe.orSome("😡") // maybe.orSome("😡") == 😡
)

Obtenir une Maybe d’une Maybe: `orElse`

orElse ne retourne pas une valeur mais une Maybe:

dans le cas d’un `Some`

let maybe = monet.Maybe.fromNull("😄")
let newMaybe = maybe.orElse(monet.Maybe.Some("🤢"))

console.log(
	newMaybe, // { isValue: true, val: '😄' }
	newMaybe.isSome() // == true
)

dans le cas d’un `None`

let maybe = monet.Maybe.fromNull(null)
let newMaybe = maybe.orElse(monet.Maybe.Some("🤢"))

console.log(
	newMaybe, // { isValue: true, val: '🤢' }
	newMaybe.isSome() // == true
)

⚠️ Donc orElse retourne la Maybe initiale si c’est un Some ou la Maybe proposée si un None.

Ok, et en vrai, à quoi ça pourrait me servir?

… Pensez à une recherche en base de données:

let users = [
    {id:1, name:"bob", avatar:"🐼"}
  , {id:2, name:"sam", avatar:"🐻"}
  , {id:3, name:"jane", avatar:"🐰"}
  , {id:4, name:"john", avatar:"🐱"}
]

let getUserById = id => monet.Maybe.fromNull(users.find(u => u.id == id))

console.log(
	getUserById(3) // { isValue: true, val: { id: 3, name: 'jane', avatar: '🐰' } }
)
console.log(
	getUserById(6) // { isValue: false, val: null }
)

Dans le 1er cas j’obtiens un Some, sans le 2ème un None… ok … Mais comme c’est une monade, nous avons la méthode map❗️ et on peut faire plein de choses sympas

Maybe et `map()`

Avant, pour obtenir l’avatar d’un utilisateur que l’on cherche par son id, on aurait fait quelaue chose comme ceci:

users.find(u => u.id == 6).avatar

Et comme l’utilisateur n’existe pas, on obtient un joli:

TypeError: Cannot read property 'avatar' of undefined

Qui n’a jamais oublié de tester si il avait récupéré quelque chose ou pas avant de jouer avec dans son code ⁉️. Mais maintenant, vous pouvez faire ceci:

let getUserById = id => monet.Maybe.fromNull(users.find(u => u.id == id))
let getAvatar = u => u.avatar

console.log("display avatar of 2:",
	getUserById(2).map(getAvatar).orSome("👻")
)

console.log("display avatar of 6:",
	getUserById(6).map(getAvatar).orSome("👻") // be careful Number six doesn't exist ... I'm not a number, I'm a free man!
)

et vous obtiendrez ceci:

display avatar of 2: 🐻
display avatar of 6: 👻

et sans “plantage” ❗️😊

getUserById me retourne une monade Maybe M1
avec map je peux appliquer une transformation à la valeur M1 (sans la modifier)
et obtenir une nouvelle monade Maybe M2
sur laquelle je peux faire un orSome
✌️ donc plus de plantage idiot dans une recherche dans une base de données, collections, …

Un dernier pour la route 🍷

Une chose que j’adore ❤️ avec la Maybe, c’est le catamorphisme 🤦 (allez faire un tour ici https://fr.wikipedia.org/wiki/Catamorphisme ça pique 🌵 hein?). Plus simplement (et même si étymologiquement parlant c’est tiré par les 💇), pensez à catastrophe.

Dans monet.js la Maybe a une méthode cata qui va vous permettre de gérer les catastrophe. Cette méthode prend 2 arguments (en fait 2 callbacks ou 2 closures, appelez les comme vous le sentez), cata(left(), right(value)):

le 1èr callback, que l’on appellera left (l’argument le plus à gauche) qui ne prend aucune valeur en argument et qui est appelé quand la Maybe est un None
le 2ème callback, que l’on appellera right, qui prend comme argument la valeur de la Maybe quand c’est un Some

⚠️ right est aussi un moyen mémotechnique: right comme juste, “c’est ok, tu as tout juste 👍”.

Mais avec un petit bout de code ce sera plus parlant, rappelez vous de notre getUserById qui nous retourne une Maybe:

console.log(
	getUserById(3).cata(
		()=> {
			return "this 😡 does not exist"
		},
		(user) => {
			return `Hello ${user.avatar}`
		}
	)
)

Dans ce cas là, nous obtiendrons: Hello 🐰

console.log(
	getUserById(6).cata(
		()=> {
			return "this 😡 does not exist"
		},
		(user) => {
			return `Hello ${user.avatar}`
		}
	)
)

Dans ce cas là, nous obtiendrons: this 😡 does not exist

Fin de ce chapitre. Maybe est très pratique, mais dès fois, on aurait besoin qu’elle en fasse un tout petit peu plus. Donc la prochaine fois, je vous parlerais de Either.

Bon Dimanche 🍗 🍰 🍷

monet.js - Identity Monad

MonetJS - Identity Monad

Je trouve Scala de plus en plus intéressant, et certains concepts fonctionnels me manque en JavaScript. J’ai donc essayé divers frameworks JavaScript dits “fonctionnel” et j’en ai enfin trouvé un que je trouve simple à assimiler et à utiliser: monet.js. Donc, aujourd’hui nous parlon de la monad(e) Identity

Rappel: Monad?

⚠️ Disclaimer: ma définition ne va pas plaire à tout le monde, mais c’est un autre débat (ma mission c’est de montrer que le fonctionnel c’est pas compliqué et que ça peut servir.)

Pour faire court: une monad(e) est un container qui contient une valeur que l’on ne peut pas modifier (vous pouvez replacer “immutabilité” dans une conversation). Un peu comme ceci:

function monad(v) {
	let value = v
	this.get = () => value
	return this
}

et je peux l’utiliser comme ceci:

let m = new monad(42)
console.log("value of m", m.get())

… et je ne pourrais JAMAIS modifier value … mais en fait ce n’est pas une monade 😲

Pour que ce soit une monade,

il faut lui ajouter une méthode map qui permet d’appliquer à la valeur du container une opération (fonction/closure) retournant elle même une valeur et d’obtenir enfin une nouvelle monade sans changer la valeur de la précédente 😜:

function monad(v) {
	let value = v
	this.get = () => value
	this.map = (operation) => new this.constructor(operation(value))
	return this
}

Et on l’utilisera comme cela:

let m = new monad(40)
let m2 = m.map(n => n + 2)
m.get() == 40
m2.get() == 42

J’ai donc obtenu une nouvelle monade avec une valeur de 42 et ma 1ère monade reste avec une valeur de 40.

… Mais, mais, mais 🦆 …. Ce n’est pas encore une monade, c’est uniquement un Functor

Il faut encore lui ajouter une méthode flatMap, c’est un peu la même chose que pour map, mais dans ce cas là l’opération appliquée ne retourne pas une valeur “simple” mais aussi une monade (ou éventuellement un functor ou un container … mais ça peut se dicuter). Et du coup il faut “applatir” la monade retournée par l’opération pour éviter d’imbriquer des monades dans des monades (oui je sais 😜).

C’est à dire,

que l’on applique l’opération sur la valeur de la monade
on en récupère la nouvelle valeur
on retourne une nouvelle monade avec la nouvelle valeur

En code, c’est peut être un peu plus clair:

function monad(v) {
	let value = v
	this.get = () => value
	this.map = (operation) => new this.constructor(operation(value))
	this.flatMap = (operation) => new this.constructor(operation(value).get())
	return this
}

Et on l’utilisera comme cela:

let m = new monad(40)
let add1 = n => new monad(n+1)
m.flatMap(add1).flatMap(add1).get() == 42

Et pour mieux comprendre, vous n’avez qu’à essayer de faire:

m.map(add1).map(add1).get()

Maintenant passons à monet.js.

Identity

Tout ce que je viens d’expliquer est déjà implémenté dans monet.js sous le nom de monad Identity.

⚠️ vous pouvez utiliser monet.js dans votre browser ou avec node.js

Utilisation

C’est simple:

const monet = require('monet');

let monadWith40 = monet.Identity(40) // number 40 wrapped in an Identity box
let addOne = n => n +1

monadWith40.map(addOne).map(addOne).get() == 42

Et dans la vraie vie, est-ce que cela peut servir?

Alors, la monade Identity n’est pas forcément la monade la plus ✨ , mais oui elle peut servir.

Imaginons que vous ayez toutes les étapes d’un projet modélisées sous forme de fonctions comme ceci:

let coding = p => ({total: p.total + p.dev, dev: p.dev})

/* on pourrait aussi écrire:
function coding(p) {
  return {
    total: p.total + p.dev,
    dev: p.dev
  }
}
*/

let specifications = p => ({total: p.total + p.dev * 8.72 / 100, dev: p.dev})
let architecture = p => ({total: p.total + p.dev * 16.46 / 100, dev: p.dev})
let integrationAndTests = p => ({total: p.total + p.dev * 15.48 / 100, dev: p.dev})
let buildingAndPackaging = p => ({total: p.total + p.dev * 15.48 / 100, dev: p.dev})
let documentation = p => ({total: p.total + p.dev * 7.25 / 100, dev: p.dev})
let environmentLogistics = p => ({total: p.total + p.dev * 13.51 / 100, dev: p.dev})
let managementAndQuality = p => ({total: p.total + p.dev * 28.13 / 100, dev: p.dev})

Donc si je souhaite par exemple, connaître le nombre de jours de spécifications pour un projet où le dev fait 100 jours, je ferais ceci:

specifications({total:0,dev:100}).total == 8.72

si j’utilise monet.js, je “chiffrerais” mon projet comme ceci:

let startEstimation = monet.Identity({total:0, dev:100})

let globalEstimation =
	startEstimation
		.map(coding)
		.map(specifications)
		.map(architecture)
		.map(integrationAndTests)
		.map(buildingAndPackaging)
		.map(documentation)
		.map(environmentLogistics)
		.map(managementAndQuality)

console.log("Total:", globalEstimation.get()) // 205.02999999999997

Si j’ai besoin de n’avoir que la charge de documentation:

startEstimation.map(documentation).get()

Il y a aussi du `flatMap`

Je rappelle que c’est une monade 😉

On imagine par exemple que le chef de projet veut se faire une petite provision pour risque de 5 jours et qu’il l’implémente de cette façon:

let provision = p => monet.Identity({total: p.total + 5, dev: p.dev})

Comme cette fois-ci mon “étape” provision me retourne une monade, je vais utiliser flatMap pour l’intégrer dans mon chiffrage:

let globalEstimation =
	startEstimation
		.map(coding)
		.flatMap(provision)   // <-- c'est ici
		.map(specifications)
		.map(architecture)
		.map(integrationAndTests)
		.map(buildingAndPackaging)
		.map(documentation)
		.map(environmentLogistics)
		.map(managementAndQuality)

Voilà, ce n’est pas plus compliqué que ça.

PS: en ce qui concerne flatMap vous pouvez en entendre aussi parler sous le nom de bind oud de fmap.

A bientôt pour la suite avec Maybe, Some et None

K33G_ORG's blog

Programmation OnBoard sur Android avec Termux

Programmation OnBoard sur Android avec Termux

Petite prise en main rapide

Insaller quelques outils

1er programme en JavaScript

Look Ma! I’m doing Rust on my phone!

Créer un projet Rust

SOZU, le reverse-proxy magique, Partie 2

Sōzu, 1ers pas, 2ème partie

Pré-requis

Lancement

1ers contacts

Enlever des machines

Ajouter des machines

SOZU, le reverse-proxy magique

Jouer avec Sōzu - 1ers pas

1) Sōzu?

✨✨✨ Remerciements pour leurs explications

2) Mise en place du terrain de jeux

A) Le code source du site web

index.js

package.json

B) Notre projet Vagrant

Vagrantfile

Générer (et démarrer les VMs) les VM

Démarrer les webapps

C) Installation de Sōzu

404.html

503.html

demo.toml

3) On joue … Une 1ère fois!

A) 1er contact

B) Tuons des VMs

Arrêtons 2 VMs:

Arrêtons la dernière VM

4) On relance les sites

5) On fait une mise à jour de site

A) Nouveau projet Vagrant

B) Création, provisionning et lancement

Développer son propre Service Discovery Backend en mode REST pour Vert.x avec Node et Express

Développer son propre Service Discovery Backend pour Vert.x avec Node et Express

Quel type de Service Discovery Backend?

Implémenter ServiceDiscoveryBackend

mon fichier pom.xml

Implémentation de HttpBackendService

1ère utilisation de HttpBackendService, écrivons un test

Publier votre nouvelle librairie

Mise en oeuvre d’un 1er microservice

Avant toute chose ⚠️

Un fichier pom.xml

Microservice Hey.java

Mise en oeuvre d’une WebApp

Avant toute chose ⚠️

Un fichier pom.xml

WebApplication Hello.java

Microservices avec Vert-x en Scala

Microservices avec Vert-x en Scala

Architecture de mon exemple

Vert.x Service Discovery

Création du microservice

Préparation

Code

Rendre le service “découvrable”

Pour résumer, qu’avons nous fait?

Création du consommateur

Préparation

Code

Qu’avons nous fait?

Astuce pour déployer chez Clever-Cloud

Variables d’environnement

Build

Vous avez moins d'une journée pour faire un ChatBot et le déployer sur Clever-Cloud

Vous avez moins d’une journée pour faire un ChatBot et le déployer

Initialisation du bot

Réglages

package.json

external-scripts.json

hubot-scripts.json

Ecrire le cerveau du bot

Implémentation de `HttpBackendService`

1ère utilisation de `HttpBackendService`, écrivons un test

Un fichier `pom.xml`

Microservice `Hey.java`

Un fichier `pom.xml`

WebApplication `Hello.java`

Changer `mainClass`

Modifier le code de `src/main/golo/main.golo`

Obtenir la valeur d’une Maybe: `orSome`

Obtenir une Maybe d’une Maybe: `orElse`

dans le cas d’un `Some`

dans le cas d’un `None`

Maybe et `map()`

Il y a aussi du `flatMap`