All posts in Open Source

Collaboration et efficacité au quotidien avec Git

Vous êtes chef de projets, développeur ou architecte et vous cherchez à gérer vos sources de façons innovante et efficace ?

Vous avez sûrement entendu parler de Git, le système de contrôle de version distribué en licence Open Source.
Mais l’avez-vous concrètement utilisé ?
Et le maîtrisez-vous ?

Devenu incontournable, Git est un gestionnaire polyvalent capable de gérer aussi bien les petits que les très gros projets informatiques.
Des équipes de développement réparties géographiquement peuvent bénéficier des fonctionnalités de Git, en permettant à chacun de travailler de manière déconnectée et de se resynchroniser au moment voulu.

Git s’impose aujourd’hui dans de nombreuses organisations mais ses fonctionnalités avancées le rendent inévitablement plus complexe que les gestionnaires de sources traditionnels.
Pour répondre à cet enjeu et maîtriser ses fonctions surpuissantes, pourquoi ne pas vous former à Git ?

Constitués de 50 % de travaux pratiques, profitez de 2 jours pour revoir les fondamentaux de Git, son utilisation efficiente au quotidien, maîtriser la gestion des branches et son usage en équipe.

Informations et inscriptions ici.

Prochaines sessions 2019 :
Toulouse, du 4 au 5 novembre
Paris, du 2 au 3 décembre

Retour sur EclipseCon France 2018

En septembre 2017, Oracle annonçait sa décision, en accord avec les autres grands acteurs du marché que sont IBM et RedHat, de transférer les technologies JavaEE à la fondation Eclipse pour «rendre le processus d’évolution de ces standards plus agile» [4].
Cette annonce a provoqué un séisme au sein de la communauté Java et a levé de grandes interrogations sur l’avenir de la plateforme, sur le positionnement du projet Eclipse MicroProfile et sur l’état d’avancement de cette transition.
Comme chaque année DocDoku1 était présent à l’EclipseCon France 2018, rendez-vous annuel de la communauté Eclipse à Toulouse.
Comme à chaque fois un thème est à l’honneur. Cette année il était légitime que ce soit le tour de la plateforme «entreprise» pour Java d’être sous le feu des projecteurs.
Étant moi même à l’affût d’information sur l’avenir de cette plateforme, j’ai profité de l’unique journée à laquelle j’ai pu venir, pour me concentrer sur JakartaEE et MicroProfile.

JakartaEE

JakartaEE

Au début de cette année, la communauté a choisi le nom JakartaEE pour désigner ce qu’Oracle appelait JavaEE. En effet Oracle a souhaité conserver ses droits sur la marque Java, il fallait donc trouver un autre nom.
Pourtant à la fin de l’année 2017 la fondation Eclipse avait annoncé la création du projet Eclipse Enterprise for Java (EE4J).

EE4J ou JakartaEE ?

Eclipse Enterprise for Java [5] est le projet «chapeau» pour tout ce qui concerne les technologies JavaEE, c’est à dire les API mais aussi les implémentations de référence transférées aussi par Oracle.
Eclipse JakartaEE Platform [6] est donc un sous-projet de EE4J qui reprend ce qu’était la spécifiaction de la plate-forme JavaEE : la définition d’un environnement d’exécution résultant de l’agrégation d’un ensemble spécifications d’API.
On trouve naturellement par ailleurs un sous-projet pour chaque API (Servlet, EJB, …) mais aussi les implémentations de références développées au sein de la fondation Eclipse ou par Oracle comme Yasson, EclipseLink, Glassfish, Grizzly, Jersey, …

Où en est la transition ?

Tout d’abord la procédure de transfert est longue car Oracle doit faire des vérifications (propriété intellectuelle, licence, …) pour chaque élément transféré.
En outre, les CTS2/TCK3 d’Oracle ne sont pas libres.
Nous apprenons que la transition se fera en plusieurs étapes :

  • Rendre JakartaEE 8 officiellement compatible avec JavaEE 8.C’est à dire obtenir une implémentation de référence JakartaEE qui passe les CTS/TCK actuels d’Oracle.
  • Fournir des CTS/TCK libres pour JakartaEE et s’assurer que l’implémentation de référence JakartaEE passe avec succès ces tests.
  • Une fois ces deux objectifs atteints JakartaEE pourra évoluer selon le processus normal de la fondation Eclipse.

En regardant l’état d’avancement on peut voir que la migration d’une bonne partie des projets est déjà bien avancée.

Un point sur les licences

Le système actuel de licence d’Oracle (CDDL4 et GPL5v2 des spécifications, API et RI ; TLDA6 pour l’usage des TCK et de la marque JavaEE) vont également changer en Eclipse Public License (EPLv2)

Comment la plateforme évoluera-t-elle ?

Les API sortent du giron de JCP7 et des JSR8 pour rejoindre le système des Working Group d’Eclipse et du processus de spécification de la fondation.
Grâce à ce changement, l’Eclipse Foundation espère une plus grande agilité et flexibilité.$
On nous indique que la stratégie d’évolution sera la standardisation a posteriori des bonnes idées qui ont fait leurs preuves à l’instar des exemples célèbres comme Hibernate, Weld, Jersey qui ont donné JPA, CDI et JAX-RS.
Notons que le JCP ne disparaît pas, il continue de fonctionner pour ce qui concerne JavaSE.

JakartaEE vs. MicroProfile

JavaEE 6 a vu l’arrivée de la notion de profil (Web Profile, Full Profile) au sein de la plateforme JavaEE. Le constat de l’époque étant que toutes les applications n’avaient pas besoin de l’ensemble des technologies de la plateforme.
Avec l’arrivée du Cloud Computing et succès des architectures micro-service (comprendre à base de VM), Eclipse MicroProfile propose une spécification de profil encore plus minimal, concurrent direct de Spring Boot [7], basé essentiellement sur les API standard CDI, JAX-RS et JSON-P auxquelles s’ajoutent quelques API nouvelles (Config, Health, Metrics, …).

MicroProfile

Eclipse MicroProfile [8] est donc une spécification alternative d’un ensemble d’API adaptées à la mise en œuvre d’applications architecturées sous forme de micro-service.
D’abord basé sur un nombre très limités d’API, la plateforme évolue comme le montre le tableau [Table:1]

Évolution de Microprofile
API/MicroProfile 1.0 1.1 1.2 1.3 1.4 2.0
CDI 1.2 2.0
JSON-P 1.0 1.1
JAX-RS 2.0 2.1
Config 1.0 1.1 1.2 1.3
Health Check 1.0
Metrics 1.0 1.1
Fault Tolerance 1.0 1.1
JWT Propagation 1.0 1.1
Open Tracing 1.0 1.1
Open API 1.0
Rest Client 1.0 1.1
JSON-B 1.0

Une des forces des spécifications ouvertes, comme pour JEE, est de permettre de fédérer divers éditeurs. Grâce à cela il existe plusieurs implémentations de MicroProfile (voir le tableau ci-dessous).

Implémentations de MicroProfile
Éditeur Implémentation
IBM Open Liberty [9]
RedHat WildFly Swarm [10]
Payara Payara Micro [11]
Apache Tomee [12]
Hammock Hammock [13]
Kumuluz KumuluzEE [14]

Avec les implémentations de MicroProfile, il est possible de déployer une application de plusieurs façons :

  • l’application, les dépendances et le runtime sont packagés dans un seul et même JAR exécutable.Format popularisé par Maven et Spring Boot, la taille de l’archive peut devenir si importante que cela peut poser des problèmes lors de déploiements fréquents (déploiement continu)
  • L’archive JAR contient l’environnement d’exécution, l’archive WAR les ressources métier et les éventuelles dépendances tierces.Avantage, Le WAR est plus léger à déployer car il ne contient que ce qui est spécifique au métier. Cela rappelle le mode de déploiement dans un serveur JavaEE.

12-Factor Application

Pour rappel, «Application à 12 facteurs» est une méthodologie pour construire des applications SAAS9.
Les 12 facteurs en question sont:

  1. Une seule base de code, versionnée (Codebase)
  2. Déclarer explicitement et isoler les dépendances (Dependencies)
  3. Ne pas stocker la configuration dans le code (Config)
  4. Tous les services sont vus comme des ressources «tierces» (Backing services)
  5. Stricte séparation entre la construction, la livraison et l’exécution d’une application (Build, release,run
  6. Les processus d’une application sont sans-étatProcesses
  7. Les services (Web) sont exposés via un port réseau (Port Binding)
  8. L’application se décompose en processus parallèles (Concurrency)
  9. L’application doit pouvoir être démarrée et arrêtée à la demande (Disposability)
  10. Garder les environnements (développement ,recette, production) aussi similaires que possible(Dev/Prod parity)
  11. Les logs sont un flux d’événements indépendant de la manière dont ils sont stockés (Logs)
  12. Les processus d’administration doivent s’exécuter dans le même environnement que l’application (Admin Process)

La présentation d’Emily Jiang [2] nous montre comment l’association de la plateforme MicroProfile et Kubernetes permettent de mettre en œuvre une application selon ces principes.

Codebase
Le code source de l’application est géré par Git (sur GitHub).
Dependencies
La construction et la gestion des dépendances est gérée par Maven.
Config
Les configmaps Kubernetes et l’API Config servent à injecter les propriétés de configuration dans l’application.
Build-Release-Run
Une plateforme d’intégration continue prend en charge le packaging pour chaque environnement.
Processes
L’API REST permet de mettre en œuvre les processus sans-état
Port Binding
Kubernetes et l’API Config sont responsable de l’affection des ports
Concurrency
Le découpage en micro-services et Kubernetes permettent de gérer la mise à l’échelle
Disposable
L’API Fault Tolerance permet de rendre l’application résiliente aux arrêts des processus.
Dev/Prod Parity
Kubernetes Helm permet de s’assurer que les différents environnements sont similaires
Logs
ELK10 permet d’indexer et de gérer les journaux.
Admin Process
L’outillage standard de Kubernetes (kubectl exec) permet des déclencher les processus d’administration.

Sécurité sans-état avec JWT

La sécurité est un aspect fondamental pour les applications d’entreprise, celui-ci est d’ailleurs pris en compte dans JavaEE (avec plus ou moins de souplesse) depuis les tous débuts de la plateforme.
Les architectures micro-service («SOA avec un nom sexy» dit Jean-Louis Monteiro [3]) ne font pas exception, mais l’aspect sans-état nécessaire pour faciliter la gestion de la charge change la donne.
Jean-Louis discute des inconvénients des différentes options d’authentification et de propagation des identités:

Basic Auth
présente plusieurs risques car :
– le couple login/motdepasse est envoyé à chaque requête,
– risque d’attaque DOS du référentiel de sécurité.
OAuth 2.0
basé sur une paire de jetons (access/refresh) recrée au final une session HTTP côté serveur pour garder une trace des jetons générés (et confiés au client) : cela consomme de la mémoire et du temps de calcul car chaque micro-service activé doit vérifier les tokens
JWT
est un format de jeton similaire à SAML mais codé en JSON. Ils contiennent des informations signées et potentiellement chiffrées. Dans ce cas de figure les informations signées, donc non altérables, sont stockées côté client.

L’association JWT + OAuth 2.0 permet de réduire considérablement les ressources nécessaires côté serveur : seules des références de jeton sont conservées (pour la révocation) et chaque service peut vérifier la signature du jeton de manière autonome.
Une présentation de la mise en œuvre de se mécanisme avec l’API JWT propagation de la plateforme MicroProfile vient enfin compléter la brillante démonstration.

JakartaEE + IOT

Une démonstration concrète de la mise en œuvre de technologies JavaEE et de l’Internet des Objets.
Payara Micro [11] est une déclinaison du serveur d’application Payara Server (basé sur Glassfish), pensée pour les micro-services «conteneurisés».
Ce micro-serveur d’application est compatible MicroProfile, mais malgré sa taille (moins de 70Mo),il supporte la mise en cluster, les connecteurs JCA, le Clustering, JCache, les EJB Timer, les événements CDI distribués.
Comment obtenir un serveur d’application si léger ? En faisant l’impasse sur les API historiques les moins pertinentes pour ce genre d’application m’a-t-on indiqué.
Grâce à sa légèreté, sans trop de compromis quant aux fonctionnalités, nous assistons à la démonstration d’une application capable d’agréger des données en provenance de capteurs (d’humidité dans le cas présent) à travers des applications JavaEE déployées sur des nano-ordinateur de type RaspberryPi.
Événements CDI distribués, connecteur JCA pour des échanges de messages asynchrone (MQTT), services REST sont au rendez-vous pour démontrer que les technologies JavaEE ont aussi leur place dans le monde des ressources contraintes de l’IOT.

Kubernetes : retour d’expérience

La fondation Eclipse est en cours de migration de sa plateforme d’intégration continue depuis Cloodbees Jenkins Enterprise vers une solution basée sur un cluster Kubernetes (OpenShift).
À partir de sa propre expérience de migration, Mikaël Barbero nous présente une excellente introduction à Kubernetes [1]
Kubernetes [15] est un système Open Source d’orchestration de conteneurs (VM) permettant d’automatiser le déploiement, la configuration, la gestion et la montée en charge d’applications ou de micro-service «conteneurisés».
Contrairement à la plateforme JavaEE où le conteneur – la machine virtuelle Java – est limitée à l’exécution de bytecode, les conteneurs (machines virtuelles) gérés par Kubernetes sont plus génériques car indépendants d’un OS, d’un langage et d’une plateforme pré-définis.
Là ou les serveurs d’application JavaEE permettaient d’orchestrer des machines virtuelles Java au sein d’un cluster, des outils comme Kubernetes réalisent sensiblement le même travail avec des conteneurs Docker dans le cas présent.
On perçoit comment ont évolués les usages ces dernières années: plutôt que de dépendre des capacités d’un serveur d’application JavaEE, limitées plus ou moins au monde Java, on préfère utiliser un outillage tiers pour gérer un cluster de machines virtuelles plus générales

Conclusion

Que ne lit-on pas ici et là sur la nature «monolithique» de la plateforme JavaEE, que l’on oppose à une architecture fragmentaire des micro-services.
Pourtant JavaEE/JakartaEE ne décrit pas comment doit être implémenté l’environnement d’exécution mais défini seulement un ensemble d’API qui doit être disponible et un format de packaging. Chaque type de composant est d’ores et déjà distribuable, alors pourquoi ne pourrait-on pas voir JEE comme la définition d’une PAAS11 tout à fait capable de construire des applications à base de micro-services ?
Est-ce la difficulté de morceler la plateforme comme ce qui a été réalisé lors des premiers profils (Web et Full) ? Est-ce la nécessité de conserver une compatibilité ascendante ?
Le succès des solutions MicroProfile (ou dans une certaine mesure Springboot ou Dropwizard) nous apprend que:

  • On doit pouvoir choisir les technologies strictement nécessaires à la mise en œuvre d’une application ou d’un composant applicatif.L’intégration de systèmes de modules dynamiques comme OSGI dans les implémentations des serveurs d’applications permet d’ores et déjà de ne charger en mémoire que les composants nécessaires, reste la configuration parfois complexe d’un domaine que l’on voudrait déléguer à des systèmes moins spécifiques.
  • Micro-service ou pas, le contexte des applications d’entreprise nécessite de disposer de solutions pour simplifier la mise en œuvre des aspects transverses (sécurité, transaction, distribution, tolérance aux pannes, métrologie, surveillance, journalisation, …).Il suffit, pour s’en convaincre, de regarder l’évolution des API de MicroProfile. Si les nouvelles API répondent à de nouveaux usages, elles peuvent également profiter à JakartaEE, mais à ce rythme MicroProfile restera-t-il «micro» ?
  • Le choix de la standardisation adoptée par Sun/Oracle ou la fondation Eclipse permet de fédérer les efforts des différents éditeurs et de favoriser la portabilité et l’interopérabilité.

Maintenant que JavaEE est en passe d’être libéré de la tutelle – soit-elle symbolique – d’Oracle, l’enthousiasme des participants à la conférence était au rendez-vous.
Grâce à la disponibilité de systèmes de virtualisation par conteneurs capables d’exécuter des composants (Java ou non); d’outils permettant la gestion d’infrastructures complexes de type Cluster ou Cloud; la modularité sera à mon avis le défi auquel devra répondre la plateforme JakartaEE, soit en intégrant ou définissant de nouveaux profils comme MicroProfile, soit plutôt en proposant une plateforme totalement modularisé pouvant être composée à la carte, à l’instar du travail réalisé sur JavaSE.
Demain, déployer une application JakartaEE consistera-t-il à découvrir à partir d’un paquetage les API utilisées, de provisionner un conteneur contenant le strict nécessaire et d’exécuter le tout ?
Merci enfin à toute l’équipe de la fondation Eclipse qui ont encore une fois réussi à organiser un événement fantastique.
Bravo à tous les conférenciers pour la variété et la qualité des présentations.

Références

1. Mikaël Barbero. 2018. Kubernetes 101. Retrieved from https://www.slideshare.net/mikaelbarbero/kubernetes-101-a-cluster-operating-system/
2. Emily Jiang. 2018. Build a 12-Factor Microservice in Half an Hour. Retrieved from https://www.eclipsecon.org/france2018/sites/default/files/slides/Build12FactorAppUsingMP.pptx
3. Jean-Louis Monteiro. 2018. Stateless Microservice Security via JWT, TomEE and MicroProfile. Retrieved from https://www.eclipsecon.org/france2018/sites/default/files/slides/2018_EclipseConEU_StatelessRESTSecurityWithMP-JWT.pdf
4. 2017. Opening Up Java EE – An Update. Retrieved from https://blogs.oracle.com/theaquarium/opening-up-ee-update
5. Eclipse Enterprise for Java. Retrieved from https://projects.eclipse.org/projects/ee4j
6. JakartaEE. Retrieved from http://microprofile.io/
7. Spring Boot. Retrieved from https://spring.io/projects/spring-boot
8. Eclipse MicroProfile. Retrieved from http://microprofile.io/
9. Open Liberty. Retrieved from https://openliberty.io/
10. WildFly Swarm. Retrieved from http://wildfly-swarm.io/
11. Payara. Retrieved from https://www.payara.fish/
12. Apache TomEE. Retrieved from http://tomee.apache.org/
13. Hammock. Retrieved from https://hammock-project.github.io/
14. KumuluzEE. Retrieved from https://ee.kumuluz.com/
15. Kubernetes. Retrieved from https://kubernetes.io/

  1. DocDoku est membre solution de la fondation Eclipse
  2. Compatibility Test Suite
  3. Tehnology Compatibility Kit
  4. Common Development and Distribution License
  5. Gnu Public License
  6. Technology License and Distribution Agreement
  7. Java Community Process
  8. Java Specification Request
  9. Software As A Service
  10. Elasticsearch, Logstash, Kibana
  11. Platform As A Service

DocDoku référencé par le pôle Innovation de l’UGAP

Le pôle Innovation de l’UGAP (Union des groupements d’achats publics), première centrale d’achat publique française, a choisi d’intégrer DocDoku à son référencement des logiciels multi-éditeurs par l’intermédiaire de son partenaire SCC, leader des solutions de service d’infrastructures informatiques.
Notre plateforme de digitalisation des métiers  et process ainsi que l’ensemble de nos savoir-faire sont à présent plus visibles et immédiatement accessibles pour l’ensemble des acheteurs publics français – administrations et établissements publics de l’Etat, collectivités territoriales, établissements publics de santé et secteur social.

Ce référencement intervient dans le contexte actuel de mutation des organisations qui cherchent à se transformer en digitalisant leurs métiers afin de maîtriser leurs dépenses tout en soutenant les acteurs français de l’innovation.

La plateforme DocDokuPLM dispose des briques essentielles à l’innovation collective, en mesure de répondre aux enjeux de transformation des organisations dans toutes leurs spécificités. Nos capacités permettent ainsi de répondre à des besoins aussi divers que :

Retrouvez-nous au 12ème forum technique des membres d’aerospace Valley

DocDoku participe au 12ème forum des adhérents

Du 16 au 17 mai 2017 se tiendra le 12 ème forum des adhérents d’Aerospace Valley, DocDoku y participera et y sera exposant.

« Digitalisation, quels risques, quelles opportunités pour nos filières ? »

C’est le thème du forum de cette année qui se tiendra au palais des Congrès d’Arcachon. Un thème majeur pour notre société puisque notre coeur de métier est la digitalisation des processus et des données métier des organisations.
Ces sera en effet l’occasion pour nous de présenter notre accélérateur de transformation digitale en notre plateforme open source DocDokuPLM.
N’hésitez donc pas à nous retrouver sur notre stand afin d’échanger sur vos enjeux et vos projets digitaux.
Pour plus d’informations sur le programme, rendez-vous ici sur le site d’Aerospace Valley.

DocDoku sera présent sur Smart Industries 2016, salon de l’industrie du futur

bannière de smart industries

Du 6 au 9 décembre 2016, se déroulera la deuxième édition du salon Smart Industries à Paris Nord Villepinte. DocDoku y participera pendant quatre jours pour oser avec vous l’industrie du futur.

Smart Industries c’est quoi ?

Smart Industries est un salon qui rassemble 300 exposants et 7000 visiteurs autour de 9 parcours thématiques sur l’industrie du futur. C’est également des conférences de qualité, des dizaines de start-up, des démonstrateurs, un grand concours pour les jeunes… le tout parrainé par la présidence de la république et encouragé par l’Alliance pour l’industrie du futur.

Présentation de la plateforme DocDokuPLM

DocDoku y présentera sa plateforme open source DocDokuPLM et ses nouveautés.
Modulaire et digitale, elle conviendra à toutes les organisations industrielles qui rêvent de gagner en productivité.
En effet, notre plateforme permet d’orchestrer les processus industriels, de structurer les données et collaborer efficacement.
N’hésitez-pas à venir nous rencontrer sur notre stand dans le hall 7 stand F25.

Infos pratiques et chiffres clés sur Smart Industries 2016 :

  • Vous pouvez vous inscrire gratuitement ici
  • Du 6 au 9 décembre 2016 à Paris Nord Villepinte (plan d’accès au parc ici)
  • 300 exposants
  • 7 000 visiteurs attendus
  • 1 espace simulation
  • 1 Connect+ Event autour des enjeux de l’IoT

OW2con 2016 : les logiciels open source répondent aux besoins des entreprises

Morgan tech lead logiciel libre

Morgan, notre tech lead

OW2con’16 une huitième édition toujours autant plébiscitée

Morgan, notre tech lead s’est rendu à lOW2con’16 à Paris pour présenter notre plateforme digitale de gestion des données industrielles DocDokuPLM et plus particulièrement son approche PaaS au service du métier des industriels

Retrouvez sa présentation en vidéo ici et en pdf ici.

Pour cette édition l’événement s’est déroulé dans les locaux de Mozilla Paris.

Organisé pour la huitième année consécutive, OW2con’16 est l’événement communautaire annuel qui rassemble les experts, architectes logiciels, développeurs informatiques, chefs de projet et les décideurs de partout dans le monde. Il s’agit d’un événement célèbre par ses présentations et démonstrations de projets open source pertinents et ainsi que sa table ronde.

Du code au produit : relever le défi de la distribution du logiciel open source

Le thème d’OW2con’16 était « Du code au produit : relever le défi de la distribution du logiciel open source”. Un thème qui nous allait donc à merveille. Les présentations ont su démontrer la maturité du logiciel open source, ainsi que sa capacité à s’adapter et à répondre aux différentes problématiques des entreprises.

Qualité et gouvernance logicielle, accessibilité, plate-forme applicative d’entreprise, sécurité, IoT et mobilité ainsi que cloud computing sont des thèmes qui ont été largement abordés lors de cette conférence.

Retour sur Intersud 2016 à Béziers

Evénement incontournable de rencontres industrielles de la grande région

Le 6 septembre 2016, l’équipe de DocDoku s’est rendue à Intersud Béziers, un événement unique, organisé par la CCI de Béziers au stade de la méditerranée. C’était l’occasion pour preneurs et donneurs d’ordres de la région Occitanie de se rencontrer. Pas moins de 122 personnes ont répondu présents à l’invitation.

L’événement était conçu pour les professionnels de l’industrie issus de domaines d’expertise très divers (énergie, aéronautique, numérique, robotique, santé, agroalimentaire, défense, systèmes embarqués ou encore chimie).

Le but était donc de se réunir autour d’entretiens individuels de 30 minutes. De quoi développer son réseau d’affaires et pouvoir construire des projets avec des acteurs forts de la région. Entre rendez-vous individuels et conférences, la journée s’est clôturée par un moment de convivialité et de rencontres autour d’une « troisième mi-temps ».

Intersud Beziers DocDoku et Sinox

Eric Descargues, co-fondateur de DocDoku et Emmanuel Mouton, PDG de Synox

Grâce à une organisation aux petits oignons et dans un cadre exceptionnel, nous avons pu rencontrer à la fois de nombreux donneurs d’ordres et futurs partenaires issus du tissu industriel occitan.

Notre objectif premier était de faire connaître notre plateforme digitale open source DocDokuPLM, dédiée à la gestion des données industrielles, tout en s’inscrivant durablement dans notre nouvelle région.

A l’année prochaine !

Retour sur l’EclipseCon France 2016 (partie 2)

eclipsecon

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.

iotConnecting 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 ?

LoRalora

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 :

  1. Liaison montante uniquement, l’appareil initie la communication et le serveur peut y répondre.
  2. L’appareil et le réseau se synchronisent sur une « fenêtre de tir » afin d’échanger des données.
  3. L’appareil est en écoute constante du réseau.

Evidemment les classes d’appareils influent sur leur consommation.

The Things Networkttn

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

angular

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 Jenkinsjenkins

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 » :

  • 336 CPUs
  • 1.032 TiB RAM.

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

Retour sur l’EclipseCon France 2016

StandDocDolu

Comme l’an dernier nous étions présents à l’EclipseCon France, événement incontournable dans le milieu du logiciel libre à Toulouse. Cette année encore l’organisation était sans faille, avec une grande diversité de thèmes (modélisation, IoT, devops…), chacun représenté par des intervenants de grande qualité.DocDokuPLM

DocDoku était en effet présent afin d’y présenter sa plateforme DocDokuPLM. Ceci a donné lieu à de nombreux échanges avec des acteurs industriels de Toulouse, ce qui a permis de constater que nous sommes au coeur de problématiques essentielles telles que l’interopérabilité, l’ouverture de la plate-forme, la sémantique des modèles.

Retour sur quelques présentations auxquelles j’ai eu la chance d’assister.

La modélisation à l’honneur avec Sirius, Papyrus et Capella

La modélisation de logiciels ou de systèmes est une des problématiques majeures développées au sein de la fondation Eclipse.

Étaient présents cette années, entre autres, le CEA avec l’outil Papyrus, Obeo avec l’outil Sirius, et PolarSys avec l’outil Capella.

Chaque outil a ses particularités. Pour ma part j’ai assisté au workshop sur Sirius animé par une équipe très motivée et maîtrisant parfaitement son outil. Sirius a la particularité de permettre la définition de Domain Specific Languages pour ensuite définir des modèles dans ce langage de modélisation.

Mention spéciale à l’équipe du CEA qui est venue avec une véritable usine en Lego de fabrication de petites voitures (en Lego elles aussi), la partie logicielle étant modélisée à l’aide de Papyrus.

Papyrus

Un IoT open source et innovant avec LoRa

L’IoT était très bien représenté, avec notamment la présence de Benjamin Cabé, animateur du meetup IoT-Toulouse, et Johan Stokking, de The Things Network qui a pour but de développer unLoRa réseau mondial et libre permettant la collecte et l’échange de données provenant d’objets connectés.

Ce projet est basé sur la technologie LoRa qui permet la communication à bas débit, par radio, alternative libre à SigFox, et soutenu par une alliance d’entreprises parmi lesquelles nous retrouvons Orange et Bouygues Télécom.

Eclipse Che : la révolution de l’environnement de développement

Eclipse Che, développé par Codenvy (connu pour son service d’IDE dans le cloud) est un outil permettant de gérer des environnements de développement virtualisés dans le cloud.

EclipseCheEclipse Che permet de mettre en place dans le cloud, non seulement un IDE, mais également un environnement d’exécution et de test automatisé du code.

Ceci permet de ne pas avoir à installer tout un environnement de développement/exécution/test sur la machine de chaque développeur. L’IDE en ligne renforce également le travail collaboratif : plusieurs développeurs peuvent éditer en même temps un même fichier (comme sur Google Docs).

L’équipe d’Eclipse Che est jeune et dynamique et de nombreuses améliorations sont à venir en ce qui concerne le pair programing et les tests JUnit.

TypeScript: du typage pour améliorer la scalabilité de JavaScript

TypeScript

Saurez-vous trouver les membres de DocDoku sur cette photo ?

TypeScript nous a été présenté par Sébastien Pertus, évangéliste technique chez Microsoft. TypeScript est en effet un projet libre développé par Microsoft, principalement par Anders Hejlsberg qui est aussi le principal inventeur de C#.

TypeScriptLogoCette présentation était à la fois pleine d’humour et abordait des questions techniques pointues avec des démonstrations de programmation très pertinentes.

TypeScript est à considérer comme un langage de programmation à part entière qui est trans-compilé en JavaScript. Ce nouveau langage ajoute à JavaScript de nombreuses fonctionnalités de typage comparables à ce qu’on retrouve dans le langage Java. On peut citer le typage statique, les classes, les interfaces…

De nombreuses fonctionnalités ajoutés par TypeScript sont maintenant présentes dans ECMAScript Edition 6, mais TypeScript conserve une longueur d’avance en proposant par exemple la notion de décorateur qui permet de programmer avec des annotations. D’autres améliorations sont prévues dans la future version de Javascript comme par exemple les non nullables types.

Tuleap : l’ALM open source

Enfin, l’aspect gestion de cycle de vie des applications/gestion de projet était également présent avec Tuleap développé par Enalean. Tuleap propose un outil de gestion de projet complet intégrant tous les aspects de tous les processus de développement (Cycle en V, Kaban, Scrum, Extreme Programming etc):

  • Intégration des principaux systèmes de configuration  (Git, SVN, CVS)
  • Intégration continue (Jenkins)
  • Wiki
  • Revue de code
  • Gestionnaire de bugs
  • Gestionnaire de post-it configurable style Trello.

 

Encore un grand merci à tous les organisateurs et conférenciers de cet événement et à l’année prochaine !

2016 sera consacrée à coupler l’IoT avec notre plateforme DocDokuPLM

2016 sera consacrée à l’Internet of Things (IoT)

Comme nous l’avions en effet évoqué lors du SIANE 2015, salon des partenaires de l’Industrie du grand sud, sur lequel nous exposions au sein de l’espace de l’Usine du Futur, 2016 sera en effet consacrée à l’IoT pour DocDoku.

La problématique : comment compléter les données théoriques avec les données terrain ?

Notre équipe R&D continue en effet d’innover en travaillant sur une nouvelle brique de notre pateforme capable de rapprocher et d’analyser avec pertinence les données théoriques issues du PLM et les données captées en situation réelle (capteurs physiques restituant au travers d’un IoT gateway les données au PLM).

La demande des industriels pour l’usine du future nous conforte en effet dans notre effort pour compléter notre plateforme DocDokuPLM avec une brique dédiée notamment à la maintenance prédictive permettant ainsi d’améliorer la prédiction des pannes et d’anticiper les défaillances des équipements / produits. Mon prochain billet sera spécialement dédié à ce sujet.

Retour sur notre présence à l’EclipseCon


La seconde édition de l’EclipseCon à Toulouse les 24 et 25 juin derniers, a réuni plus de 300 visiteurs et 18 exposants, tous accueillis dans une ambiance conviviale et chaleureuse par la responsable des relations partenaires, Perri Lavergne.

DocDokuPLM plébiscité par la communauté et la presse

En tant que partenaire de l’événement, aux côtés d’Obeo, IBM, Thales, Codenvy, Eurotech, Intel ou encore Red Hat, une conférence nous a été consacrée nous permettant ainsi de faire découvrir notre plateforme à la communauté Eclipse.

Parmi les visiteurs sur notre stand, nous avons eu un échange passionnant avec Eike Stepper, Consultant Senior IT Software Architect, au sujet du projet CDO (Connected Data Objects) sur la comparaison de graphes dont l’implémentation serait appropriée aux Product Breakdown Structure de notre plateforme.

Nous avons également échangé avec Wayne Beaton, Directeur des projets Open Source de la Fondation Eclipse, au sujet de l’étendue de  l’écosystème Eclipse et de ses nombreuses applications dans l’industrie.

Enfin, les journalistes de Linux Magazine et de L’embarqué étaient également au rendez-vous et en ont profité pour en savoir davantage sur DocDokuPLM.

Des conférences autour de projets novateurs Eclipse

Parmi les différentes conférences données lors de la convention, nous avons pu assister à celle du projet Oomph: l’installateur Eclipse. Celui-ci permet aux nouveaux utilisateurs dès leur première utilisation, des fonctionnalités poussées d’Eclipse. Permettant ainsi une installation très facile et des mises à jour automatisées, l’installateur est aussi capable de paramétrer très facilement son environnement de travail.

Un autre projet très prometteur nous a été présenté: Eclipse Che. Il existe déjà depuis quelques temps, et la société Codeenvy offrant une plateforme de développement nous a présenté tout son potentiel.

En couplant Eclipse Che à Docker, logiciel open source qui automatise le déploiement d’applications dans des conteneurs logiciels, Codeenvy propose un environnement de travail en ligne, déjà paramétré pour tout nouvel utilisateur. L’utilisation via github étant déjà intégré par le système de pull request (demande de validation de mise à jour), cet outil pourrait être l’avenir pour les projets open source.

Nous avons enfin assisté à des conférences autour d’Eclipse sur notamment de nouveaux plugins, l’intégration des technologies IoT dans Eclipse, la communauté et comment participer au projet. Nous avons particulièrement apprécié la conférence sur la place de l’informatique dans les énergies renouvelables : comment celles-ci peuvent-elles répondre aux problématiques que posent l’intégration des énergies renouvelables dans notre consommation et quelles sont les perspectives que l’on peut avoir à court et long terme ?

Pour finir, nous souhaitons remercier l’équipe de la Fondation Eclipse ainsi que les intervenants pour leur accueil et leur dynamisme.

Projet d’innovation : revue de conception produit en temps réel sur le web

Depuis début 2014, nous travaillons en collaboration avec l’IRIT et plus particulièrement l’équipe Vortex, sur un projet de recherche appliquée dans le cadre de l’appel à projets régional Agile IT 2013.

Objectif du projet

L’objectif de ce projet était de créer un Environnement Virtuel Collaboratif (EVC) rendant accessible, manipulable et modifiable la maquette numérique des produits à tous les métiers de l’entreprise.

D’un point de vue logiciel, il s’agissait donc de développer le module web pour :

  • la visualisation collaborative 3D web temps réel,
  • l’édition et la manipulation web de pièces 3D.

Utilisable depuis un navigateur internet, sans qu’il soit nécessaire d’installer le moindre plugin, ce composant logiciel fait donc partie intégrante de notre plateforme digitale open source DocDokuPLM

Fonctionnalités et bénéfices

Bien plus qu’un simple partage d’écrans, notre plateforme permet donc désormais à la fois de réaliser le design du produit en 3D tout en gérant son cycle de vie depuis le même outil, accessible de n’importe où au travers de votre navigateur.

Véritablement extensible, ce module permet de gérer plusieurs EVC (room en anglais) avec plusieurs utilisateurs simultanés. Entièrement développé grâce aux nouveaux standards du Web, ce dernier ne nécessite aucune installation complémentaire.

De plus, ce module offre toute la sécurité que l’on peut en attendre : les participants invités sur l’EVC (ou la room) pour la revue n’auront jamais accès aux documents ou articles sur lesquels ils n’ont pas les droits d’accès.

La vidéo ci-dessous (filmée par téléphone) montre l’utilisation de cette fonctionnalité.

L’ordinateur de droite initie la réunion de groupe (EVC ou room) et invite les utilisateurs connectés (sur l’autre PC à gauche).

Nous vous invitons également à découvrir gratuitement tout cela en créant un compte et un espace de travail sur notre plateforme cloud : http://www.docdokuplm.net

DocDoku rencontre les industriels au salon de l’industrie 2015

INDUS 05

Le salon de l’industrie 2015 a regroupé, au parc des expositions de Lyon, près de 20 500 professionnels des technologies de production.
Confirmation de l’adoption massive des robots notamment intégrés auprès des équipements de productions et machines à commandes numériques pour améliorer le chargement des pièces et outils, et l’efficacité des approvisionnements.
Même tendance dans l’automatisation des postes d’assemblage par les robots.
Il semble également que la chaine d’automatisation commence toujours par la commande papier avec scan du code-barre de cette dernière.
Accent sur l’innovation avec un prix spécial accordé pour un robot collaboratif d’Akéo-Plus capable de déplacer des boîtes de poids et de taille variables tout en détectant les personnes à proximité et en contournant les obstacles.

La transformation numérique des équipementiers industriels est en marche mais reste centrée à l’adoption d’ERP et d’intégration de fonctionnalités numériques autour de la CFAO.
Il semble qu’une fracture numérique apparait entre les grands équipementiers investissant  dans  l’usine intégrée du futur et les ETI/PMI conservant une approche plus traditionnelle (non digitale) en matière de processus métier autour de leurs produits.
Certains intégrateurs métier, comme les experts en programmation de commandes numérique, souhaitent d’ailleurs compléter leurs offres avec l’utilisation de la maquette numérique en le lien avec les bureaux d’études.

Ces constats confirme que DocDoku est idéalement positionnée pour apporter les solutions digitales nécessaires aux organisations industrielles.
Notre plateforme digitale collaborative répond en effet aux besoins des PMI/ETI industrielles voulant évoluer rapidement et simplement vers la gestion électronique des documents techniques, puis vers la gestion de leurs produits, et de manière homogène et logique.

Les rencontres avec les industriels et les intégrateurs ont été prometteuses d’opportunités. Je vous recommande donc ce très bon salon pour l’année prochaine.

Les tests unitaires avec Mockito

Les tests unitaires

Egalement appelés « TU », ils sont destinés à tester une unité du logiciel. Afin d’être vraiment unitaires, ils doivent être en totale isolation pour ne tester qu’une classe et qu’une méthode à la fois.

Tester le bon comportement de son application c’est bien, détecter les éventuelles régressions c’est encore mieux ! Et c’est là que réside tout l’intérêt d’écrire des TU.

De la théorie… à la bonne pratique

Un test unitaire doit être véritablement unitaire. Pour cela, les appels aux services, aux bases de données et fichiers doivent être évités. Le TU doit s’exécuter le plus rapidement possible afin d’avoir un retour quasi immédiat.

Un TU faisant partie intégrante du code applicatif, les pratiques suivantes sont recommandées :

  • il doit respecter les conventions de code
  • il doit être simple et lisible,
  • il ne doit tester qu’un  seul comportement à la fois
  • il doit faire le moins d’appel possible aux dépendances
  • l’utilisation de mocks est recommandée pour fiabiliser les TU.

Un mock est un objet qui permet de simuler un objet réel tel que la base de données, un web service…

L’approche TDD (Test Driven Development) reste la meilleure solution pour éviter que les tests soient écrits à la fin du développement de l’application.

Frameworks de mock

L’écriture d’objets de type mock peut s’avérer longue et fastidieuse, les objets ainsi codés peuvent contenir des bugs comme n’importe quelle portion du code. Des frameworks ont donc été conçus pour rendre la création de ces objets fiable et rapide.

La plupart des frameworks de mock permettent de spécifier le comportement que doit avoir l’objet mocké avec :

  • les méthodes invoquées : paramètres d’appel et valeurs de retour,
  • l’ordre d’invocation de ces méthodes,
  • le nombre d’invocations de ces méthodes.

Les frameworks de mock permettent de créer dynamiquement des objets généralement à partir d’interfaces ou de classes. Ils proposent fréquemment des fonctionnalités très utiles au-delà de la simple simulation d’une valeur de retour comme :

  • la simulation de cas d’erreurs en levant des exceptions,
  • la validation des appels de méthodes,
  • la validation de l’ordre de ces appels,
  • la validation des appels avec un timeout.

Plusieurs frameworks de mock existent en Java, notamment :

  • EasyMock,
  • JMockIt,
  • Mockito,
  • JMock,
  • MockRunner.

Dans ce qui suit, nous allons détailler le framework Mockito.

Mockito

mockito

C’est un framework Java très connu permettant de générer automatiquement des  objets ‘mockés‘. Couplé avec JUnit, il permet de tester le comportement des objets réels associés à un ou des objets ‘mockés’ facilitant ainsi l’écriture des tests unitaires.

Configuration du projet

Pour intégrer Mockito à son projet, il suffit simplement de rajouter la dépendance Maven :

<dependency>

<groupid>org.mockito</groupid>

<artifactid>mockito-all</artifactid>

<version>1.9.5</version>

</dependency>

Deux manières sont possibles pour intégrer Mockito dans les tests Junit :

1- Ajouter l’annotation @RunWith (MockitoJunitRunner.class) à la classe de test :

@RunWith(MockitoJunitRunner.class)

public class MyTestClass {

}

2- Faire appel à la méthode initMocks dans la méthode de SetUp :

@Before

public void setUp() {

MockitoAnnotations.initMocks(this);

}

Création d’objets mockés avec @Mock

La création d’objets mockés se fait soit en appelant la méthode mock(), soit en rajoutant l’annotation @Mock pour les instances de classes.

User user = Mockito.mock(User.class);

ou

@Mock

User user;

Mockito encapsule et contrôle tous les appels effectués sur l’objet User. Ainsi user.getLogin() retournera tout le temps null si on ne « stubb » pas la méthode getLogin().

Définition du comportement des objets mockés ou « Stubbing »

Le stubbing permet de définir le comportement des objets mockés face aux appels de méthodes sur ces objets. Plusieurs méthodes de stubbing sont possibles :

  1. Retour d’une valeur unique

Mockito.when(user.getLogin()).thenReturn(‘user1’); //la chaine de caractères user1 sera renvoyée quand la méthode getLogin() sera appelée.

  1. Faire appel à la méthode d’origine

Mockito.when(user.getLogin()).thenCallRealMethod();

  1. Levée d’exceptions

Mockito.when(user.getLogin()).thenThrow(new RuntimeException());

Il faut noter que la méthode retournera toujours la valeur stubbée, peu importe combien de fois elle est appelée . Si on stubb la même méthode ayant la même signature plusieurs fois, le dernier stubbing sera pris en compte.

Mockito.when(user.getLogin()).ThenThrow(new RuntimeException()).ThenReturn(« foo »);

Ici le premier appel va lever une exception, tous les appels qui suivront retourneront « foo ».

  1. Retours de valeurs consécutives

Mockito.when(user.getLogin()).thenReturn(‘user1’,’user2’,’user3’);

Le premier appel retourne user1, le deuxième retournera user2 le troisième user3. Tous les appels qui suivent retourneront la dernière valeur c’est à dire user3.

  1. Ne rien retourner

 Mockito.doNothing().when(user.getLogin());

Espionner un objet avec @Spy

Au lieu d’utiliser l’annotation @Mock, nous pouvons utiliser l’annotation @Spy. La différence entre les deux réside dans le fait que la deuxième permet d’instancier l’objet mocké, ce qui peut être très utile quand nous souhaitons mocker une classe et non pas une interface.

Une autre différence est à signaler est le stubbing. Si nous ne redéfinissons pas le comportement des méthodes de l’objet espionné, les méthodes réelles seront appelées, alors qu’avec @Mock, nous sommes obligés de spécifier leurs comportements, sinon la valeur nulle est retournée par défaut. Dans l’exemple qui suit la méthode getLogin() sera appelée.

@Spy

User user = new User(‘user1’);

user.getLogin() // retourne user1

Vérification d’interactions @Verify

@Verify permet de vérifier qu’une méthode a été bien appelée et que que les interactions avec le mock sont celles attendues.

Nous pouvons également vérifier le nombre total de fois ou la méthode a été appelée (atMost(3),atLeastOnce(),never(),times(5)) , l’ordre des invocations des objets mockés en utilisant inOrder() et aussi vérifier si une méthode a été invoquée avant la fin d’un timeout. Nous pouvons également ignorer les appels stubbés en utilisant ignoreStubs() et aussi vérifier qu’il n y’a pas eu  d’interaction en utilisant verifyNoMoreInvocations().

verify(user).getLogin();

//le test passes si getLogin() est appelée avant la fin du timeout

verify(mock, timeout(100)).getLogin();

Injection

Mockito permet également d’injecter des resources (classes nécessaires au fonctionnement de l’objet mocké), en utilisant l’annotation @InjectMock. L’injection est faite soit en faisant appel au constructeur, soit en faisant appel au ‘setter’ ou bien en utilisant l’injection de propriétés.

public Class DocumentManagerBeanTest{

@Mock EntityManager em;

@Mock UserManager userManager;

@Spy RoleProvider role = new RoleProvider();

@InjectMocks DocumentManagerBean docBean;

@Before public void initMocks() {

MockitoAnnotations.initMocks(this);

}

@Test

public void uploadDocument(){

docBean.uploadDoc(file);

}

}

public Class DocumentManagerBean {

private EntityManager em;

UserManager user;

RoleProvider role

public String uploadDoc(String file){

if (user.hasAcess()){

em.checkFileExists(file);

….

}

}

}

Conclusion

Mockito est un framework de mock qui, associé à Junit, permet :

  • une écriture rapide de tests unitaires,
  • de se focaliser sur le comportement de la méthode à tester en mockant les connexions aux bases de données, les appels aux web services …

Cependant il a certaines limitations, en effet , il ne permet pas de mocker :

  • les classes finales,
  • les enums,
  • less méthodes final,
  • les méthodes static,
  • les méthodes privées,
  • les méthodes hashCode() et equals().

Aussi, les objets ‘mockés’ doivent être maintenus au fur et à mesure des évolutions du code à tester.

Interviews DocDoku & Aerospace Valley

François Dorgeret, en charge des projets innovants au sein du pôle Aerospace Valley, et moi-même avons participé à une interview dans le cadre du salon SIANE 2014.
L’occasion pour nous de présenter notre vision de l’usine du future et la manière dont elle est abordée au sein de son DAS chez Aerospace Valley.

Salon Innovation Connecting Show de Toulouse du 16 au 18/09/2014

Nous avons en effet exposé pendant ces trois jours sur le salon international Innovation Connecting Show de Toulouse du 16 au 18/09/2014.

Au programme de ce salon : conférences, pitchs et démonstrations de notre technologie sur notre stand.

J’ai également eu le plaisir de répondre aux questions de la ravissante Ginie sur le plateau TV du salon :

Interview Eric Descargues – plateau TV salon Innovation Connecting Show 2014 from DocDoku on Vimeo.

Grunt, Gulp, quel outil pour automatiser vos tâches front-end ? (2/3)

Gulp

Tout comme Grunt, Gulp est un outil d’automatisation JS (javascript task runner) basé sur la plateforme NodeJS qui va nous permettre d’améliorer notre workflow et d’optimiser nos applications web. Qui dit automatisation dit plus de temps pour se concentrer sur d’autres choses plus importantes comme produire du code de qualité ! Grâce à cet outil, nous allons pouvoir automatiser des tâches telles que la compression d’images, les tests unitaires ou encore la minification.

Depuis sa sortie, Gulp a suscité un grand intérêt auprès de la communauté des developpeurs front-end du fait de la simplicité de sa mise en place et de sa configuration qui lui permette d’être très facilement lisible et maintenable.

Installation

Puisque Gulp est basé sur NodeJS, ce dernier doit être installé sur votre poste avant d’installer Gulp.

Vous pourrez installer NodeJS sur votre machine sans trop de difficulté en vous rendant ici.

Une fois NodeJS installé, vous pourrez installer facilement Gulp en utilisant npm (Node Packet Manager).
Il faut lancer la commande suivante :

$ npm install -g gulp

Cette commande aura pour effet d’aller récupérer Gulp depuis le registre npm et de l’installer globalement dans votre système.
Pour installer gulp uniquement au niveau de votre projet, il ne faut pas mettre l’option -g dans la ligne de commande.

Configuration

À ce niveau, Gulp est installé sur votre système et est prêt à être utiliser dans nos projets.

Tout comme nous l’avions vu dans notre précédent article, il faut avoir mis à la racine de notre projet un fichier package.json dans lequel on va renseigner toutes nos dépendances de développement .

À présent, il faut installer Gulp en tant que dépendance du projet, ce qui permettra aux autres membres de la team, de partir du bon pied lorsqu’ils feront un « npm install » !
La commande à exécuter est la suivante :

$ npm install --save-dev gulp gulp-util

L’option « –save-dev » dans la ligne de commandes va permettre de mettre à jour les dépendances de développement dans le fichier package.json en ajoutant une référence à gulp et gulp util. Si vous omettez cette option, le fichier package.json ne sera pas mis à jour avec la dépendance en question et vous serez obligé de la rajouter manuellement.

Maintenant nous allons pouvoir installer tous les plugins qu’il nous faut pour automatiser l’éxécution des tâches !
Étant donné que les plugins de Gulp sont des modules de node, nous allons utiliser npm pour les installer.

$ npm install --save-dev gulp-less gulp-watch

La ligne de commande ci-dessus va installer le plugin pour compiler nos fichier LESS et va nous permettre de surveiller les fichiers que l’on modifie dans le but d’y associer un traitement particulier. De plus, une entrée sera automatiquement ajoutée au niveau de devDependencies dans le fichier package.json

{
  "devDependencies": {
    "gulp": "^3.7.0"
    "gulp-less": "^1.2.3",
    "gulp-watch": "^0.6.5"
  }
}

À l’heure actuelle, Gulp dispose d’un peu plus de 600 plugins. Certains feront sûrement votre bonheur, tels que :

Gulpfile.js

De la même façon que Grunt, toute la configuration de Gulp réside dans le fichier gulpfile.js situé à la racine du projet.
Nous allons donc commencer par dire à Gulp de quels plugins nous avons besoin pour executer les tâches :

var gulp  = require('gulp'),
    util  = require('gulp-util'),
    less  = require('gulp-less'),
    watch = require('gulp-watch');

Par la suite nous allons specifier quelles tâches nous allons exécuter. Dans notre cas nous allons faire 2 choses :

  • Une tâche « less » qui va compiler les fichiers LESS et placer le résultat à un endroit donné
  • Une tâche « default » qui va exécuter la tâche « less » puis surveiller toutes modifications des fichiers de type .less, si une modification survient la tâche « less » sera rejouée

Pour définir une tâche Gulp, on utilise la méthode task() suivante :

gulp.task('less', function () {
  gulp.src('app/styles/**/*.less')
    .pipe(less())
    .pipe(gulp.dest('build/styles'));
});

La méthode task() prend en entrée un nom sémantique « less » qui définit le nom de la tâche et ensuite une fonction anonyme qui contient le traitement en question.

Nous allons décomposer cette méthode ligne par ligne :

gulp.src('app/styles/**/*.less')

La méthode src() va nous permettre de spécifier le chemin vers les fichiers avec l’extension LESS et va les transformer en un stream qui sera diffusé aux plugins pour effectuer les traitements.

.pipe(less())

La méthode pipe() va utiliser le stream provenant de src() et le passer aux plugins référencés. Ici en l’occurrence, le plugin less recevra le stream de fichier pour les traiter.

.pipe(gulp.dest('build/styles'))

La méthode dest() va nous permettre de spécifier l’emplacement où l’on souhaite écrire le résultat du traitement. Les fichiers LESS compilés seront donc placés dans le dossier styles du build.

Pour exécuter cette tâche, il suffira de se placer à la racine du projet et de lancer la commande :

$ gulp less

Si nous ne spécifions pas de tâche dans la ligne de commande, la tâche « default » sera lancée.

gulp.task('default', function() {
  gulp.run('less');
  gulp.watch('app/styles/**/*.less', function() {
    gulp.run('less');
  });
});

La tâche « default » ci-dessus a pour but de lancer la tâche « less » (compilation de LESS pour avoir en sortie une feuille de style CSS) puis surveiller toutes modifications des fichiers LESS. Si une modification survient, la tâche « less » sera re-éxecutée. De cette façon, on n’a plus à se soucier de compiler les fichiers LESS à chaque fois qu’on les modifie !

Là est toute la puissance de Gulp, une syntaxe très séduisante, claire et facilement lisible et un gain de performance grâce à un système de stream qui évite d’écrire dans un dossier temporaire.
Il n’y a pas autant de plugins disponibles pour Gulp que pour Grunt, c’est un fait, mais la communauté n’en est pas moins active et grandissante, il ne serait pas étonnant que Gulp s’impose comme le prochain standard de l’automatisation JS des tâches, mais d’ici là quel outil choisir ?

La suite, dans notre prochain article consacré au match Grunt / Gulp.

Grunt, Gulp, quel outil pour automatiser vos tâches front-end ? (1/3)

Introduction

En tant que développeurs front-end, nous sommes amenés à réaliser nos projets web en ayant à l’esprit un certain nombre de bonnes pratiques telles que :

  •  La compression des feuilles de styles CSS et la minification des scripts Javascript pour qu’ils soient le plus léger possible en production
  •  L’optimisation des images en réduisant leur poids sans altérer leur qualité
  • Auto-générer des sprites d’images
  •  S’assurer que les scripts Javascript ne contiennent pas d’erreurs de syntaxe
  •  Retirer les alertes/console log en production
  •  etc …

Si  nous voulons avoir une webapp optimisée, nous devons réaliser absolument toutes ces tâches. Des tâches répétitives, quelque soit le projet, et fastidieuses car elles ne se limitent pas seulement aux 4 citées en exemple plus haut.

Automatiser ce genre de tâches est donc devenu quasi-vital dans le but, d’une part, de gagner un temps considérable à ne plus tout faire manuellement et d’autre part, d’être sûr de l’optimisation du code livré en production (minification, obfusquation etc…). Tout cela en moins de temps qu’il ne faut pour préparer votre café préféré !

Si votre quotidien est synonyme de tâches à répétition et que vous avez cherché à un moment donné à les automatiser, vous avez forcément entendu parler de Grunt ou encore de Gulp qui s’imposent comme des références en la matière d’outils d’automatisation Javascript.

Outils Javascript d’automatisation

Les outils js d’automatisation des tâches s’appuient sur Node.js, une plateforme software écrite en Javascript orientée serveur qui fut créé il y a quelques années. Elle utilise le moteur V8 de Google Chrome qui va analyser/exécuter ultra-rapidement du code js et qui fonctionne suivant un modèle non bloquant (programmation asynchrone). Node.js a ouvert la voie, entre autres, à de nouveaux outils d’automatisation tel que Grunt et c’est une vraie chance pour nous autres développeurs front-end que d’avoir à notre disposition ce genre d’outils pour :

  • déployer rapidement un serveur de développement
  • rafraîchir sa page lorsque l’on modifie un fichier
  • compiler les templates
  • bouchonner les données renvoyées par un web service,
  • supprimer tous les commentaires dans le code
  • minifier les feuilles de styles
  • obfusquer les scripts JS
  • etc…

Il n’y a pratiquement pas de limites à ce que l’on peut faire !

Grunt

Grunt est un outil basé sur des tâches exécutées en ligne de commande qui va grandement accélérer nos workflows classiques de développement en réduisant notre effort lors de la préparation des sources pour les mises en production.

Dans la plupart des cas, sachez que lorsque vous effectuez manuellement une tâche, son équivalent automatique existe sous forme de plugin Grunt comme par exemple la minification et la concaténation de scripts.

Grunt est également capable de gérer des tâches qui ne sont pas forcément liées à Javascript comme la compilation CSS depuis SASS ou LESS.

Enfin sachez qu’il dispose d’une incroyable communauté de développeurs et d’une énorme base de plugins mise à jour très régulièrement. Vous n’êtes donc pas seul à vous lancer dans l’aventure !

Installation

Comme évoqué précédemment, Grunt est basé sur Node.js. De ce fait il doit être installé sur votre machine pour que Grunt puisse fonctionner. L’installation de Grunt se fait via le npm (Node Packet Manager), il suffit d’ouvrir votre invité de commandes et d’exécuter cette instruction pour installer Grunt :

$ npm install -g grunt-cli

Package.json

Package.json est un fichier à créer à la racine de votre projet, il va vous permettre de tracker et d’installer toutes les dépendances liées au développement. Ainsi, tous les membres de votre team disposeront des toutes dernières versions des dépendances. Ce qui en fin de compte permet de garder un environnement de développement constamment synchronisé.

{
  "name": "Example",
  "description": "Un package de test",
  "version": "0.0.1",
  "private": "true",
  "author": "Prenom Nom ",
  "devDependencies": {
    "grunt": "^0.4.5"
  }
}
$ npm install

La commande ci-dessus va dire à npm d’aller récupérer toutes les dépendances qui sont listées dans devDependencies puis de les installer dans le dossier node_modules.
 Dans cet exemple, si la commande réussie, Grunt version 0.4.5 ou supérieure sera installée localement dans le projet.

Gruntfile.js

Comme le fichier package.json, le fichier Gruntfile.js doit être placé à la racine du projet. Il contient toute la configuration des tâches automatiques à exécuter lorsque l’on exécute grunt depuis l’invité de commandes.

module.exports = function(grunt) {

    /* 1. Toute la configuration. 
     * L'ordre n'a pas d'importance.
     */
    grunt.initConfig({
        pkg: grunt.file.readJSON('package.json'),

   /* 2. La configuration du plugin cssmin pour la minification de css.
    * Une sous tâche build qui va minifier index.css dans style.css
    */
        cssmin: {
                   build: {
                             src: 'app/css/index.css',
                             dest:'build/css/style.css'
                          } 
                }
    });
    
    /* Chargement du plugin
     * 3. On dit à Grunt que l'on compte utiliser le plugin grunt-contrib-cssmin.
     */
    grunt.loadNpmTasks('grunt-contrib-cssmin');

    /* Déclaration des tâches
     * On dit à grunt ce qu'il faut faire lorsque l'on execute "grunt" dans l'invité de commandes.
     */
    grunt.registerTask('default', ['cssmin']);

};

À partir de maintenant il n’y a plus qu’à exécuter la ligne de commande suivante dans notre invité de commandes pour minifier notre feuille de style :

$ grunt

Et voila ! Notre feuille de style a été minifiée en une fraction de seconde. grunt-command-line
Imaginez maintenant toutes les tâches que l’on peut automatiser exactement avec la même simplicité! 
Pour vous en rendre compte, je vous invite à jeter un œil à l’impressionnant listing de plugins disponible pour Grunt. Pas moins de 3000 plugins pour faciliter notre quotidien.

Grunt est donc un outil très simple d’usage, qui consiste en un fichier de configuration js facilement lisible, dans lequel on paramètre les plugins que l’on souhaite utiliser pour automatiser nos tâches.
Sachez qu’il n’est pas le seul sur le marché… 
La suite, dans la deuxième partie de ce dossier qui sera consacrée au petit nouveau, Gulp !

Bien démarrer ses projets web avec Yeoman

yeoman

Introduction

Avec autant d’outils disponibles pour les développeurs web aujourd’hui, il peut parfois être difficile de comprendre comment tout cela s’assemble et fonctionne.

Construire la structure de son projet « from scratch » et organiser son code et ses dépendances n’est pas toujours évident. Yeoman va nous aider à résoudre ce problème, et vous lancer sur de bons rails en générant la structure de base de votre projet (scripts, librairies, tests, …). Le code généré par yeoman est le fruit de l’aggrégation des meilleurs pratiques du web qui ont évoluées au sein de l’industrie.

Dans cet article, vous allez apprendre comment exploiter Yeoman afin de pouvoir de créer des applications web solides.

Qu’est-ce que Yeoman ?

Yeoman est une collection de trois outils : Yo, Grunt, et Bower. Combinés ensemble, ces outils fournissent tout ce qu’un développeur a besoin pour démarrer son projet.

Yo – CLI tool for scaffolding out Yeoman projects

Yo est un outil qui est utilisé pour échafauder une nouvelle application. Il permet de créer la structure du projet, l’organisation des feuilles de style, des scripts, des ressources.

Grunt – The javascript task runner

Grunt est un outil basé sur nodejs qui vous permet d’exécuter des tâches écrites en javascript. Par exemple, avec grunt vous pouvez automatiser les builds, les tests, et le développement. Grunt s’appuie sur un grand nombre de plugins parmi lesquels on peut trouver.

Bower – A package manager for the web

Bower est un outil qui va vous permettre de gérer vos dépendances et librairies, les installer automatiquement et surtout les garder à jour, de sorte que vous n’avez pas à les télécharger manuellement.

Installation

Prérequis

Un guide complet est accessible directement ici, pour ceux qui voudrait rapidement l’essayer assurez vous d’avoir installé Nodejs , Git et optionnellement Ruby et Compass (si vous voulez utiliser scss)

Ensuite, en ligne de commande, installer yo

npm install -g yo

Comme yo dépend de grunt et bower, ces derniers seront installés automatiquement !

Maintenant, il faut installer un générateur de projet :

npm install -g generator-webapp

Certains générateurs embarquent yo, grunt et bower, et les installeront si nécessaire automatiquement. La liste des générateurs se trouve sur npm

Utilisation

Une génération de projet avec yeoman se déroule ainsi :

mkdir MyWebApp	&& cd $_       # Crée un dossier nommé MyWebApp et se place dedans
yo webapp                      # Génère une structure de base
bower install underscore       # Installe les dépendances et librairies
grunt                          # Pour builder le projet	
grunt test                     # Lance les tests
grunt serve                    # Lance un serveur

Générateurs

Plusieurs générateurs sont disponibles via npm. Parmi les frameworks les plus utilisés, on trouve facilement les générateurs associés :

Backbone

npm install generator-backbone

yo backbone 			# Génère la structure
yo backbone:model article	# Génère un modèle
yo backbone:collection article  # Génère une collection
yo backbone:router article      # Génère une route
yo backbone:view article	# Génère une vue
grunt serve 			# Lance votre projet dans un serveur local

AngularJS

npm install generator-angular
yo angular 					# Génère la structure
bower install 					# Installe les dépendances
grunt serve 					# Lance votre projet dans un serveur local

Emberjs

npm install generator-ember 	
yo ember 					# Génère la structure
bower install 					# Installe les dépendances
grunt serve 					# Lance votre projet dans un serveur local

Et si cela ne vous suffit pas, vous pouvez aussi écrire votre propre générateur et ainsi optimiser d’avantage votre productivité, ou contribuer à la communauté en soumettant votre générateur sur npm. Pour les plus courageux suivre le guide ici

Plugins grunt

Une multitude de plugins va vous permettre d’augmenter votre productivité et automatiser vos tâches : validation du code, minification et obfuscation du code source, zip des sources, live reload, lancer des commandes shell, déployer sur un serveur … Voir ici pour tous les plugins disponibles.

Pour installer un plugin grunt, éditer le fichier package.json à la racine du projet pour ajouter le plugin. Exemple :

{
	"name": "MaWebApp",
	"version": "1.0.2",
	"dependencies": {},
	"devDependencies": {
		"grunt": "~0.4.1",
		"grunt-contrib-copy": "~0.4.0",
		"grunt-contrib-clean": "~0.5.0",
		"grunt-contrib-compress": "~0.7.0",
		"time-grunt": "~0.2.1"  ## Ajoutez vos dépendances après cette ligne
	},
	"engines": {
		"node": ">=0.8.0"
	}
}

Ensuite, dans votre terminal :

npm install

Cela va installer automatiquement les nouvelles dépendances que vous avez ajoutées.

Conclusion

Ceci n’était qu’un aperçu des possibilités qu’offre Yeoman. En utilisant les générateurs de base et en inspectant le code généré, vous comprendrez mieux comment tout ces composants fonctionnent ensemble, et vous ouvrira surtout de nouvelles perspectives dans vos workflows.