Suivi de Fabrication en Perl

Au siècle dernier, un de mes collègues avait mis au point un suivi de fabrication simplifié lié à la gestion
commerciale.

Cela a permis d'effectuer un suivi de la fabrication presque en temps réel. Les délais de fabrication étant fixés par contrat
les clients de mon client pouvaient savoir ou en était leur commande juste avec un coup de fil (internet n'était encore
très utilisé) les données remontaient chaque fois que quelqu'un bipait sur un dossier.

Basé sur des terminaux séries avec 2 lignes de 16 caracteres il fallait trouver un dialogue simple avec les utilisateurs
Je ne sais plus qui a eu l'idée du code-barre mais cela simplifiait énormément la chose.

Il fallait 2 choses : le dossier de fabrication qui avait un code barre et une feuille A4 par utilisateur ou se trouvait
codifié le code de l'utilisateur, l'opération et sont status (début, fin, arrêt etc .. )

En 2 bips les informations remontaientt des postes de fabrications.

En 2005 l'outil arrivait au bout de sa course, à cause du coût de chaque poste la liaison série imposait des vitesses réduites
et des câbles spécifiques.

Il fallait évoluer.

Il existait des solutions basé sur Windows NT (le unix killer de l'époque :) ) et des terminaux symbol mais tout cela était
disproportionné par rapport au besoin de base et au budget.

J'avais découvert le langage perl quelque années auparavant et je m'amusais avec les exemples du célèbre livre "Perl CookBook" de chez
O'Reilly ( Perl en Action en Français ).
Dedans se trouvait un exemple d'un serveur TCP simpliste.
Après quelques tests pour étudier la faisabilité, je proposais une évolution pour le suivi de fabrication.

La base du dialogue n'avait pas à être changé, les liaisons séries devaient être remplacé par du réseau TCP/IP
Les terminaux séries pouvaient être remplacés par des terminaux VT sans soucis, un cable en 'Y' permettait de gérer le clavier et
le lecteur code barre tout cela pour beaucoup moins cher, sans licence et quasiment sans limite.

L'échange avec la gestion se fait par un table commune entre les 2 bases, constamment synchronisée par un processus dédié
entre la base Mysql du code Barre et la base Oracle de l'ERP.

Il fallait que cela soit asycnhrone car nous avions vécu la pénibilité d'avoir a gérer des arrêts du code barre, à chaque fois que la gestion devait s'arrêter
alors que le coté production n'était pas concerné.

Avec ce processus de synchro et sa propre base le code barre est un outil indépendant de l'ERP.

L'utilisation d'écran standard a permis d'afficher beaucoup d'informations dont les opérations en cours et a venir, permettant ainsi
a certain poste d'optimise leur travail

Développé en 2005 ce petit exemple issue du Perl CookBook a été modifié plusieurs fois, mais depuis il continue a fonctionné
de manière autonome même au moment au j'écrit ces lignes en 2019

Un projet de remplacement est en à l'étude, mais si c'est moi qui doit le faire cela sera en python.

J'ai beaucoup aimé codé en perl. Mais à l'usage c'est un langage difficile à lire et relire quand on ne le pratique pas tout les jours.
Et la moindre modifs de ce scripts d'environ 3000 lignes me prend 3 jours dont 1 journée pour relire et me remettre dedans.

D'un autre coté c'est gràce a la concision et la simplicité de Perl, ainsi que la manière très particulière qu'a Larry Wall le créateur de ce langage
de voir les choses, que j'ai compris la différence entre une variable et un objet (au sens informatique du terme).
En perl un objet est un variable "Bénie" (la commande est bless $variable) qui devient unique dans le traitement.
Vous pouvez réfléchir sur le sens profond de ceci.