Anthony
Laurito

« L'incurable Geek. »

Réalisations

Quelques-unes de mes réalisations. Liste non exhaustive — cliquez sur un projet pour le détail complet.

Bulletins météo détaillés et personnalisables, édités à partir de données d'API.

En savoir plus

Un vaste robot qui étend les fonctionnalités du CRM Sellsy via ses API.

En savoir plus

Un ORM développé from scratch pour le WLangage, entièrement en POO, avec jointures.

En savoir plus

Le livre des best practices pour débuter en dev.

En savoir plus

Application iOS de récupération des retours NOEMIE, avec références unifiées.

En savoir plus

Montage vidéo, management, formation… et des contributions sur Developpez.com.

En savoir plus

Quadro

Quadro est un logiciel développé dans le cadre de mon activité indépendante. Il permet d'éditer des bulletins météo très détaillés et personnalisables.

Pour ce faire il récupère une multitude d'informations concernant la météorologie des sites géographiques via des API. Ces données sont ensuite retraitées par un algorithme confidentiel. Enfin, les bulletins sont contrôlés et personnalisés individuellement pour apporter davantage de précisions avant d'être envoyés par email.

Quadro dispose d'un ORM (que j'ai écrit, Windev n'en disposant pas par défaut), permettant de faciliter les interactions avec les objets qui représentent et encapsulent de façon abstraite la base de données.

La base de données était à l'origine une base HFSQL Client/Serveur de plus de 45 millions de lignes. Elle a désormais été migrée vers PostgreSQL.

Les traitements de récupération de données auprès des API, d'édition PDF, et d'envoi par email, sont tous multi-threadés pour plus de rapidité.

Ci-dessous, le résultat final d'un bulletin fictif créé pour l'exemple :

Exemple de bulletin météo généré par Quadro

DTKS

DTKS est un logiciel développé dans le cadre de mon activité indépendante.

Son interface est anecdotique car son but est justement de ne pas en avoir : c'est un vaste robot !

Le but est d'utiliser les API du CRM Sellsy pour faire toute sorte d'opérations. Modifications récurrentes, mises à jour en masse, calculs de statistiques détaillées avec édition de tableaux Excels, gestion des relances… c'est un véritable couteau Suisse qui m'a été demandé, pour étendre les fonctionnalités de Sellsy grâce à leur super API 💪

Il possède un ORM dont la déclinaison permet de stocker (de façon chiffrée) les JSON récupérés afin d'agir comme un cache local de la base Sellsy. Il est orchestré via le planificateur de tâches de Windows et accepte tout un jeu de lignes de commande pour régenter ses actions. On peut même l'appeler par mail pour plus de simplicité.

Sa conception POO robuste lui permet de fonctionner dans l'ombre à chaque jour qui passe et fournit une encapsulation étendue de l'API Sellsy, dont l'interrogation est très facile. Il prend même déjà en charge la version 2 de cette API, qu'il utilise pour certains traitements.

Grâce à lui, de nombreuses opérations manuelles sont désormais automatiques. Et les avantages sont multiples :

  • c'est beaucoup plus rapide (des dizaines d'heures de travail par mois sont économisées) ;
  • les collaborateurs peuvent se pencher sur des tâches à plus forte valeur ajoutée ;
  • aucun risque d'oubli puisque les humains n'ont plus à y songer ;
  • les statistiques calculées, qui collent parfaitement aux besoins métiers, permettent un pilotage plus précis de l'activité.

Voici l'une des meilleures définitions de l'informatique : le traitement de l'information, pour aider l'humain !

cCommunORM

cCommunORM est le nom d'une classe qui s'inscrit dans un ensemble de classes, qui forment un ORM.

Né en 2019 ce projet visait à compenser l'absence d'ORM dans le WLangage. Cela nécessitait de longs et fastidieux copier-coller dans des classes pour implémenter des méthodes de get, save, delete… et chaque modification devait être répercutée partout.

Cet ORM entièrement objet et faisant grand usage de l'héritage et du polymorphisme possède plusieurs fonctions :

  • il écrit tout seul ses requêtes en utilisant un formatage connu à l'avance du schéma de données (ce qui impose un schéma très propre, mais ce n'est pas l'objet de cette page 🙂). Depuis la version 28 de Windev, il utilise directement l'attribut <mapping> pour lier les attributs de classe à la rubrique en base de données ;
  • il est capable de faire ses JOIN sur les objets liés (ou pas, car c'est débrayable. Ceci est rendu possible par la classe cJoinClauseOrm, qui facilite l'adjonction des JOIN dans les classes de mapping), et également de requêter les tableaux d'objets liés (ou pas aussi, car c'est aussi débrayable) ;
  • il accepte des requêtes customisables, et fournit la classe cWhereClause, qui permet de décrire une clause Where sous forme d'objets. Plus besoin d'écrire soi-même la clause WHERE : utilisez des opérandes directement dans le code et construisez vos clauses, imbriquées ou pas. Cela permet notamment de pouvoir écrire une clause where en JSON et l'envoyer à cette classe qui saura la traduire en SQL.

Il fonctionne avec une classe encore plus ancienne (2015 !), cBDD, qui contient l'ensemble des méthodes nécessaires pour ouvrir une base de données, y faire automatiquement des mises à jour avant/après ouverture, des modifications de structure (pour les bases HFSQL uniquement), des créations de fichiers…

Ces classes me permettent d'être immédiatement opérationnel concernant la base de données, et de ne pas devoir recoder toute la plomberie à chaque fois. Ouvrir une base et s'en servir devient une formalité.

Note importante : cet ORM, comme beaucoup d'autres, travaille en RAM. Et donc, il est extrêmement pratique pour manipuler facilement des jeux de données réduits mais ne sera pas très utile pour des traitements de masse. Traitements qui peuvent de toute façon, souvent être dévolus à la base elle-même.

Le Bon Code

Le livre des best practices pour débuter en dev.

Noeli

À l'époque où je travaillais dans la facturation de transports médicaux, les professionnels de santé (PS) envoyaient par télétransmission leurs factures à la sécurité sociale. Afin de vérifier l'état de paiement des factures, ils obtenaient ensuite des retours dits NOEMIE.

Ces retours étaient des mails envoyés sur une boîte particulière fournie à la sécurité sociale, par le professionnel de santé. Ils contenaient des lignes de texte au format bien précis, qui est détaillé dans la norme NOEMIE.

Et donc, je m'étais lancé comme projet personnel de créer une application mobile sur iOS qui permettrait de récupérer ces retours Noemie.

S'en est suivi tout un travail de conception articulé autour de la norme NOEMIE que j'avais choisie d'implémenter — car il y en a plusieurs et elles ne sont pas destinées aux mêmes intervenants dans le domaine de la santé — la norme NOEMIE PS.

Cette norme contient des Références. Il s'agit pour faire simple d'un format possible d'un retour NOEMIE, et chaque référence peut inclure des infos que d'autres n'incluent pas. Noeli était une application permettant de récupérer les retours de plusieurs boîtes mail mais surtout, sa conception permettait d'accueillir dans un format unique un ensemble de références hétérogènes. Dit autrement, Noeli allait gommer toutes les différences existantes entre les références pour uniformiser leur représentation.

Un long travail d'analyse fut donc nécessaire. Oui, NOEMIE PS, c'est 130 pages.

L'application mobile Noeli fut donc codée sous Windev Mobile 21, et elle embarquait le cœur du système : un composant interne nommé ciRetourNoemie, codé en Windev 21.

Ce composant glouton, capable d'avaler n'importe quel retour NOEMIE de la norme PS, est capable de le restituer sous la forme d'un objet. Il travaille en mémoire exclusivement (même si ses résultats peuvent être stockés en base de données). Sa représentation unique d'un ensemble de références permet ensuite de les présenter simplement à l'écran.

Architecture et langage de développement

Noeli a été entièrement développée en WLangage. Elle se compose de 2 parties :

  • l'application mobile, développée avec Windev Mobile 21, et qui incorpore le moteur de réception des mails ainsi que toute la partie IHM ;
  • le moteur de traitement des retours, un composant interne développé avec Windev 21. C'est le cœur de Noeli !

Organisation du projet

Avant même de plancher sur l'application mobile, il a fallu développer le composant qui serait le cœur du système. Une analyse approfondie de la norme NOEMIE PS (et un profond manque de sommeil) m'ont permis de sortir la première version de ce composant en 2 semaines (analyse, développement, et tests inclus).

Par la suite, l'application mobile a été développée. Cette seconde pièce du puzzle devait fournir l'interface, ainsi que le moteur de connexion aux boîtes mail. Là encore, une phase d'analyse a été nécessaire, suivie d'une phase de développement et d'une phase de tests. S'ajoutent à ça les éléments de design et les opérations inhérentes à la publication sur l'App Store.

Au total, environ 4 mois de travail ont été nécessaires pour en arriver à la version 1.1.1 de Noeli.

Le composant

Noeli fait appel à un composant pour interpréter les retours Noemie.

Entièrement codé en objet, il permet d'interpréter un retour de façon précise. Si on lui donne le contenu d'un retour, il peut renvoyer des tableaux d'objets complets qui contiennent les informations qu'on pouvait voir sur Noeli (en fait, il en renvoyait bien plus, mais tout n'était pas visible depuis l'application). Il ne gère pas de base de données, et se contente simplement d'opérer en mémoire pour un maximum de rapidité. Sa seule fonction est de traiter un retour pour le restituer sous une forme beaucoup plus simple à exploiter.

Comme cité plus haut, une analyse approfondie de la norme NOEMIE PS a été nécessaire. Cette norme contient en effet plusieurs références. Chaque référence permet de présenter certaines données (toutes les références ne fournissent pas les mêmes informations), et sous une certaine forme. Le but du composant était donc de gommer, d'abstractiser ces différences, afin de fournir une présentation unique en dépit des différences existantes entre chaque référence.

L'app mobile

Une fois le composant prêt, restait à créer l'application qui allait l'utiliser. Par ailleurs, les retours NOEMIE sont des mails, il faut donc une interface permettant de paramétrer les boîtes mail, et un moteur pour récupérer les retours sur les boîtes. C'est l'application mobile qui remplissait ces fonctions.

Et bien plus…

J'ai arpenté bien d'autres horizons, et en ai encore beaucoup d'autres à explorer. Montage vidéo, management, formation, développement personnel…

Mon pseudo sur Developpez.com : kunnskap.

Ce que j'y raconte ? Quelques topics du forum où vous pourrez le découvrir :

Me contacter

contact@anthonylaurito.fr