Le prix du CHUM remporté dans le coopérathon

Le 4 novembre dernier avait lieu la grande finale du coopérathon 2016.

L’équipe PMSIpilot Canada à participé à un projet avec le CHU mère-enfant de Sainte Justine.

Ce projet est une application de « Suivi Sécuritaire en Service Clinique ». Il s’agit d’un écran qui représente les chambres d’un service en reprenant leur configuration physique. Dans chaque chambre sont affichés une quinzaine d’informations dont notamment une alerte en cas de nécessité pour le personnel d’intervenir en urgence.

plus d’information sur le descriptif officiel du projet.

Notre équipe a remporté le prix du CHUM ( CHU de Montréal ) !!!
cooperathon victoire pmsipilot

 

3 membres de PMSIpilot participent au Cooperathon 2016 Montréal


Le coopérathon, c’est un lieu de rencontre entre des idées, des besoins et des compétences provenant de divers horizons qui se réunissent pour y répondre.

Marouane, Alexandre et Michaël, tous trois membres du bureau PMSIpilot CANADA, participent cette année au volet Santé du Coopérathon de Montréal.

Le lancement officiel aura lieu ce vendredi 7 octobre au centre de recherche du CHUM.

D’autres informations seront ajoutées tout au long de l’événement qui se terminera le 4 novembre. À bientôt avec plus de détail sur le projet sur lequel nous embarquerons ;)

pmsipilot-canada-wide

PMSIpilot Canada 1176 rue BISHOP H3G 2E3 Montreal, Qc +1 514-370-5452
 

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 ?

 

PMSIQuotes

Sans « T » ?!

– Va sur « production/santé »
– Heu… sur « producion » ?

5ème élement, raspberry PI zero et IP over Avian Carriers

– Le temps est sans importance
– Avec le raspberry PI ?
– Non, avec un pigeon

Le temps des cathédrales

– J’ai l’effet cathédrale.
– Tellement c’est vide entre tes deux oreilles ?!

Le PMSI pour les nuls

– RSS c’est l’inverse de SSR !

Fan de RPG

– On a le Requêteur au support
– L’heureux quêteur ?

Les logos

– Nous au moins on a un vrai logo
– Comment tu peux déterminer la véracité d’un logo ?
– Si tu peux en faire une peluche c’est un vrai logo

Mesurage de MR

– Bon, vous avez le droit de voir ma MR.
– Oula ! Elle est presque aussi grosse que la mienne celle-là !

Je suis…

– heu … http://brew.sh/linuxbrew/ quelqu’un a un avis dessus ?
– Je suis mitigeur
– non ça c’est pour l’eau
– je suis robinet
– je suis batman

Au sujet du cannibalisme

– Mangez @manu
– Un manu maxi best of

Tous mes goûts sont dans la nature

– On ne dit pas « c’est pas bon », on dit « je n’aime pas »
– Ben…je n’aime pas parce que c’est pas bon !

 

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

 

Diving in Docker

Chez PMSIpilot, nous aimons avoir une infrastructure moderne, performante et surtout, simple à maintenir. En interne, nous avons un outillage assez conséquent pour supporter notre organisation. Déployer ces services sur des machines physiques est, d’une part coûteux et, d’autre part, difficilement maintenable. Nous avons choisi il y a environ un an de basculer la plupart des services non-critiques sur Docker.

… 

 

Retour sur le Forum PHP 2015

Encore un évènement autour de PHP qui se termine. Encore un Forum assez exceptionnel pour moi. Beaucoup de rencontres, de débats intéressants et un maximum de partage !

Encore une fois, l’AFUP et les conférenciers ont fait un travail monumental pour nous proposer un évènement de qualité dans un lieu très sympatique avec une ambiance exceptionnelle.

Un évènement très riche en rencontres qui m’a permis d’apprendre de nouvelles choses, d’ouvrir les yeux sur d’autres mais surtout, d’échanger… et de consommer beaucoup de café :)

… 

 

Introduction au Mob Programming chez PMSIPilot

Le Mob Programming est une technique de travail qui propose de développer une feature en équipe à la manière d’un pair-programming démultiplié !

Concrètement toute l’équipe se retrouve autour d’un PC avec vidéo-projecteur et chacun a tour de rôle sera chargé de coder en étant guidé par les réflexions de l’équipe.

Ainsi l’ensemble des avis peuvent être entendus et débattus au fur et a mesure que la feature prend forme (validation d’un pattern, d’une librairie , d’une interface, …).
On évite donc les allers-retours autour d’un développement et les risques d’effets tunnels.

… 

 

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.
…