Elixir ? C’est quoi ?

Une marque de bière !
Oui mais pas que. C’est aussi le nom d’un langage dynamique, fonctionnel, concurrentiel et fun !
On en parle de plus en plus et la communauté est très active avec une nouvelle version (1.2) qui date tout juste du mois de Mars.

Basé sur Erlang, et sa machine virtuelle Beam, créé par Ericsson pour être utilisé dans des appareils de télécommunications, Elixir en tire des propriétés intéressantes comme l’Open Telecom Platform (aka OTP, communication entre les services), la tolérance à la panne (supervisor) et le rechargement de code à chaud.

Pourquoi m’y intéresser ?

Ça peut paraître étonnant mais au jour d’aujourd’hui, je n’ai pas trouvé de technologie qui me donne entière satisfaction pour écrire un backend organisé en micro-applications ou micro-services

Java

  • même si Spring Boot fait du bon boulot pour rendre la tâche plus facile, il y a encore beaucoup de verbosité et de configuration pour organiser un backend en plusieurs applications indépendantes
  • les applications sont quand même assez longues à démarrer comparés à d’autres technologies (NodeJS par exemple) et ça joue sur le temps d’exécution des tests
  • le refactoring est assez lourd, même si mon IDE en fait une grosse partie (avez-vous déjà essayer de renommer une micro-application ?)

JavaScript

  • Express : à chaque fois que je redonne une chance à Express, je m’en veux dès que j’ai à configurer un ou deux middlewares (passportjs, connexions ssl, etc)
  • HapiJS : j’avais bien accroché (voir ici), surtout pour l’approche configuration plutôt que code (comme c’est le cas dans Express). Beaucoup de plugins pour faire des choses sympas mais quand on veut sortir des sentiers battus, aïe (je n’ai pas réussi à autoriser des connexions ssl…)

Je n’ai pas tout essayé (il faudrait peut-être que je donne une chance à Vert.X ou Wisdom) mais quitte à essayer quelque chose d’autre, j’ai choisi d’y aller à fond.

Et Elixir fait mieux ?

Je ne sais pas. Je débute.

Mais il y a quelques indices qui m’incitent à pousser l’apprentissage un peu loin :

  • programmation fonctionnelle -> ce dont j’ai besoin la plupart du temps dans mes backend REST, c’est des morceaux de code stateless qui appliquent un traitement à des données.
    Et bien c’est le cas d’usage parfait pour de la programmation fonctionnelle (parallélisme, enchaînements de tâches simples, etc)
  • utilisation des actors -> les actors sont un modèle de concurrence qui impliquent des process indépendants qui ne partagent pas d’état et qui communiquent par messages.
    Ça me paraît bien pour faire des micro-services indépendants, non ?
  • OTP -> l’Open Telecom Platform permet de faire communiquer simplement nos process et même de les superviser pour les redémarrer en cas de crash (tolérance à la panne) ainsi que de les monitorer (usage CPU, RAM, applications lancées, etc).
    Et tout ça, inclus de base !
  • mix -> mix est la chaîne d’outils d’Elixir. Elle permet de gérer les dépendances avec hex, de compiler, de lancer les tests, de générer la documentation à la JavaDoc, lancer des applications, etc.
    Ce qui me plaît le plus avec mix (outre le fait que c’est un vrai couteau suisse), c’est qu’il révèle une véritable culture du test (même les exemples de la documentation sont inclus dans l’exécution des tests…). Et ça, ça me plaît.

Penser autrement

Je ne vais pas entrer plus loin dans le détail. L’apprentissage d’Elixir est un peu déroutante quand on est habitué à la programmation objet (pattern matching partout, récursion à fond, pas de boucle, etc) mais elle en vaut la peine, ne serait-ce que pour apprendre à penser autrement.
Pour ça je vous conseille la lecture du très bon Programming Elixir 1.2 de Dave Thomas et surtout de réaliser les exercises qu’il contient. Ce n’est qu’à cette condition que votre lecture sera efficace. Et n’hésitez pas à partager vos implémentations, voici les miennes.

Mais ce n’est pas tout

Elixir a indubitablement quelque chose à apporter dans la conception de nos backend.
Ça se sent. Mais ce n’est pas tout.
On a un autre outil à notre disposition pour nous aider: Phoenix, LE framework web écrit en Elixir !

Ça sera l’objet de ma prochaine lecture, Programming Phoenix et de mon prochain post.

Think differently !

Commenter et partager

Let's Encrypt your Nginx !

Let’s Encrypt est un projet d’autorité de certification gratuite, automatisé et libre.

Concrètement, cela nous permet notamment d’avoir des sites et applications web en https, reconnues comme dignes de confiance par les navigateurs internet. Et cela sans payer et surtout basé sur des logiciels open source !

La beta est ouverte au public depuis jeudi, j’en ai donc profité pour remplacer les certificats auto-signés de mon GitLab sous Nginx par de vrais certificats “made by” Let’s Encrypt.

Installation et génération des certificats

L’installation de Let’s Encrypt est simple, il suffit de cloner le repository et de lancer un script qui va installer la bonne version du logiciel selon l’OS.

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto --help

La cible de Let’s Encrypt est de fournir un service permettant d’automatiser la génération des certificats et leur renouvellement. Cela marche bien pour un serveur Apache mais pas encore pour Nginx (ne pas oublier que c’est une beta).

On va donc lui demander de seulement générer les certifacts et de ne pas tout gérer. Pour cela, il suffit de stopper Nginx (la coupure ne sera pas très longue) et lancer la génération du certificat pour son domaine.

sudo nginx -s stop

./letsencrypt-auto certonly --standalone -d my-gitlab-domain.fr -d www.my-gitlab-domain.fr

Et voilà, les certifacts sont prềts dans /etc/letsencrypt/live/my-gitlab-domain.fr/

Redémarrer nginx et configurer le domaine

On redémarre le service Nginx.

sudo service nginx start

Et on modifie la configuration de notre serveur Nginx.

server {
	listen 443;
	listen [::]:443;

	# Make site accessible from http://localhost/
	server_name www.my-gitlab-domain.fr my-gitlab-domain.fr;

	ssl on;
  ssl_certificate /etc/letsencrypt/live/my-gitlab-domain.fr/cert.pem;
  ssl_certificate_key /etc/letsencrypt/live/my-gitlab-domain.fr/privkey.pem;

  ssl_stapling on;
  ssl_stapling_verify on;
  ssl_trusted_certificate /etc/letsencrypt/live/my-gitlab-domain.fr/fullchain.pem;

	location / {
    ...
  }
}

On recharge la configuration pour qu’elle soit prise en compte par Nginx.

sudo ngnix -s reload

Le tour est joué !

Renouvellement

Le certificat est valide pour 60 jours et sans renouvellement automatique pour Nginx pour l’instant, il suffira de relancer la commande pour le renouveller.

./letsencrypt-auto certonly --standalone -d my-gitlab-domain.fr -d www.my-gitlab-domain.fr

Sources:

Commenter et partager

Dans le cadre d’un projet basé sur Hapi.js (je reviendrai dessus dans un prochain article), j’ai pris un peu de temps pour améliorer la façon de déployer mes applications Node.js.

Voici ce que j’ai mis en place pour mes petits projets.

Déployer à chaque “git push”

Quoi de plus sympa qu’une application qui se déploie en production sur un simple commit/push ? Rien, on est bien d’accord ?
Je me suis donc inspiré de cet article pour mettre en place, sur mon serveur Ubuntu, un bare repository vers lequel je push lorsque je veux déployer mon application.

Contenu d'un bare repository
branches  config  description  HEAD  hooks  index  info  objects  refs

Je définis une action sur l’événement post-receive, ce qui se fait simplement en créant un fichier du même nom dans le répertoire hooks.

hooks/post-receive
#!/bin/sh
GIT_WORK_TREE=/opt/my-app git checkout -f
cd /opt/my-app
npm install

Ainsi à chaque push, un checkout est fait dans le repertoire d’installation de mon application (un git clone ayant était fait manuellement la première fois) puis un npm install pour mettre à jour mon application.

Facile, non ?

Oui. Un peu trop facile peut-être…

Mettre à jour son application d’un simple push c’est cool, mais encore faut-il s’assurer que la qualité est toujours au rendez-vous. Mon projet étant hébergé sous GitHub, j’utilise Travis CI comme outil d’intégration continu, parfaitement intégré puisqu’il déclenchera un build à chaque push sur GitHub.
Il se configure assez simplement grâce au fichier .travis.yml à la racine du projet.

.travis.yml (début)
sudo: false
language: node_js
node_js:
- 4.0
services: mongodb
addons:
  apt:
    sources:
    - mongodb-3.0-precise
    packages:
    - mongodb-org-server
...
...

On déclare le langage et runtime qu’on utilise (ici Node.js v4) et les services dont on a besoin (ici MongoDB en l’installant à chaque build).

.travis.yml (fin)
...
...
  ssh_known_hosts:
    - my.server.fr
after_success:
  - eval "$(ssh-agent -s)"
  - mkdir ~/.ssh
  - mv .travis-config ~/.ssh/config
  - mv .deploy.pem ~/.ssh/deploy.pem
  - chmod 600 ~/.ssh/deploy.pem
  - git remote add deploy ssh://user@my.server.fr/opt/my-app-bare
  - git push deploy master
before_install:
  - openssl aes-256-cbc -K $encrypted_d3a1e9dbde14_key -iv $encrypted_d3a1e9dbde14_iv
    -in .deploy.pem.enc -out .deploy.pem -d

Et vient la partie un peu plus velue.

Tout d’abord, on met en place la tuyauterie pour ssh en rajoutant notre serveur comme hôte de confiance (ssh_known_hosts) puis en décodant notre clé privée ssh (before_install) qui sera utilisé par Travis pour faire le push et qui avait été commit encryptée sur le repository.
La partie intéressante se trouve dans le after_success, juste après la tambouille pour initialiser la connexion ssh, on ajoute notre bare repository sous le nom deploy et on pousse notre branche master vers ce deploy.

Voilà, on a automatisé notre push vers notre serveur de production lorsqu’on push sur GitHub.

Bon, c’est bien joli tout ça mais en apparence on ne fait que dire à Travis de faire un push une fois le build terminé, ce qu’on savait déjà faire manuellement…

En apparence seulement, car ce qui est bien avec Travis c’est que si une cible test est présente dans notre package.json, il va l’exécuter automatiquement et la prendre en compte dans son résultat de build !
Ainsi si nos tests ne passent pas, le build est en échec et notre application n’est pas redéployée.
On peut même aller encore plus loin en fixant un seuil minimal de couverture de code de nos tests en dessous duquel ils sont considérés en échec. C’est ce que je fais avec Lab, l’outil de test de Hapi.js, avec la commande suivante qui fixe le seuil de couverture à 95% :

Lancement de tests
lab -c -t 95 -L

Sympa non ?

Oui. Mais c’est pas suffisant…

C’est pas suffisant parce que même si notre application est installée à la volée, il faut que notre serveur Node.js redémarre pour prendre en compte toutes les modifications. Pour ça, j’utilise PM2 en mode watch qui est un utilitaire qui va monitorer nos serveurs Node.js.

Ainsi lorsque des fichiers vont être mis à jour par notre push, PM2 va automatiquement redémarrer le serveur Node.js qu’on lui avait spécifié avec la commande :

pm2 start
pm2 start my-app.js

Cool !

PM2 est un outil vraiment sympa qui possède plein de fonctionnalités. Je vous recommande d’y jeter un oeil si vous ne connaissez pas.

Bonus

Bien, notre application est redéployée à chacun de nos push à condition que la qualité soit là et les modifications sont prises en compte sans qu’on ait à intervenir grâce à PM2.

Ce qui serait sympa, c’est d’avoir toutes les infos de build, de couverture de tests, versions de nos dépendances, etc, centralisées dans un seul endroit. Et les badges du README.md sont parfaits pour ça.

Les versions de dépendances npm (prod et dev) sont fournis par david-dm.org, le status de build par Travis et la couverture de code par Coverall.io qui se plugge lui-aussi sur GitHub.

Pour transmettre les informations à Coverralls, j’ai rajouté un script coverage dans package.json qui lance coveralls en sortie de rapport de Lab :

Lab et Coveralls
lab -c -L -r lcov | ./node_modules/.bin/coveralls

Je rajoute l’appel à ce script (npm run-script coverage) dans la cible after_success du fichier .travis.yml et le tour est joué.

Tous les outils utilisés ici sont gratuits pour des projets open-source.

Enjoy !

Commenter et partager

GitLab Backup

dans Divers

J’ai récemment choisi de migrer mes projets Git privés de Stash vers GitLab. Voilà une bonne occasion de remettre à plat mon système de backup Git qui consiste actuellement en un simple rsync des répertoires Git vers un serveur distant. Pas très pratique et surtout pas adapté…

J’ai trouvé cet article expliquant comment réaliser le backup d’un «bare» dépôt, ce qui est justement le cas de mes dépôts GitLab. Le seul hic, c’est qu’il faut le faire pour chaque dépôt et le refaire lorsqu’on ajoute un dépôt. Pas l’idéal..

J’ai donc pris un moment pour écrire un script Python qui permette de scanner les projets d’un serveur grâce à l’API REST de GitLab et de réaliser un clône de chacun de ces projets, tout en étant fortement configurable pour convenir aux besoins de tout le monde.

Ce script se nomme GitLabBackup et est disponible librement sur mon GitHub pour tous ceux qui cherchent une solution de backup à leur GitLab.

Enjoy ;)

Commenter et partager



Deuxième étape de ma cure de rattrapage Java après Effective Java, The Well-Grounded Java Developer est un livre introduisant les nouveautés de Java 7 ainsi que les langages polyglottes tournant sur la JVM. Il a été écrit par Ben Evans, membre du comité exécutif du Java Community Process, et Martijn Verburg, coleader du London JUG, entre autres.

J’ai choisi ce livre car il permet à la fois de faire le tour des nouveautés Java 7 (Project Coin, NIO.2), de rentrer dans des sujets techniques (injection de dépendances, concurrence, manipulation de .class et bytecode) ainsi que de faire un tour d’horizon des nouveaux langages développés sur la JVM (Groovy, Scala, Clojure), en terminant sur une touche de software craftsmanship : mixer de façon judicieuse tous ces langages pour tirer partie de leurs qualités respectives.

Je conseille fortement ce livre à tous ceux qui, comme moi, auraient mis Java entre parenthèses ces dernières années et qui seraient restés bloqués à Java 6. Même si j’aurais aimé que certains points soient un peu plus approfondis, on voit beaucoup de choses, on découvre un tas de sujets et on code aussi ! Et les pages défilent très vite.

J’ai vraiment apprécié la partie polyglotte et notamment le fait chacun des langages présentés soit approfondi en mettant l’accent sur un de leurs points forts, avec pour chacun un petit projet à coder :
    - GRails, framework web orienté “rapid web development” pour Groovy
    - ScalaTest, framework de tests pour Scala
    - Compojure, framework web pour Clojure

Un livre à garder dans sa bibliothèque et à ressortir souvent. Cerise sur le gâteau, pour l’achat en version papier, Manning offre l’ebook en multiples versions et non-limité dans le temps, ce qui est un vrai plus pour emporter sa lecture partout !

Commenter et partager


Jeudi dernier avait lieu une nouvelle session du Lava JUG : Bigdata et intégration en entreprise avec Jean-Baptiste Onofré.

Jean-Baptiste est membre de l’Apache Software Foundation et participe, ou a participé, à de nombreux projets de l’association et cette soirée était donc l’occasion de découvrir un peu plus ce monde là.

Avec une présentation fleuve de plus de trois heures, Jean-Baptiste nous a présenté, en véritable passionné, les arcanes de la fondation Apache. A commencer par le rôle que tout un chacun peut jouer en récupérant les sources et en proposant des “pull requests” (developer) jusqu’à devenir membre de l’association (ASF member) en passant par le rôle de _committer _et en participant aux PMCs (Project Management Committees).

Jean-Baptiste est aussi très impliqué dans les technologies tournant autour de l’OSGi, framework très connu pour son approche orientée services permettant un découplage faible et encourageant la réutilisabilité de composants.

C’est dans cet esprit qu’il nous a présenté un projet dont il est à l’origine et qu’il dirige en qualité de PMC Chair : Karaf et ses compagnons Cellar, Cave, … Véritable couteau suisse embarquant tout une flopée de fonctionnalités, Karaf permet de déployer des applications très variées et dans des environnements très différents.

Parmis ces fonctionnalités, on peut notamment citer : le redéploiement à chaud, une mise à jour à la volée de la configuration, un système de logging avec niveau de log modifiables dynamiquement, un shell Unix-like puissant entièrement développé from scratch et donc disponnible sur tous les OS ainsi qu’un système de provisioning (i.e. déploiement des artefacts ET des fichiers de configuration).

Complétée par une démo et ponctuée de devinettes sur l’origine des noms de divers projets Apache, ce fut une soirée enrichissante qui résonna parfaitement avec la présentation de Wisdom par Clément Escoffier et qui donne envie de mettre le pied dans un projet open source.

La session est à retrouver ici.

Encore merci à lui et au Lava JUG !

Commenter et partager


Je vous propose dans cet article de jouer un peu avec Docker pour monter une instance MongoDB sur un Ubuntu Server 14.04 et la rendre accessible depuis internet. Le but étant de fournir un base de données partagée entre plusieurs développeurs pour un projet assez simple.

Nous verrons donc comment récupérer une image Docker de Mongo qui va bien à travers Docker Hub et comment mettre en place quelques mécanismes de sécurité de base (authentification + connexions SSL).

L’article peut paraître assez long mais pas de panique, c’est dû aux explications et aux exemples. Le nombre de commandes à taper n’est pas très important.

C’est parti !

Continuer

J’étais jeudi soir au Lava JUG, pour une soirée MongoDB, animée par Tugdual Grall (alias “Tug”) qui a notamment travaillé neuf ans chez Oracle et qui est maintenant Technical Evangelist chez MongoDB. Le but de la soirée était de présenter les principes fondateurs de MongoDB qui est un SGBD de type NoSQL avec une approche orientée document.

La première partie de la présentation était consacrée à la théorie et aux opérations de base : présentation du modèle orienté document, différence par rapport aux SGBD traditionnels de type relationnel ainsi que par rapport aux autres SGBD de type NoSQL, les programmes mongod (le serveur) et mongo (le client) écrit majoritairement en C/C++, opérations CRUD, indexes, etc.

Le second temps était focalisé sur ce qu’apporte MongoDB dans le domaine des bases de données et notamment du “big data” : une scalabilité facilitée et une haute disponibilité grâce à des données qui peuvent être distribuées sur plusieurs instances de MongoDB, donc potentiellement sur plusieurs serveurs. Pour mettre en valeur ces qualités, la société MongoDB a développé un outil intéressant permettant de monter un cluster d’instances dans le cloud (ou sur un réseau d’entreprise) : MMS.
Une autre fonctionnalité très intéressante de MongoDB, même sans avoir des milliards de lignes de données, est l’hétérogénéité des données: un document peut-être enrichi dans le temps avec de nouvelles informations sans avoir à mettre à jour tous les documents existants du même type.

Pour la première fois, la soirée du jeudi était suivie d’un workshop le vendredi matin. Animé par Tug et organisé avec bienveillance par les gars du Lava JUG (café et croissants servis !). Mise en pratique des notions abordées la veille, cette séance était le parfait complément de la présentation.

Ne connaissant MongoDB que de nom avant jeudi dernier, j’ai bien aimé ce format présentation+workshop qui apporte un vrai plus dans la découverte de nouvelles technologies. Ajouté à ça l’énergie que met Tug dans le partage de ses connaissances et tout était réuni pour passer de bons moments.

La présentation, comme toutes les épisodes précédents, est à (re)découvrir ici !

Encore merci à Tugdual et au Lava JUG !

Commenter et partager

Effective Java

dans Lectures


Première étape de ma cure de rattrapage Java : repartir des bases de Java 6. Pour cela, j’avais déjà ce qu’il me fallait dans ma bibliothèque: Effective Java, Second Edition de Joshua Bloch que j’avais lu il y a quelques années.

Joshua Bloch est un développeur reconnu, il a notamment travaillé chez Sun Microsystems et Google et il a dirigé plusieurs spécifications et implémentations Java dont la fameuse Java Collections.

Effective Java est une mine de bonnes pratiques, basée sur l’expérience de son auteur pour écrire du code Java efficient, notamment lorsque l’on développe une bibliothèque dont l’API sera fortement exposée.
La seconde édition a été mise à jour pour Java 6, ce qui peut-être paraître un peu daté à l’heure de Java 8. Mais, même si quelques items ne sont plus forcément d’actualité avec l’avènement des nouvelles versions de Java (ex: concurrence), la majorité des conseils sont bons à prendre car ils ne sont pas liés au langage lui-même mais à la programmation objet en général.

Le livre est découpé en 78 items répartis en 10 parties, que je vais reprendre ici, en condensé, afin de servir de mémo.
Continuer

J’étais hier soir au Lava JUG, pour une soirée autour des langages fonctionnels, animée par Yannick Loiseau, maître de conférence à l’Université Blaise Pascal et fortement impliqué dans le développement logiciel, notamment dans les langages fonctionnels.

A l’heure où de plus en plus de langages informatiques “modernes” (Java 8, C++ 11, Groovy, Scala, Clojure, etc) ajoutent des touches de programmation fonctionnelle, voire en font leur paradigme principal, et un an après la présentation Lambda Bestiary de Rémi Forax; Yannick nous propose un retour sur les concepts qui se cachent derrière ce style de programmation. Et en deux heures, ça promettait d’être sportif !

Et ce le fut un peu ! Mais là où Yannick a été très bon, c’est qu’il s’est appuyé sur des concepts que la plupart des développeurs connaissent déjà en langage objet (tels que les design patterns classiques) en montrant comment on pouvait les réécrire en langage fonctionnel, la plupart du temps de façon plus concise et “naturelle”.

La plupart des concepts ont été revus : fonctions de 1er ordre, d’ordre supérieur, concepts de map, filter, fold, unfold, les closures, les lambda jusqu’aux concepts plus avancés de partialisation, curryfication et monades. Le tout parsemé d’exemples en Java 8 et Golo. Et ce rappel tombe à pic pour moi car mes prochaines lectures seront consacrées à Java 7 et 8 ainsi qu’à Groovy, Scala et Clojure. Timing parfait !

La présentation, comme toutes les épisodes précédents, est à (re)découvrir ici.

Encore merci à Yannick et au Lava JUG pour ces moments de partage !

Commenter et partager

Pierre PIRONIN

J’ai créé ce blog pour parler de ce qui se passe autour de moi dans le domaine du génie logiciel.
J’exposerai mes devs, mes idées, mes lectures, les faits qui m’intéressent et les événements auxquels je participe.

Bonne lecture !


Artisan développeur


Auvergne, France