Forum PHP 2017

Petit résumé des conférences auxquelles j’ai pu assister dans le cadre du Forum PHP 2017 à Paris le 26 Octobre dernier.


1 > Cocktail temps réel pour l’Olympia

par Amélie DUVERNET

Présentation d’une stack technique pour la mise en place d’une application dédiée à la gestion des sièges de l’Olympia.
L’accent a été mis avant tout sur le fait de gérer le temps réel : lorsque les billets sont scannés, via une douchette, on voit le plan des sièges se remplir progressivement sous nos yeux.

  • PHP : pour la gestion de la sécurité et du back
  • redis : bdd no sql
  • RabbitMQ : gestion des notifications basée sur le protocole AMQP
  • NodeJS : daemon qui tourne en tâche de fond et qui écoute RabbitMQ
  • socket.io : web socket avec NodesJS pour le temps réel
  • AngularJS : pour un front dynamique

2 > AB testing chez M6 Web

par Nastasia SABY & Fabien de Saint PERN

L’AB testing est une pratique issue du marketing qui vise à évaluer les réactions d’une population donnée (on parle alors de panel) vis à vis des modifications apportées à un produit particulier.
On peut par exemple imaginer une entreprise qui vend de la lessive à ses clients. Elle décide de créer une évolution de son produit. Sa question est alors de savoir si effectivement l’évolution de son produit est appréciée ou non des consommateurs.

Il ne suffit pas d’avoir une bonne idée : il faut prouver que l’idée est bonne.

Au sein de M6 Replay, ils utilisent ce concept afin de tester l’approbation des nouvelles évolutions et features apportées à la plateforme. Il est ainsi possible de mettre en place :

  • un AB test : deux versions de l’API.
  • un ABC test : trois versions de l’API.
  • un AABC test : trois versions de l’API, mais on fait croire au pannel qu’il y en as quatre.

Dans un AB test, si la version B de la plateforme embarque une modification qui risque potentiellement de solliciter de manière accrue le serveur, on parle alors de canary testing.

canary testing

Mais oui, vous savez le canari que les mineurs amenaient avec eux dans la mine pour prévenir les coups de grisou.
En gros, on déploie la feature auprès d’un panel réduit d’internautes et si le serveur ne tient pas la charge c’est que c’est trop gourmand en ressources et pas assez optimisé.

Ok, mais concrètement comment ça se passe ? Comment on le met en place ? Comment on exploite les résultats ? Malheureusement les intervenants ne se sont pas attardés sur ce sujet :(

Je sais juste qu’ils rapatrient tous leurs résultats de test vers une plateforme big-data. J’ai ainsi pu glaner quelques informations sur leur stack à la volée :

  • cassandra
  • Hadoop
  • HDFS
  • Hive

Pour aller plus loin :


3 > Software Management Lessons From The 1960’s

par Larry GARFIELD

Dans la série “ces vieux concepts toujours d’actualité qui nous font bien comprendre que l’on a rien inventé de nouveau”, cette conférence était bien sympa.
“Le Mythe du mois-homme” ou “The Mythical Man-Month: Essays on Software Engineering” est un livre de Frederick BROOKS dont la première édition remonte à 1975.
L’auteur nous démontre la différence entre la production industrielle et le génie logiciel, en démolissant méthodiquement les mesures jours/hommes et mois/hommes, ainsi que toutes les pratiques qui en découlent.

Le Mythe du mois-homme

S’il faut 30 jours/hommes pour un projet, cela ne veut pas dire qu’il faut 30 hommes pour finir le projet en 1 jour.

L’intervenant reprend les grands concepts du livre et tente des les appliquer à notre époque et nos métiers quotidiens. Résultat : rien n’a changé.
Le livre n’en ressort que plus juste et correct dans sa vision à long terme.

La problématique reprise de projet

Pour aller plus loin :


4 > L’art subtil du nommage

par Julien JANVIER

Je m’étais pas mal intéressé à ce sujet à travers plusieurs articles. On y exposait souvent une vision extrémiste qui prônait le fait de ne surtout pas utiliser de doc, en se basant sur le principe du juste nommage, celui-ci devant répondre à toutes les problématiques inhérentes au besoin d’information sur le code.

Après avoir balayé les bases évidentes du nommage (que je ne listerai pas ici), l’intervenant nous livre quelques idées intéressantes :

  • Ne cherchez pas à nommer. Oui je sais c’est bizarre, mais somme toute logique. On nomme un chien, un enfant, un produit, … En programmation on décrit plus que l’on ne nomme. Que fait ma classe ? A quoi sert-elle ? Quelle est sa responsabilité ? etc …
  • Bien souvent on a tendance à se persuader que l’on a créé quelque chose de révolutionnaire qui fait plein de choses ultra complexe : en fait on vient juste de créer une UserFactory. Il faut rester simple et humble.
  • Ne cherchez pas à décrire ce qui n’existe pas. Si vous bloquez sur un nom, posez vous la question de savoir quelle est la responsabilité et l’utilité de votre classe, méthode ou variable. Bien souvent l’erreur de conception peut être révélée lors du nommage.

5 > Le streaming d’API : Pourquoi ? Comment ?

par Audrey NEVEU

Conférence assez complète, où l’intervenante insiste dans un premier temps sur l’importance de streamer nos API au lieu d’utiliser une architecture REST classique. L’idée de base ici part de ce postulat : “Plutôt que de demander en permanence au serveur si il y a eu du changement sur certaines ressources, pourquoi ce ne serait pas ce dernier qui préviendrait les utilisateurs du changement ?”.

On va donc parcourir plusieurs solutions pour mettre en place cette idée.

  • Le WebHook : c’est un concept non normé (pas de spec, pas de doc centrale). Pour l’appréhender rapidement le plus simple est d’utiliser l’API de github.
  • Le PubSub : il s’agit d’un protocole, donc plus cadré, basé sur le publish / subscribe. Il introduit la notion de Hub qui va relayer l’information :
    Publisher => Hub => Subscriber.
  • Le Web-Socket : là on passe sur de la push technologies bi-directionnelle. Il dispose d’un protocole dédié RFC-6455 et permet de traiter le texte et le binaire.
  • Le Server-Sent Event : push technologies mono-directionnelle (serveur => client). Passe par le protocole HTTP et ne traite que le texte. A ce jour il reste non supporté par IE :(

Pour aller plus loin :


6 > Climbing the Abstract Syntax Tree

par James TITCUMB

Là on décortique des algos très simples en php pour rentrer dans leurs interprétation par le compilateur.
Le but idéal serait de comprendre comment optimiser les algo php pour faciliter le travail du compilateur et gagner en performances ! Mais c’est assez complexe … En vérité il s’agit plus d’une appréhension de l’AST : l’arbre syntaxique abstrait mis en place dans php 7.

Si l’on schématise la manière dont php fonctionne, voici ce que l’on obtient : Code PHP => Lexer + Parser => Compiler => Opcache => Execution.
l’AST est une représentation de données utilisée dans la phase de compilation.

Ce qu’il faut retenir :

Pour aller plus loin :


7 > Développeur et protection de la vie privée

par Erwan RICHARD

C’est un vaste sujet sociétal, qui se prête plus à l’exercice du débat plutôt qu’à celui de la conférence. Le but de l’intervenant n’est pas de nous guider vers un process ou une éthique mais plutôt de nous interpeller autours de cette question : “En tant que développeur, qu’elle est ma responsabilité vis à vis du respect de la vie privée des internautes ?”.

D’un point de vue utilisation, on retiendra la multitude d’outils alternatifs présentés : sharingbuttons.io, piwik, leaflet, mapbox, framasoft, …

A noter la mise en place le 25 Mai prochain de la GDPR, directive européenne relative à la protection de la vie privée des internautes ; et dont la mise en place risque de bouleverser une multitude de modèles économiques en place dans de nombreuses structures.

Internet et le mythe de la vie privée

Pour aller plus loin :


8 > C’est quoi être différent dans l’IT ?

par Haikel GUEMAR

Même si l’on n’en a pas forcément conscience, nos métiers sont également soumis, à des degrés divers, aux habituelles discrimination en vigueur : sexe, orientation sexuelle, age, milieu social, culture, …

Comment identifier la discrimination ? Comment la combattre ? Comment faire de la différence une richesse ? etc …

Beaucoup de questions qu’il est légitime de se poser, peu de réponses concrètes. Il est effectivement très difficile de répondre à ces problématiques en 45 min. L’intérêt étant avant tout de nous éveiller à certaines situations, de prime abord anecdotiques, mais qui franchissent en réalité certaines limites, censées nous interpeller.

 

Retour de mes deux jours à la Blend Web Mix 2017

Aujourd’hui je vais vous présenter, un peu tard on en conviendra, mon retour du salon la Blend Web Mix 2017. J’ai eu la chance de pouvoir y participer les deux jours et je m’en vais vous faire un debrief de toutes les conférences, toutes très intéressantes, que j’ai pu voir. Suivez-moi !

GraphQL, l’avenir du REST

La première journée commence fort avec une savoureuse introduction à cette technologie qui fait frémir les développeurs(euses, eux ?) sur Twitter depuis déjà quelques semaines, je parle bien entendu de GraphQL. Présenté par un habitué des conférences, François ZANINOTTO, accompagné par un non moins talentueux collègue (faute de connaitre son nom, désolé). Les deux amis nous ont présenté un état des lieux de l’architecture REST (et d’autres solutions plus anecdotiques) et en quoi GraphQL ça rox. Et c’est vrai que ça rox, je ne vais pas vous refaire la présentation ici, mais il faut savoir que GraphQL va nous permettre de fusionner plusieurs requêtes HTTP en une seule.

En effet dans une optique REST il est récurrent de devoir faire une première requête pour récupérer un parent puis en faire plusieurs autres pour récupérer les enfants. Ici GraphQL nous fournit un langage permettant de tout fusionner en une seule requête; quand je vous disais que ça roxait.

Ensuite coté serveur, GraphQL vous demandera de coder quelques resolvers qui auront pour objectifs de retourner l’information, GraphQL se chargera de résoudre les interdépendances et de remonter les données (comme pour la résolution d’un graphe, oui voilà d’où vient le graphe de GraphQL).

Ainsi on pourrait résumer cette conférence par TL;DR don’t use REST anymore, use GrapQL instead. Mais c’est sans compter sur l’intelligence de cette présentation, puisque les deux speakers ont fini leur présentation en évoquant les points qui ne vont pas avec GraphQL (notamment le fait que GraphQL se moque de la méthode HTTP utilisée pour requéter l’API, oui oui on peut récupérer des trucs via un DELETE, un DELETE !).

Au final beaucoup de rêves brisés, mais que voulez vous, la réalité est parfois dure.

Vous pouvez retrouver la présentation ainsi que les slides sur Slideshare.

Créer une expérience WebVR cross-plateformes

Des idées plein la tête j’ai enchainé avec une autre conférence, toujours dans les technologies de demain : la VR. Et plus spécifiquement la VR dans une page web, so sexy.

Conférence présentée par David ROUSSET, le monsieur est un grand fan des jeux vidéos, du web et de la VR (le bougre possède plusieurs casques VR). Sa présentation tenait sur la découverte de sa librairie javascript de création de contenu 3D, Babylon.js et de son extension WebVR.

Connaissant David depuis maintenant un moment, bien avant la VR et bien avant qu’il rejoigne Microsoft (aurais-je oublié ce détail ?), je n’avais pas besoin d’être convaincu pour dire que sa librairie est efficace et se pose comme une concurrente sérieuse à Three.js. Et ces multiples démos en live l’attestent bien assez.

PS : David si tu passes ici, merci pour tes tutos game dev sur ton blog ;)

Sa présentation sur Youtube

Concevoir un robot d’interaction : des pieds à la tête

En parallèle de la conférence de David, je suis allé faire un tour à celle qui parle de robot (qu’est ce qu’il faut pas que je fasse pour couvrir le plus de sujet possible).

Conférence présentée par Amélie CORDIER, ancienne professeur et maitre de conférence à l’IUT Lyon 1, et Jade LE MAÎTRE co-fondatrice de Hease Robotics. Toutes deux se sont lancées dans un jeu de questions / réponses dans le domaine de la robotique.

Beaucoup de questions pertinentes, sur le présent de la robotique et sur son avenir. On se rassure d’être encore très loin d’une vie à la Blade Runner et on se désole de l’être autant de celle avec des Wall-E.

En bref une très bonne FAQ parfois coupée par l’arrogant, mais terriblement mignon petit robot Cozmo.

Leur présentation sur Youtube.

BATTLESTAR GALACTICA: Saison 5 – Les Cylons passent dans le cloud avec Vert.x

La journée se poursuit avec une présentation inspirée et, on ne va pas se mentir, un peu old school (Battlestar Galactica – 1978) sur le pilotage d’une infrastructure entièrement microservices.

On retrouve un Philippe CHARRIERE sympathique présentant Vert.x un framework événementiel pour la JVM ou comment brancher plusieurs services dans différents langages et les faire fonctionner entre eux.

Le tout illustré par une bataille – presque – impressionnante de points de couleur. Il va falloir avoir un peu d’imagination pour voir les vaisseaux scintillants des Cylons.

Sa présentation sur Youtube.

Un site dynamique sans serveur (serverless), c’est possible !

Peut-être la présentation qui m’a le plus laissé sur ma faim, présentée par une Virginie MATHIVET beaucoup trop motivée pour une fin de journée, elle nous fait la présentation, accompagnée de son DevOps, de la procédure à adopter pour faire un site dynamique sans serveur.

N’espérez pas une révolution à base de magie cosmique, cette présentation nous résumera la marche à suivre pour créer un site avec une base de données via les services d’Amazon, la plateforme Saas. On se retrouve avec une course contre la montre de clics frénétiques sur les interfaces ô combien peu ergonomiques d’Amazon.

Au final peu de choses innovantes, on lance deux – trois services Amazon, on pousse son code front et voilà votre site est prêt, tout chaud sorti du four Amazon.

Spoil alert, vous pouvez faire la même chose sur Azure.

Leur présentation sur Youtube.

Voyage au centre du cerveau humain ou comment manipuler des données binaires en Javascript

Le deuxième jour c’est Thomas JARRAND qui ouvre le bal avec une présentation intrigante mélangeant Javascript, binaire et cerveau. Ou autrement dit, comment parcourir une IRM au format binaire grâce à Javascript.

Développeur chez Elao, Thomas a eu pour objectif de créer un #seriousgame dans lequel le joueur doit analyser des IRM de cerveau pour le compte de l’université de Bordeaux et de Harvard Medical School, le tout en Javascript.

Pour ce faire Thomas nous explique comment manipuler des chaînes binaires, les découper et les transformer en pixels qui, mis bout à bout, forment une image.

Je vais pas vous mentir, je suis un grand fan de Javascript et ce genre d’initiative me parle beaucoup. C’est donc tout naturellement que j’ai beaucoup aimé cette présentation claire et fort intéressante sur la manipulation de chaînes binaires en JS.

Enfin la démo finale est clairement impressionnante, c’est fluide, ça fonctionne (même sur mobile) bref c’est Javascript.

La présentation sur Youtube.

Electron, une alternative intéressante?

Petite présentation de Electron par Florent MOIGNARD qui nous fait un bilan en 15 min de cette technologie montante. Faisant le comparatif entre application web et application native, il finira par les avantages et les inconvénients d’Electron.

Petit fait intéressant, il existe déjà des d’applications Electron qui sont utilisées tous les jours: Slack, Atom etc …

Sa présentation sur Youtube.

Apprentissage statistique et analyse prédictive en Python avec scikit-learn

On enchaîne avec une présentation d’une toute autre nature puisqu’elle parle d’IA et d’analyse prédictive présenté par Alexandre GRAMFORT, chercheur à l’Inria.

Alexandre commence par poser les définitions d’intelligence artificielle, d’analyse prédictive, de machine learning et de deep learning, soucieux de sensibiliser sur la différences de ces aspects gommant toute confusion.

Par la suite Alexandre nous présente le principe de prédiction ainsi qu’un survol des différents algorithmes de prédiction.

Claire et bien vulgarisée, cette présentation était intéressante et permet d’avoir un aperçu du domaine de l’analyse prédictionelle.

Jamais trop matheux et toujours compréhensible, Alexandre a su nous intéresser à un domaine plutôt obscur pour les simples mortels dont je fais partie.

Sa présentation sur Youtube.

Des sites web plus performants grâce à l’intelligence artificielle

Encore une présentation dans le domaine de l’intelligence artificielle. Lucas NACSA nous présente des cas concrets d’utilisation de l’IA dans le domaine du web marketing.

On passe de la prédiction des sorties de stock, de l’influence des soldes ou encore à des moteurs de recherche intelligents grâce à des données extérieurs, comme par exemple la météo.

L’objectif final est de comprendre les habitudes des utilisateurs, leurs goûts et ce qui pourrait leur faire plaisir. Grâce aux réseaux de neurones, on peut prédire des articles qui seraient susceptibles de plaire à un potentiel client et ainsi le site e-commerce s’adapte à celui-ci.

Techniquement intéressant, c’est cependant ce genre de présentation qui renforce mes convictions qu’internet devient de plus en plus une bulle personnalisée. Nous enfermant toujours plus sur ce qu’on connait et qu’on aime pour nous réconforter. Quitte à perdre notre liberté de peur de découvrir d’autres choses inhabituelles, #jaimalàmoninternet.

Sa présentation sur Youtube.

Audio procédural : la révolution WebAssembly!

Yann ORLAREY nous présente les technologies de la création de son par ordinateur. Utilisées par exemple dans le jeux-vidéos, évitant de charger des fichiers sonore en favorisant la création de son par l’ordinateur.

Yann nous présente ainsi l’univers de la création de son via l’API audio Javascript et de la nouvelle librairie WebAssembly.

Comme son nom l’indique, WebAssembly est la concaténation de Web et Assembly (l’assembleur), c’est le souhait d’offrir un langage bas niveau performant.

L’objectif ici et de pouvoir programmer du son de façon performante dans un navigateur. Il en profite également pour présenter Faust, le langage sur lequel il travaille.

Pas forcement facile à comprendre, mais cependant intéressante, cette présentation se destine avant tout à une niche. Heureusement la petite vidéo démo de fin nous montre un cas concret de son explication (en plus de bien roxer).

Vidéo de la présentation sur Youtube.

Réalité virtuelle et augmentée, ces nouvelles technologies au service de la formation et de l’emploi

Nous voici enfin sur la dernière conférence que j’ai pu voir. Présenté par Loic LEXTRAIT, je pensais ne rien apprendre sur la réalité virtuelle et augmentée puisque je possède moi-même un casque VR et que je me suis pas mal renseigné sur le sujet (à 900€ le matos, on réfléchit à deux fois).

Et pourtant, outre l’aspect technique divergeant des deux technologies que Loic a su parfaitement expliquer, c’est surtout l’aspect formation qui m’a particulièrement emballé.

Comment ces technologies peuvent aider la formation ? Et bien Loic y répond avec beaucoup d’enthousiasme en montrant des exemples de réalisation de sa boite de prestation. On voit par exemple une simulation VR d’infirmier(e).

Cette présentation fut réellement rafraichissante, Loic à su transmettre sa passion de ces technologies, imaginer pouvoir apprendre de nouvelles compétences manuelles dans un univers virtuel en 3D immersif fait rêver. Qui a dit que les jeux vidéos abrutissaient ?

Malheureusement la vidéo Youtube de sa présentation ne possède pas la bonne bande son, bien regrettable pour une si bonne conférence.

Conclusion

On retiendra finalement de cette Blend Web Mix un buffet bien copieux accompagné d’une Ninkasi rafraîchissante, ah pardon vous vouliez peut être une conclusion constructive, je reprends…

La Blend Web Mix peut se vanter de proposer des conférences abordant des sujets différents et portés sur la haute technologie, au moins sur celles dites techniques. Mais ça reste souvent du survol, on ne va que rarement dans la technique pure. Sur ce point il faut noter que la Blend Web Mix se destine avant tout à un public plus hétérogène qu’un public technique.

Globalement je suis satisfait de ces deux jours, les conférences sont souvent de qualité et l’organisation force au respect. La salle commune est immense, Cité Internationale oblige me direz-vous, et de nombreuses activités viennent combler les trous entre deux conférences.

Merci d’avoir lu mon retour, je tiens à préciser que tout le contenu est totalement subjectif et provient pour la plupart de mes souvenirs, je ne peux donc pas vous garantir que mon récit ne soit pas un peu, beaucoup, romancé par moment.

 

Intégration continue : de Jenkins à Gitlab CI

L’intégration continue a toujours été un élément très important pour l’équipe technique du Groupe PSIH.
Lorsque nous nous appelions encore PMSIpilot et que nous ne maintenions qu’une seule suite logicielle, les tests, et la qualité en général, étaient déjà très importants. À l’époque, nous utilisions exclusivement Jenkins pour lancer nos jobs automatiquement.

Nous avons donc historiquement un cluster qui a évolué au fil des années. Nous avons commencé avec quelques slots puis nous sommes passés à quelque chose de plus important, avec une dizaine de serveurs (un maître et neuf esclaves) et donc beaucoup plus de slots. Cela nous allait parfaitement, d’autant qu’à cette époque nous n’utilisions pas de solution de gestion de code source telle que Github ou Gitlab.

Il y a environ 4 ans, nous avons décidé de migrer toute notre gestion de code source sur Gitlab et depuis, nous avons scrupuleusement suivi toutes ses mises à jour. Nous appliquons chaque mise à jour 1 mois après sa sortie officielle afin de bénéficier directement de tous les correctifs mineurs. Du coup, à un moment, nous avons hérité de Gitlab CI.

Nous n’avons pas commencé à l’utiliser tout de suite. Jenkins nous allait très bien malgré quelques problèmes liés à sa lourdeur et à sa complexité. Au fil du temps, ces problèmes sont devenus de plus en plus présents et nous avions une boucle de feedback de plus en plus longue sur les développements : il n’était plus possible d’attendre une demi-heure, voir plus, pour avoir le résultat de nos tests unitaires.
Gitlab CI était donc notre sauveur !

Nous avons donc commencé, petit à petit, à migrer les jobs les moins complexes vers Gitlab CI. Ce changement a été très bénéfique car, non seulement notre boucle de feedback a été drastiquement réduite, mais nous avons en plus un retour immédiat directement dans Gitlab, dans les Merge Requests. On peut donc facilement consulter les commentaires de revue de code et le statut de l’intégration continue.

Il nous restait un problème à régler : nous n’avons pas pu nous passer totalement de Jenkins. En effet, Gitlab CI tourne, chez nous, sur une infrastructure basée sur Docker et nous devons être capable de construire et lancer des machines virtuelles en intégration continue. Jenkins était déjà équipé pour cela et porter tous ces mécanismes dans Gitlab CI était trop coûteux. Du coup, les développeurs se retrouvaient souvent à passer de Gitlab à Jenkins afin de planifier correctement leurs jobs et consulter leurs statuts.

C’est comme ça que Jenklab CI est né !

Jenklab CI

Ce petit outil, écrit en Javascript et utilisable en ligne de commande ou via un conteneur Docker, utilise l’API de Jenkins et nous permet de faire un pont avec Gitlab CI : il est capable d’exécuter un job Jenkins depuis un pipeline Gitlab CI en injectant toutes les variables prédéfinies par l’environnement d’intégration continue de Gitlab.

Grâce à cela, nous avons pu régler les problèmes que nous avions : nous pouvons garder en l’état tous nos jobs qui construisent et déploient nos machines virtuelles et nous avons un retour direct dans Gitlab, dans l’interface des Merge Requests.

Jenklab CI se veut simple et efficace : il ne propose pas de fonctionnalité très avancée, juste le strict minimum pour garantir un confort d’utilisation de nos deux solutions d’intégration continue. En bonus, nous pouvons utiliser toutes les options proposées par Gitlab CI pour choisir quand lancer un job Jenkins (déclenchement manuel, automatique …)

J’ai déjà donc cité le fait que les variables de l’environnement Gitlab CI sont transmises à Jenkins, ce qui est idéal pour configurer automatiquement vos jobs en fonction de certains paramètres (branche Git à utiliser, dépôt à cloner …).

Le log du job Jenkins est affiché directement dans la console Gitlab CI, nous pouvons donc garder l’historique complet des exécutions même si, du côté de Jenkins, les logs sont purgés régulièrement.

Pour finir, Jenklab CI est capable d’annuler un job Jenkins lorsque le job correspondant est annulé dans Gitlab CI.

Nous utilisons cette solution depuis quelques mois maintenant pour tous nos jobs qui sont coûteux en temps, qui demandent une infrastructure plus complexe ou qui déploient des livrables (la construction et publication de nos RPMs par exemple). Nous sommes très satisfaits de cet outil.

Si vous souhaitez l’utiliser, n’hésitez pas à jeter un oeil au dépôt sur Github et éventuellement à nous soumettre vos remarques ou demandes d’évolution.


Le Groupe PSIH recrute des développeurs(euses) pour son équipe R&D. Si vous êtes intéressé(e)s, n’hésitez pas à consulter l’offre et à nous contacter.

 

Langages de programmation… Il y en a pour tout le monde

Notre principal produit chez PSIH est une plateforme décisionnelle extrêmement riche en fonctionnalités utilisée par plus de 700 établissements hospitaliers en France. Ceci nous amène à utiliser différents languages de programmation pour résoudre différentes problématiques techniques. Voici un aperçu de ces langages qui composent notre stack technique.

chart (2)

PHP

Tout a commencé avec du PHP, avant de passer à une architecture orientée micro-services, notre plateforme était composée d’une seule application monolithique en PHP. Avec l’architecture actuelle, PHP reste présent dans nombre d’applications fullstack Symfony2 mais aussi de services backend (PHP 5.6 pour le moment mais la migration vers PHP 7 est prévue). D’autres amis se sont joints à la fête.

Javascript

Javascript représente le language principal des différents frontends de la plateforme (ES 2015). Il est notamment utilisé dans un certain nombre d’applications AngularJS. Mais nous utilisons également javascript dans des outils et services NodeJS. Nous sommes également amenés à utiliser du Rhino pour la partie intégration de données.

Typescript

Nous avons entamé la migration Javascript ES6 vers Typescript sur certains projets et ce pour différentes raisons que je vous laisserai découvrir dans notre précédent article Why Typescript ? (Angular2, we are coming!)

Java

Java est utilisé dans différents services backend. Nous prévoyons une migration de Java au JDK8. Nous avions pour ainsi dire déjà amorcé la transition en utilisant Guava pour imiter les Optional et Lambda.

Less

Nos feuilles de styles sont écrites essentiellement en Less (pmsipilot-ui); un passage à Sass est envisagé avec la sortie de Twitter Bootstrap 4

Shell / Python / Ruby

Dans le cadre de l’industrialisation de la plateforme et du continuous delivery, nous sommes également amenés à utiliser différents du shellet du python pour du scripting et du ruby pour écrire des cookbooks Chef et configuration Vagrant.

SQL

le SQL (et PL/SQL) occupe forcément une partie importante de toute plateforme décisionnelle, notamment dans le développements de flux d’intégration et la génération de requêtes de reporting.

Le C

Pas énormément ok, mais on en fait quand même :).

Alors vous voulez vous joindre à la fête ?

 

Refactoring : Improving the design of existing code

Retranscription brute de pomme de la petite rétro diffusée en interne

Hier soir se tenait le book club de Lyon, organisé par le software craftmanship de Lyon. On était une petite dizaine, je vous fais un résumé rapide :

La séance portait sur les deux premiers chapitres de Refactoring de Martin Fowler, qu’on ne présente plus

Couverture du livre

La discussion a commencé sur la difficulté de faire du Refactoring en partie à cause d’une vision biaisée que le monde du business logiciel lui donne. Fowler explique à ce titre que le Refactoring n’est pas une tâche à part entière mais plutôt une étape de chaque développement. On aura paraphrasé Kent Beck :

To make a change, make the change easy and then make an easy change.

L’excuse “on a pas le temps on verra lors de la prochaine refacto” est un non sens financièrement parlant puisqu’une dette technique est quasi toujours mal maitrisée. Certes, certaines entreprises ont besoin d’une petite dette technique pour bien fonctionner, mais souvent la dette s’accumule et la période de refacto apparaît de plus en plus imaginaire

Quand refacto et quand ne pas refacto du coup ?

If it ain’t broke, don’t fix it

Ne pas aller refacto du code quand on sait que le code ne va pas évoluer. Le mieux est donc de refacto pour chaque feature donnée mais ça je vous en ai déjà parlé

On a évoqué l’importance du code review et des habitudes de chacun pour paraitre diplomatique dans les remarques. L’étape de la revue de code, ou celle du cross testing (qu’on fait peu ici), est également une bonne étape pour faire du refacto

En outre, la force des tests, c’est qu’ils permettent que le processus de refactoring soit sans régression.

Mais aussi : c’est difficile d’être un génie et de voir les patterns émerger sur du code legacy. Une bonne solution c’est de faire des tests pour faire émerger le “Quoi?” plutôt que le “Comment?”. Le quoi désigne le besoin utilisateur (dans tel contexte, je fais telle action, je m’attends à tel résultat). Le comment désigne l’implémentation. Pour chaque test qu’on veut créer on se rend compte qu’on ne peut pas tester en l’état actuel des choses (besoin de mocker 100 objets par exemple) et alors on fait un petit refacto. Quand s’arrêter ? C’est l’objet du chapitre 3 !

Prochaine session : http://www.meetup.com/Software-Craftsmanship-Lyon/events/227528781

 

Pourquoi sommes nous passés à Typescript ?

Il y’a quelques mois, nous avons migré notre frontend (4/5 applications Angular.JS, et pas des plus petites) en ES6 alias ES2015 (de façon incrémentale grâce à un workflow mi ES5, mi ES6). Je ne vous apprends rien du gain en maintenabilité et confort au niveau développement que ça nous as apporté. Hors avec le bond en popularité qu’est en train d’acquérir Typescript (Angular2 ne doit pas y être étranger), nous nous sommes posés la question du passage à Typescript.
… 

 

Workflow ES6 au sein d’une application Angular existante ES5

ECMAScript 6 (alias spécification de la future version de Javascript) se rapproche de plus en plus d’une version finale. De nombreux outils permettent déjà d’utiliser la syntaxe et les fonctionnalités d’ES6 avec du code généré compatible avec les navigateurs récents (et même un peu plus vieux). Et donc afin de limiter au maximum la dette technique au sein de nos applications, nous pensons que le changement, c’est maintenant.
… 

 

PMSIpilot UI, le thème bootstrap made in PMSIpilot

Chez PMSIpilot, nous développons une multitude d’applications web, que ce soit pour nos clients, ou pour des outils internes. Et pour chaque application, nous sommes confrontés à la problématique du design, de la cohérence par rapport aux autres applications. L’idée d’avoir une base commune s’est donc rapidement imposée.

…