Cet article fait suite à celui de Bertrand, afin de détailler certains sujets et présenter d’autres sessions auxquelles j’ai eu l’opportunité d’assister.
Connecting low power IoT devices with LoRa, MQTT, and The Things Network
De mon point de vue, l’IoT était vraiment à l’honneur cette année à Toulouse, notamment par la présence de The Things Network, ayant été invité par la Fondation Eclipse à donner un workshop et à tenir la première Keynote de la conférence.
Comme l’a mentionné Bertrand, cette équipe venue tout droit d’Amsterdam est en train de fédérer des communautés du monde entier autour de leur réseau dédié aux objets connectés, basé sur la technologie LoRa.
Alors qu’est-ce que LoRa ? Et qu’est-ce que The Things Network ?
LoRa
D’après le site de la LoRa Alliance (traduit par mes soins) :
LoRa est un diminutif pour LoRaWAN™: Low Power Wide Area Network (LPWAN).
LoRa est donc une spécification de communication sans fil basée sur les fréquences radio ISM (https://en.wikipedia.org/wiki/ISM_band).
Cette technologie est tout particulièrement adaptée comme couche de communication pour les objets connectés en ce qu’elle permet la localisation et la mobilité des appareils, à basse consommation, sans grosse installation de départ, ainsi qu’une communication bi-directionnelle.
Avec une simple antenne disposée en haut d’un immeuble en milieu urbain, ou dans un environnement plus dégagé, LoRa permet de connecter un nombre impressionnant d’appareils sans dégradation, bien plus qu’un routeur sans fil (WiFi, Bluetooth) et en consommant bien moins d’énergie et en étant moins onéreuse qu’un routeur 3G par exemple.
Quelques exemples d’utilisation:
- Réseaux électriques : prédire la consommation et produire de l’électricité en fonction des besoins réels
- Logistique : livraison avec une localisation plus précise
- Transport : appels d’urgence automatisés
- Santé : appareils de mesure de constantes
- Et tellement plus…
LoRa est en concurrence avec la technologie SigFox, que nous connaissons bien à Toulouse. Cependant son approche est différente, puisqu’à la différence de la technologie SigFox qui est propriétaire et induit des coûts de license, la spécification LoRa est libre.
Quelques relevés ayant été effectués par l’équipe de The Things Network, et autres caractéristiques :
- Environnement urbain dense : 500m à 3km
- Environnement rural : 10-50km (jusqu’à 92km lorsque très dégagé)
- Jusqu’à 10.000 appareils par routeur
- Jusqu’à 3 ans d’autonomie (à prendre avec des pincettes)
- Très basse consommation (et pas de « handshake »)
- License libre, en envoi et réception
- Pas de pré-requis à l’installation d’un tel réseau
- Couverture multiple (plusieurs routeurs peuvent relayer l’information).
Les appareils se connectant au réseau LoRa peuvent être classés en trois catégories :
- Liaison montante uniquement, l’appareil initie la communication et le serveur peut y répondre.
- L’appareil et le réseau se synchronisent sur une « fenêtre de tir » afin d’échanger des données.
- L’appareil est en écoute constante du réseau.
Evidemment les classes d’appareils influent sur leur consommation.
The Things Network
The Things Network est une initiative née à Amsterdam, pour construire un réseau mondial et libre permettant la communication entre objets connectés.
Après une campagne de crowfounding, les membres de l’équipe ont commencé la création d’une plateforme Web afin de permettre la connection d’appareils via des brokers.
Tout le code source applicatif de The Things Network est open source et disponible sur Github, pour aller de pair avec leur engagement pour permettre une vaste adoption de ces technologies.
En parallèle, une entité commerciale propose des Starter kits à visée éducative ainsi que des routeurs afin de permettre aux gens d’équiper leurs quartiers, leurs villes et d’initier le mouvement pour une couverture mondiale.
Des communautés existent déja de part le monde, principalement en Europe pour le moment. Ces communautés sont parfois à l’origine des membres de l’équipe de The Things Network, qui voyagent beaucoup afin de faire connaitre la technologie LoRa et leur projet, et parfois il s’agit d’initiatives spontanées.
A titre personnel, j’espère qu’une communauté verra le jour prochainement à Toulouse.
What every Java developer should know about AngularJS
Tout est dans le titre.
Cette session était dédiée aux développeurs plus habitués aux technologies backend et qui voulaient avoir une introduction au framework le plus en vogue actuellement côté frontend: AngularJS.
Ce workshop fut l’occasion de présenter succintement les controlleurs, les scopes, les services et autres directives, sous la forme d’un mini TP.
En tant que développeur fullstack ayant des bases d’AngularJS, je trouve que ce workshop a été bien mené, en plusieurs étapes afin d’itérer et d’introduire successivement de nouveaux concepts sur le petit cas concret présenté.
Les speakers ont même fait le choix de baser le code d’exemple sur TypeScript, afin de ne pas trop perturber leur audience plus habituée aux constructions objets classiques qu’à la spécification ECMAScript. Mes co-équipiers ont pu retrouver leurs petits dans un projet architecturé sur une base d’interfaces et d’implémentations, agrémenté de types génériques et autres héritages. Ils ont cependant eu affaire à la pauvreté du tooling Eclipse pour ce qui est du développement front.
Le tooling, parlons-en justement.
Tooling
Cette année les visiteurs ont pu assister à plusieurs sessions sur l’état des outils de développement intégrés à Eclipse. Voici un petit tour d’horizon des outils dont j’ai pu avoir un aperçu lors des sessions.
JSDT 2.0
Ce talk était dédié à la présentation du la nouvelle version des JavaScript Development Tools (JSDT), actuellement en cours de développement.
Les objectifs de JSDT 2.0 sont de supporter les méthodes et outils de l’état de l’art actuel du développement JavaScript moderne.
Actuellement, JSDT 2.0 profite d’un nouveau parseur bien plus efficace que le précédent, notamment capable de supporter la spécification ECMAScript 6.
Le reste des objectifs s’axent autour de l’intégration de gestionnaires de paquets (npm / bower), des « task builders » (grunt, gulp) ainsi que le support de Node.js et l’ajout d’outils de débugging et d’intégration avec les navigateurs, notamment Chrome.
The State of Docker and Vagrant Tooling in Eclipse
Chez DocDoku nous expérimentons déjà les outils Vagrant et Docker, notamment pour nos environnements de développement et d’intégration, afin de fournir à nos équipes une infrastructure immutable et des processus de déploiement répétables.
Dans cette présentation, j’ai pu avoir un aperçu de deux plugins, l’un pour l’intégration de Docker, et l’autre pour celle de Vagrant.
En l’état actuel, ces deux plugins présentent de nouvelles « perspectives » dans l’IDE Eclipse, qui permettent de faire tout (ou presque) ce qu’il est possible de faire en ligne de commande:
- Créer et gérer ses « box » Vagrant.
- Configurer son Vagrantfile.
- Créer et configurer ses machines virtuelles.
- Créer et gérer ses images Docker.
- Lister et manager ses containers Docker.
- Editer son Dockerfile.
Continuous Delivery: Pipeline As Code With Jenkins
Pour ma part, j’étais très curieux de voir ce qui allait être présenté dans ce talk. La perspective de pouvoir gérer ses builds sous forme de « pipelines » de traitements et la notion de « Continuous Delivery » (ainsi que le « Continuous Deployment » mais c’est un autre sujet) m’intéressent beaucoup.
Alors de quoi s’agit-t-il ? Principalement de ce que l’on pourrait décrire par la capacité d’orchestration, d’interruptibilité et de résilience de vos jobs de build. Rien que ça…
Comme décrit dans les slides de la présentation, que ce passe-t-il lorsque vous avez des jobs de build assez complexes, inter-dépendants, nécessitant des inputs d’opérateurs et éventuellement nécessitant de tourner en parallèle ?
Hormis le fait de créer de multiples jobs individuels que vous lierez par la suite en une cascade de builds à la chaîne, il n’y a pas de solution clé.
C’est ce problème que propose de résoudre le « Jenkins Pipeline Plugins », qui est en réalité un regroupement de plugins permettant d’orchestrer vos builds de manière plus fine. A la base de ce plugin se trouve un DSL, le « Pipeline DSL », qui permet de décrire l’enchainement des builds, sous forme d’étapes, et d’y attacher des options de configuration, comme le parallélisme pour n’en citer qu’une.
Il devient alors possible, par exemple, de configurer plusieurs dizaines de jobs similaires (à quelques variables près) formant de briques de bases (les dépendances d’un job de build suivant) et d’ordonner l’exécution de tous ces builds en parallèle, avant l’exécution du build suivant qui en dépend. Tout en spécifiant que la séquence de build complète doit stopper en cas d’échec d’un seul de ces builds de base (fail-fast).
Pour l’anecdote, le speaker a présenté exactement cet exemple, sur un cluster de build mis à sa disposition par un fournisseur « cloud » :
Evidemment on a tous le même dans notre garage…
Quoiqu’il en soit, j’étais assez intrigué par le choix d’un DSL, en opposition à une description déclarative via des fichiers de configuration.
Il est assez facile d’imaginer comment décrire via des structures de données simples telles que des maps et des collections, l’orchestration d’un job, et la description de chacune de ses étapes.
Je n’ai pas eu de réponse claire à ce sujet, si ce n’est le poids de l’histoire : la plupart des contributeurs étant des développeurs Java, un DSL (très proche de Java d’ailleurs) semblait un choix logique.
Conclusion
Pour ma première participation à un évènement comme celui-ci, je dois dire que je suis conquis. L’organisation était parfaite et la qualité des intervenants largement satisfaisante.
J’aurai plaisir à participer de nouveau à l’EclipseCon, et je recommande à tout développeur ayant la possibilité de s’y rendre, d’y aller sans hésiter.
L’ensemble des vidéos des Keynotes et des sessions est à retrouver sur la chaine Youtube de la Fondation Eclipse, ici.
EDIT 26/07/2016:
Un nouvel article est apparu sur le site de Fondation au sujet du tooling Docker, le voici: http://www.eclipse.org/community/eclipse_newsletter/2016/july/article2.php
