All posts in Open Source

Optimisation des performances Ionic

ionic optimisation

Ionic est un framework open source permettant de développer des applications mobiles hybrides. Pour ce faire, il utilise des technologies web comme HTML, CSS et JavaScript. Il a été lancé en 2013 et a beaucoup évolué depuis.

Evolutions

En 2013, lors de sa sortie, Ionic était fortement lié à AngularJS pour l’interface graphique et à Cordova pour l’accès aux fonctionnalités du téléphone. Depuis, Ionic permet l’utilisation de React, Vue.js et Angular dans leurs dernières versions. Il a également introduit Capacitor pour résoudre les problématiques liées à Cordova.
Avec ses dernières versions, Ionic offre un rendu plus proche des applications natives de chaque plateforme et prend en compte les dernières directives et normes AAA pour l’accessibilité.

Performance

Ionic repose essentiellement sur les WebView (WebView pour Android et WKWebView pour iOS). Par conséquent, les performances de l’application dépendent fortement de celles des WebView, qui ne figurent pas parmi les éléments les plus performants des appareils mobiles.
Les manipulations intensives du DOM peuvent provoquer d’importants ralentissements, notamment sur les appareils d’entrée de gamme.
Une surutilisation des appels aux plugins natifs (via Capacitor) ou une mauvaise configuration de ces derniers peut accroître le temps de réponse et générer de la latence, en raison des interactions entre la couche native et le JavaScript de la WebView.
De plus, l’utilisation de ressources trop volumineuses, telle que des images ou des fichiers CSS/JS, peut également ralentir l’application.

Optimisations

Pour remédier aux problèmes de performance potentiels qu’une application Ionic peut rencontrer, notamment dans le cas d’applications complexes, plusieurs pistes peuvent être envisagées.

Optimisation des ressources

Si votre application est relativement volumineuse, il est recommandé d’envisager l’utilisation du lazy loading pour charger les modules et composants uniquement lorsque cela est nécessaire.

En Angular, il faut utiliser « loadChildren » dans les routes :

export const routes: Routes = [
    {
        path: '',
        component: AppComponent
    },
    {
        path: 'something',
        loadChildren: () => import('./pages/lazy/lazy.routes').then(m => m.routes)
    }
]

Pour la gestion des médias, il est conseillé d’utiliser le lazy loading et de compresser les images avec des formats tels que SVG ou WebP. Il est également souhaitable de limiter le chargement des vidéos et audios sur les écrans inactifs.

Pour la gestion des sources, il est important d’activer la minification des fichiers afin de transmettre des ressources plus légères.

Optimisation de l’interface utilisateur

Lors de l’affichage de longues listes de données, il est recommandé d’utiliser ion-virtual-scroll. Cet élément permet en effet d’afficher de manière optimisée une grande liste en ne rendant visible que les éléments affichés dans la fenêtre de visualisation.

<ion-virtual-scroll [items]="items" approxItemHeight="50px">
  <ion-item *virtualItem="let item">
    <ion-label>
      <h2>{{ item.name }}</h2>
      <p>ID: {{ item.id }}</p>
    </ion-label>
  </ion-item>
</ion-virtual-scroll>

Vous pouvez combiner ion-virtual-scroll avec ion-infinite-scroll pour charger progressivement davantage de données à mesure que l’utilisateur atteint le bas de la liste.

<ion-content>
  <!-- Liste avec défilement virtuel -->
  <ion-virtual-scroll [items]="items" approxItemHeight="50px">
    <ion-item *virtualItem="let item">
      <ion-label>
        <h2>{{ item.name }}</h2>
        <p>ID: {{ item.id }}</p>
      </ion-label>
    </ion-item>
  </ion-virtual-scroll>

  <!-- Chargement progressif -->
  <ion-infinite-scroll threshold="100px" (ionInfinite)="loadMoreData($event)">
    <ion-infinite-scroll-content
      loadingSpinner="bubbles"
      loadingText="Chargement des éléments...">
    </ion-infinite-scroll-content>
  </ion-infinite-scroll>
</ion-content>

Pour les animations, il faut limiter au maximum les animations JavaScript et privilégier les animations CSS natives. Il est également recommandé de privilégier les animations GPU, telles que transform, plutôt que l’utilisation de top/left.

Les manipulations du DOM sont très coûteuses en termes de performance. Il est donc important de limiter l’utilisation de hooks et de directives qui entraînent des modifications fréquentes du DOM.

Optimisation des requêtes réseaux

Étant sur mobile, l’utilisation du réseau peut poser un certain nombre de problèmes, notamment dans les zones blanches ou mal desservies.
Pour résoudre ce problème, il convient de regrouper au maximum les requêtes et, le cas échéant, de compresser les données envoyées et reçues.
Il est également important de mettre en cache les données fréquemment utilisées. On peut ainsi utiliser Ionic Storage, IndexedDB ou @capacitor-community/sqlite. Les deux premiers s’appuient sur les bases de données des navigateurs. Le dernier utilise une base de données native.

Optimisation des performances natives

L’utilisation de fonctionnalités sensibles aux performances (caméra, GPS…) doit passer par des plugins Capacitor bien maintenus. Il faut donc optimiser les appels à ces plugins en les réduisant au minimum.

Optimisations générales

L’optimisation du code, avec la suppression des dépendances inutiles, la suppression des balises HTML superflues et le contrôle de la profondeur des nœuds HTML, permettront d’optimiser votre application.
L’utilisation de techniques avancées, comme le SSR (Server-Side Rendering), permettra d’optimiser les temps de chargement initiaux de l’application. Attention, dans le cadre du SSR, il faut prendre en compte le chargement des données. Lorsque la page est chargée depuis le serveur, on n’a pas accès aux données du navigateur ou aux données natives.
Pour les PWA (Progressive Web App), la configuration des services workers contribuera également à rendre l’expérience hors ligne plus rapide.

Suivi des performances

Dans le cadre du développement, l’utilisation de Chrome DevTools ou Safari Web Inspector permettra d’analyser le temps de rendu et de détecter les goulets d’étranglement de votre application.
Pour analyser les performances directement sur un appareil, vous pouvez utiliser des outils tiers comme Firebase Performance Monitoring ou Sentry.

Si vous souhaitez monter en compétence sur ce framework et travailler sur les performances et l’optimisation Ionic, n’hésitez pas à découvrir notre programme de formation ici.

A lire également notre article sur les Décorateurs TypeScript et Web Components.

ElasticSearch ILM et répartition des données

Description

La gestion d’une centaine de milliards de documents (données issues de logs applicatifs, équipements réseau, middlewares, etc.) s’avère coûteuse (machines, disques, espace de sauvegarde, etc.).
Pour alléger ce coût d’infrastructure nous devons distinguer les données brûlantes des données tièdes et froides (voir gelées). C’est ce que propose ElasticSearch avec l’ILM (Index Lifecycle Management). Nous vous proposons ainsi d’analyser sa mise en œuvre sur un cluster de production d’un de nos clients.
Les données considérées brûlantes doivent être exploitables dans des temps de réponse très courts, nous devons donc les placer sur des machines dimensionnées correctement. Les requêtes sur les données tièdes et froides n’ont pas besoin d’être aussi performantes, ces données peuvent donc automatiquement être déplacées vers des machines plus modestes grâce aux règles de rétention offertes par ILM.

Limitations des écrans dans Kibana et Cerebro

Kibana, l’interface graphique de la suite Elastic ne propose pas une vue synthétique de cette répartition. Nous pouvons obtenir cette information de répartition grâce à plusieurs requêtes, mais nous devons alors croiser les résultats, ce qui est fastidieux.
Cerebro, une interface graphique issue de la communauté open source, est excellent dans la visualisation de la répartition de la charge, mais ne propose pas cette visualisation au niveau du cycle de vie.
Même constat pour Elasticvue, qu’il s’agisse de sa version desktop, extension Chrome ou webapp.
Un moyen d’obtenir les informations souhaitées est donc de passer par l’API d’ElasticSearch.
Avec une première API nous pouvons obtenir les rôles des machines :

GET _nodes/settings?filter_path=nodes.*.roles,nodes.*.name

{
  "nodes": {
    "ECNRRDP2SUKmcu3s9qJgnA": {
      "name": "es3",
      "roles": [
        "data_cold",
        "ingest",
        "master"
      ]
    },
    "NXZNCa_BQ_SE613oSnDf-g": {
      "name": "es6",
      "roles": [
        "data_cold",
        "ingest",
        "master"
      ]
    },
    "jqmdwzdeQHG84601oQjpGw": {
      "name": "es1",
      "roles": [
        "data",
        "data_hot",
        "ingest",
        "master"
      ]
    },
    "4z2k13n8SZS4t2JmLielaQ": {
      "name": "es4",
      "roles": [
        "data",
        "data_hot",
        "ingest",
        "master"
      ]
    },
    "AFRMIIagRWK4Cu-ZhbLH2A": {
      "name": "es5",
      "roles": [
        "data_warm",
        "ingest",
        "master"
      ]
    },
    "sxljzKF-Q1app0VSkVgTxg": {
      "name": "es2",
      "roles": [
        "data_warm",
        "ingest",
        "master"
      ]
    }
  }
}

Puis avec une deuxième API nous pouvons récupérer le cycle de vie des indices (index au pluriel).

GET /*/_settings?filter_path=*.settings.index.routing.allocation.include,*.settings.index.uuid,*.settings.index.provided_name

{
  ".ds-my-index-1-2024.09.17-003772": {
    "settings": {
      "index": {
        "routing": {
          "allocation": {
            "include": {
              "_tier_preference": "data_hot"
            }
          }
        },
        "provided_name": ".ds-my-index-1-2024.09.17-003772",
        "uuid": "HyELPU6oTpC_EfskAxP5BQ"
      }
    }
  },
  ".ds-my-index-1-2024.09.17-003748": {
    "settings": {
      "index": {
        "routing": {
          "allocation": {
            "include": {
              "_tier_preference": "data_warm,data_hot"
            }
          }
        },
        "provided_name": ".ds-my-index-1-2024.09.17-003748",
        "uuid": "QNC-Z2loT4SCKFb2-LJKAw"
      }
    }
  },
  ".ds-my-index-1-2024.09.17-003714": {
    "settings": {
      "index": {
        "routing": {
          "allocation": {
            "include": {
              "_tier_preference": "data_cold,data_warm,data_hot"
            }
          }
        },
        "provided_name": ".ds-my-index-1-2024.09.17-003714",
        "uuid": "zIP72E-qTBSfKbZdAYmFEQ"
      }
    }
  },
  [...]
}

Et avec une troisième API nous pouvons restituer le détails des blocs de données correspondant aux indices :

GET /_cat/shards?format=json&h=index,node,state,prirep,docs

[
  {
    "index": ".ds-my-index-1-2024.09.17-003848",
    "node": "es1",
    "state": "STARTED",
    "prirep": "p",
    "docs": "120"
  },
  {
    "index": ".ds-my-index-1-2024.09.17-003848",
    "node": "es4",
    "state": "STARTED",
    "prirep": "r",
    "docs": "47"
  },
  {
    "index": ".ds-my-index-1-2024.09.17-003828",
    "node": "es5",
    "state": "STARTED",
    "prirep": "p",
    "docs": "29"
  },
  {
    "index": ".ds-my-index-1-2024.09.17-003828",
    "node": "es2",
    "state": "STARTED",
    "prirep": "r",
    "docs": "147"
  },
  [...]
]

En croisant les résultats de ces trois requêtes, nous pouvons donc savoir si un bloc de données d’un index « brûlant » est bien placé sur un noeud « brûlant ». Mais pour des milliers d’index, cela devient beaucoup plus laborieux.

Développement d’une solution de visualisation

Quelques lignes de JavaScript (64), d’HTML (80) et de CSS (118) plus tard et voici un aperçu d’un rapport réalisé sur un cluster ElasticSearch en local.

ElasticSearch ILM test

Résultat de l’analyse du cluster local

L’outil génère un fichier de rapport en format HTML, consultable depuis n’importe quel navigateur. Alors, en un coup d’œil on peut savoir si un bloc est à la bonne place.
Le code source est disponible sur Github.
Pour résumer ce que fait techniquement ce code source :

  • Lancement des 3 requêtes précédemment étudiées
  • Injection de ces données dans un moteur de template HTML
  • Sauvegarde du résultat dans un fichier HTML

Premier rapport réalisé sur une infrastructure de production et analyse

Ensuite, nous avons intégré l’outil dans une chaîne d’intégration continue de Gitlab pour automatiser la génération des rapports. Nous pouvons ainsi désormais nous interfacer avec le cluster à analyser et donc générer un premier rapport.
Quelques données sur la taille du cluster :

  • 10 machines ElasticSearch
  • 110 milliards de documents
  • 125 To de données stockées
  • 25 000 événements par seconde

Le premier rapport montre une répartition de la charge logique comme ci-dessous :

ElasticSearch ILM

Résultat de l’analyse du cluster de production

Les nœuds ayant le rôle data_warm reçoivent bien les blocs data_warm. Les nœuds ayant le rôle data (tout les rôles) reçoivent tout type de blocs.
Cependant ce n’est pas encore optimisé pour réduire les coûts car :

  • Il reste des blocs data_warm non alloués à des nœuds data_warm car ElasticSearch cherche l’équilibre en termes de nombre de blocs par machine.
  • Aucun bloc de données froides n’apparaît car les règles de rétention ne définissent pas de phase « cold ». Des nœuds data_cold doivent être ajoutés au cluster.
  • Il y a légèrement trop de données brûlantes en proportion, la durée de rétention en phase « hot » doit être revue à la baisse.

Evolution du cluster

Ainsi, après réflexions avec les équipes en charge de la maintenance du cluster, nous avons définit la cible à atteindre :

  • 3 nœuds cold (à venir)
  • 5 nœuds warm (node-3 node-9 node-10 node-1 node-2)
  • 2 nœuds hot warm master (node-4 node-5)
  • 3 nœuds hot ingest master content (node-6 node-7 node-8)

Les raisons de ces choix dépendent des caractéristiques des machines à disposition (CPU, disques, RAM).
Les mouvements de blocs vont être nombreux, et nous réfléchissons déjà à la procédure de migration afin de perturber au minimum le service. Il faut bien prendre en compte que l’espace disque pris par chaque bloc est de 50Go, et que chaque déplacement prend entre 30 minutes et 1 heure sur cette infrastructure réseau.
Nous avons ensuite planifié l’exécution de l’outil pour fournir un rapport tous les jours afin de suivre l’évolution de la répartition. Nous aurons donc un joli jeu de couleurs d’ici quelques semaines 😉

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

Quarkus : le framework Cloud Native révolutionnaire

L’écosystème Java est en plein renouveau. Oracle a officiellement acté son désengagement de Java EE (renommé Jakarta EE), les spécifications et leur implémentation de référence se font désormais sous l’égide de la fondation Eclipse et non plus au JCP (Java Community Process). Si ce chamboulement a pu générer quelques craintes et appréhensions quant au futur de la plateforme, aujourd’hui les conditions de passation de témoin entre Oracle et Eclipse semblent dorénavant établies (voir ici pour plus de détails sur l’imbroglio au sujet de l’utilisation du nom de package javax).

Place donc à la technique et je dois dire, pour vivre les choses de l’intérieur (nous sommes membres du consortium Jakarta) que la dynamique Jakarta est bien réelle. Le tournant micro-service a été pris avec conviction (il était temps), l’axe Cloud Native est clairement une priorité pour le consortium.

Jakarta poursuit l’oeuvre de standardisation de Java EE et offre aux développeurs le choix de l’implémentation. Nous avons toujours la filière traditionnelle avec un modèle basé sur le serveur d’applications. Mais surtout nous avons désormais la déclinaison Microprofile du standard. L’application ne nécessite alors plus de serveur pour fonctionner mais est packagée sous la forme d’une application autonome taillée pour les containers Dockers et les clusters Kubernetes. L’approche prise par la spécification Microprofile est particulièrement intéressante : conserver tels quels les modules Jakarta EE (CDI, JAX-RS, JPA…) et y adjoindre de nouveaux composants dédiés aux nouvelles problématiques découlant des architectures microservices. Notamment sont couverts les sujets liés à la tolérance à la panne, l’authentification par token JWT, la documentation Open API, les métriques et les traces, le Health Check, la génération de clients REST, l’intégration aux services de messaging… Bien sûr pour chacun de ces thèmes, il y a d’un côté la spécification des API et de l’autres les implémentations.

Cela nous amène à Quarkus qui est la nouvelle proposition Microprofile de Red Hat. Je dis nouvelle parce qu’il y a déjà Thorntail qui est la déclinaison Microprofile du serveur d’application WildFly. Quarkus lui, est une réécriture pensée véritablement pour l’approche Cloud Native. En effet, l’objectif ultime de Quarkus est de permettre la compilation native des applications grâce à GraalVM et ainsi corriger les deux faiblesses historiques de Java que sont l’empreinte mémoire et le temps de démarrage. A une époque pas si lointaine où le modèle d’exécution était le gros serveur d’applications pas ou peu redondé qui devait être redémarré le moins souvent possible, ces deux lacunes posaient peu de problème. Aujourd’hui le paradigme a changé, les applications sont découpées en plusieurs unités d’exécution (microservices) qui sont démarrées, répliquées, déplacées sur un cluster Kubernetes de nombreuses fois par jour (potentiellement tout du moins). Il est ainsi crucial que nos processus soient faiblement gourmands en ressources et puissent être lancés juste en une fraction de seconde.

Quarkus est encore jeune, la compilation native échoue plus souvent qu’elle ne réussit, mais ce n’est pas bloquant, il suffit alors de se rabattre sur une exécution classique JVM qui reste bien plus performante que n’importe quel serveur d’applications ou que Thorntail. Quarkus nous montre le futur des applications Java d’entreprise orientées Cloud Native. Si vous êtes intéressés, n’hésitez pas à échanger avec nous ou à vous inscrire à une de nos sessions de formation.

 

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

Retrouvez DocDoku sur l’EclipseCon 2018

Les 13 et 14 juin prochains, DocDoku vous donne rendez-vous dans la ville rose pour l’EclipseCon France 2018, le grand rassemblement annuel français de la communauté Eclipse.

Comme lors de la précédente édition, DocDoku reste fidèle à son engagement en tant que sponsor de l’événement et vous accueillera sur son stand pour parler solutions et technologies, mais également présenter ses derniers cas clients.
Le programme de la conférence 2018 couvrira cette année des sujets en lien avec la modélisation, les systèmes embarqués, le Cloud, la Data Analytics, le DevOps et plus encore, le tout agrémenté de sessions de démonstration des outils basés sur Eclipse.

Cette année nous serons particulièrement attentifs aux conférences sur l’arrivée dans la fondation du groupe de travail JakartaEE, auquel DocDoku appartient désormais.
En effet, ce projet ambitieux prend la suite de la renommée plateforme de développement d’applications d’entreprise Java Enterprise Edition, maintenue par Oracle précédemment.

Nous resterons également captivés par les conférences du groupe de travail Polarsys, auquel DocDoku participe également au travers de la plateforme PLM d’Eclipse EPLMP.

13 et 14 juin 2018
Centre de Congrès Pierre Baudis
11 esplanade Compans Caffarelli
31000 Toulouse

Lien direct vers le formulaire d’inscription : ici

A la recherche de ressources sur la transformation par les données ?

Toute la team DocDoku vous présente ses meilleurs voeux !

Laissez-nous vous inspirer en ce début d’année avec le top 4 des articles du blog pour vous accompagner dans votre réflexion stratégique :

Comment construire un pilotage de qualité, centré sur les données ?
> 6 clés pour mettre en place votre management par les données

Quelles sont les composantes indispensables au succès ?
> Transformation digitale : l’expertise ne suffit pas !

Découvrir les meilleurs outils de gestion collaborative, orientés temps réel et partage.
> Entreprise étendue : bien choisir sa plateforme de Data Management

Comment l’IoT peut transformer mon business ?
> Acquisition des données et IoT

Et si vous avez choisi d’activer votre transformation dès le premier semestre 2018, rejoignez dès maintenant la communauté QuickEval !

Retour sur EclipseCon France 2017


Comme les années précédentes, DocDoku était présent à l’EclipseCon France et j’ai pu assister à quelques présentations.
Faut-il encore présenter le projet Eclipse ? Pour ceux qui auraient vécu dans une grotte durant les 16 dernière années (ou ceux qui n’étaient pas nés), Eclipse est un projet proposant une plateforme extensible, basée sur OSGi, qui permet de construire des applications par agrégation de greffons (plugin) en se basant sur une bibliothèque de composants sur l’étagère.
À une époque éloignée Eclipse était considéré comme un environnement de développement intégré – c’était la première application il est vrai – pourtant force est de constater qu’année après années le projet va bien au delà de cela et que ce n’est pas près de s’arrêter, l’étagère ne cesse de s’agrandir.
Hier c’était une plateforme, puis une fondation, puis un ensemble de projets basés sur les technologies de la plateforme, aujourd’hui l’écosystème ne cesse d’évoluer et s’immisce dans une quantité impressionnante de domaines : bien sûr les outils de développement, mais aussi la modélisation, le cloud, ou encore une multitude de domaines (IoT, robotique, science, big data, …).

Au début il y avait l’outil

Du côté des outils de développement, toujours plus d’améliorations pour déboguer, pour tester, pour suivre les évolutions des langages. Java reste le langage privilégié mais ne règne plus en maître, certains veulent pouvoir développer dans la plateforme avec d’autres langages.

Java 9

L’intégration de Java 9 arrive avec son lot de nouveautés, lié en particulier au nouveau système de module tant attendu de la dernière version de la plateforme d’Oracle :

  • Support des images (jimage);
  • Support des modules (JMOD);
  • Nouveau fichier module-info.java.

De gros changements en perspective avec la disparition programmée (progressivement) des fichiers JAR.

Déboguer

Les outils de débogage s’améliorent aussi Barbero [2017].

  • triggerpoint pour activer un certain nombre de breakpoints
  • conditional watchpoint
  • tracepoint pour écrire dans la console et éviter les System.out.println() dans le code.
  • Show Logical Structure permet d’obtenir une représentation simplifiée de la structure de certains types (Listes, Maps, …)

Couverture de code

À l’occasion de l’intégration d’EclEmma, un outil de couverture de code Java, à la distribution Eclipse Oxygen, SonarSource nous rappelle quelques bonnes pratiques pour éviter les bogues Mandrikov [2017]. Un outil intégré, non intrusif, pourquoi s’en passer?

EASE

EASE (Eclipse Advance Scripting Environment) propose le moyen d’intégrer du code développé avec des langages de script dans la plateforme Eclipse.
Airbus présente un retour d’expérience : Constatant que le développement d’un plugin Eclipse nécessite certaines contraintes, l’idée est de proposer un pont pour le langage Python offrant une API simplifiée aux composants Eclipse. Les avantages d’un langage de script avec la puissance de la plateforme en somme Bernard [2017].

Abstraire par les modèles

Au devant de la scène cette année, l’ingénierie dirigée par les modèles était particulièrement
bien représentée. Par modèle j’entends une représentation abstraite de concepts mis en jeu dans un domaine particulier.

D’une part, la première journée accueillait le Xtext Summit – série de conférences sur Xtext, technologie liée aux langages dédiés (Domain-specific Language) : définition d’un langage et génération des outils. D’autre part, de nombreuses conférences gravitaient autour des modèles.

Je n’ai pas pu assister à toutes les conférences, mais le peu que j’en ai vu a affûté ma curiosité.

Eclipse EMF Parsley

Eclipse EMF Parlsey fournit un ensemble de composants d’interface utilisateurs basés sur EMF.
L’équipe de RCP Vision illustre la mise en œuvre d’une démarche MDA: Un modèle EMF, une transformation décrite par un DSL Xtext. C’est-à-dire comment un modèle EMF peut être transformé, enrichit, grâce à un DSL Guidieri et al. [2017a].

Après M2Doc : Doc2M

Ou comment l’approche Model to Document (M2Doc) n’est pas toujours suffisante.

Après une présentation intéressante de l’utilisation de la technologie M2Doc pour générer des PDF à partir de données structurées – conformément à un modèle et des gabarits (au format xdoc) – on nous montre que cela n’est pas toujours satisfaisant et un cas où il faut aussi synchroniser les documents avec les instances du modèle Michot [2017].

Big EMF models

Générer des applications à partir d’un modèle c’est bien, mais comment stocker, partager et gérer l’évolution d’un modèle, surtout quand celui-ci devient important ? Un tour d’horizon des solutions disponibles nous donne un aperçu des outils à disposition et de leurs limites, en particulier lorsque les modèles deviennent très gros, et quelques pistes pour y remédier Viaud and Lasalle [2017].

S’envoler vers les nuages

Quel que soit le domaine, la plate-forme Eclipse et ses applications font
face à un nouvel enjeu : la (re-)localisation croissante des applications dans
le cloud.

La plateforme Eclipse est historiquement plutôt tournée vers le Desktop, du moins en ce qui concerne l’interface utilisateur. Les nouveaux usages de l’informatique, réclament ce qui aurait paru un peu utopique quelques années en arrière: pouvoir utiliser n’importe quelle application, y compris un environnement de développement depuis n’importe quel appareil (pourvu que ses capacités soient adaptées) et depuis n’importe où (pourvu que l’on ait du réseau).

Eclipse RAP

Avec SWT comme base pour les composants graphiques, bon nombre d’applications construites sur la plateforme Eclipse aimeraient exposer leur interface utilisateur à travers les technologies du Web.

Eclipse RAP vise à remplacer les composants SWT natifs par un équivalent Web, avec à la clé l’espoir de pouvoir exposer n’importe quelle application RCP sur le Web.

Au fil du temps cela ne fonctionne pas trop mal mais SWT ayant été conçu pour fonctionner en local, sa transposition à travers un réseau reste verbeuse (beaucoup d’interaction entre le client et le serveur). Cela semble tout de même rester acceptable pour RCP Vision qui nous fait un retour d’expérience sur la mise en œuvre d’une applications Desktop et Web à partir d’un modèle EMF Guidieri et al. [2017b].

Eclipse Che

Eclipse Che vise, rappelons le, à offrir un environnement de développement en mode Web. Cela nécessite des changements assez importants par rapport à un IDE traditionnel:

  • Interface utilisateur déportée (ici le choix s’est tourné vers la réécriture de l’interface utilisateur avec GWT)
  • Serveur de compilation et de traitement
  • Espace de travail partagé ou multiples

On retrouve les gros changement de modèle d’architecture induis par le Cloud (approvisionnement, distribution serveur et client Web).

La présentation nous montre comment cela peut être mis en œuvre et laisse entrevoir les avantages que l’on peut en tirer Benoit [2017].

Theia

Après Eclipse Che dont je viens de parler, développé en Java; Eclipse Orion – un autre IDE en ligne, dédié aux technologies du Web, développé en JavaScript ; voici un autre projet d’IDE, Theia-ide, développé en TypeScript. Il n’est ni sous licence Eclipse, ni basé sur la plateforme et ses technologies, mais il ambitionne d’être l’« Eclipse du futur », aussi bien sur le PC que sur le cloud (https://github.com/theia-ide/theia).

Approvisionner une application Eclipse

Une application Eclipse est un agrégat de greffons. Plus le nombre de greffon augmente, plus construire une application devient complexe (récupérer, agréger, configurer, …).

Nombre d’équipe de développement sont confrontés à ce problème lorsqu’il s’agit de travailler avec une configuration cohérente de leur IDE et de synchroniser les évolutions et mises à jour. Fini le temps où il fallait installer et configurer manuellement chaque greffon, Eclipse Oomph répond à ce problème.

L’idée de Frauhofer FOKUS est de combiner Oomph, Maven et Docker pour automatiser l’approvisionnement d’une application Eclipse Bureck [2017].

Conclusion

Au fil des ans, le projet Eclipse continue de montrer son dynamisme, historiquement centré sur sa plateforme, l’écosystème se diversifie et agrège des projets parfois alternatifs ou sans rapport direct avec celle-ci. Outre l’ingénierie dirigée par les modèles, vaste sujet, qui m’a paru plus bouillonnante que jamais, trouver une solution pour des applications déployées sur le cloud me semble être le prochain défi pour la plateforme. Les modèles ne pourraient-ils pas être la clé ?

Bravo pour l’organisation impeccable, le programme riche et varié : difficile de choisir parmi les différentes conférences, heureusement petits fours et douceurs étaient là pour nous consoler.

Références

Barbero [2017]
Mikaël Barbero.
Debug java code like a pro.
2017.
URL
https://www.eclipsecon.org/france2017/sites/default/files/slides/2017ecf.pdf.
Benoit [2017]
Florent Benoit.
How to provide a portable developper workspace with eclipse che.
2017.
URL
https://www.eclipsecon.org/france2017/sites/default/files/slides/2017-EclipseCon-France-Chefile_0.pdf.
Bernard [2017]
Alain Bernard.
How ease unleashes the scientific power of airbus’ engineers in
eclipse.
2017.
URL
https://www.eclipsecon.org/france2017/sites/default/files/slides/ECF2017_EASE_full.pdf.
Bureck [2017]
Max Bureck.
From nothing to complete environment with maven, oomph and docker.
2017.
URL
https://www.eclipsecon.org/france2017/sites/default/files/slides/MavenDockerOomph.pdf.
Guidieri et al. [2017a]
Francesco Guidieri, Vincenzo Caselli, and Lorenzo Bettini.
The emf parrsley dsl: an extensive use case of xtext/xbase powerful
mechanism.
2017a.
URL
https://www.eclipsecon.org/france2017/sites/default/files/slides/EMF%20Parsley%20DSL%20Xtext%20case%20study.pdf.
Guidieri et al. [2017b]
Francesco Guidieri, Vincenzo Caselli, and Lorenzo Bettini.
Lesson learned from using emf to build desktop and web aplications.
2017b.
URL
https://www.eclipsecon.org/france2017/sites/default/files/slides/EclipseCon_France_2017.pdf.
Mandrikov [2017]
Evgeny Mandrikov.
Code coverage in practice.
2017.
URL
https://www.eclipsecon.org/france2017/sites/default/files/slides/Code%20Coverage%20in%20Practice%20-%20EclipseCon%20France%202017.pdf.
Michot [2017]
Arnaud Michot.
Doc2m update your model from your document in a breeze!
2017.
URL
https://docs.google.com/a/cetic.be/presentation/d/1Qs9IEBR9qUYc3urd3qCum02BZJciZSjUycoL4bMoNNs/edit?usp=sharing.
Viaud and Lasalle [2017]
Benoit Viaud and Jonathan Lasalle.
Emf model getting xxl? an overview of available solutions.
2017.
URL
https://www.eclipsecon.org/france2017/sites/default/files/slides/ECon17_Artal_XXL-Models.pdf.

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.

Comment utiliser les liens typés sur la plateforme DocDokuPLM ?

La structure produit est la structure d’assemblage qui décrit les liens physiques existants entre chaque composant d’un même produit. Mais comment peut-on mettre en évidence d’autres liens entre des articles ? Dans certains cas, on pourrait vouloir expliciter les relations électriques par exemple. En reliant les articles du point de vue électrique, on obtiendrait une autre structure de données s’apparentant davantage à un arbre de panne et permettant de régler les problèmes électriques plus facilement.

Grâce à la plateforme DocDokuPLM, vous pouvez définir différents arbres pour un même produit via les liens typés. Prenons l’exemple d’un bureau, voici sa structure produit complète :

Screen Shot 2015-08-19 at 11.20.29
Comme on peut le voir, cette structure n’indique pas les liens électriques pouvant exister entre certains articles. Pour définir un lien entre 2 articles, sélectionnez-les dans l’arbre et cliquez sur le bouton « Liens typés ». Ensuite ajoutez un lien et renseignez le nom et la description du type. L’article source est le premier article que vous avez sélectionné dans la structure. L’article destination est le second. Au besoin, vous pouvez inverser ces 2 articles. N’oubliez pas d’enregistrer.

Screen Shot 2015-08-19 at 11.21.23

Chaque lien typé créé avec le type « électrique » fera partie d’un nouvel arbre. Sélectionnez ce type dans le menu de configuration en haut à gauche pour afficher les nouvelles connexions produit.

Screen Shot 2015-08-20 at 15.04.39

Ce nouvel arbre typé montre alors les liens électriques entre les articles et rend la correction de pannes électriques plus aisée.

Vous pouvez ajouter une infinité de liens typés entre 2 articles (des liens de type énergétique, de dépendances…). Par contre, il est impossible de créer une boucle (lien cyclique) avec le même type de lien. Dans ce cas, le système détecte la création d’un lien cyclique et la rejète automatiquement pour éviter une boucle infinie.

first                                     second

 

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.