Discussion :

[yanover]

Bonjour,

J'espère posté dans la bonne section, je vous remercie d'avance pour le temps et l'aide que vous pourrez m'apporter.

Il ma été demandé de développer une application de gestion des entrées pour la piscine de la petite ville ou je travail.
A l'heure actuelle, la solution implémentée est codée en vbs et s'appuie sur une base de donnée Access.

Le guichet dispose d'un tourniquet automatique et commandable à l'envoi d'un signal électrique, l'entrée est validé au scannage d'un code barre.

La solution actuellement implémentée est bancal et ne permet pas d'ouvrir le tourniquet (il est toujours ouvert), c'est pourquoi il ma été demandé de trouver une solution.

Maintenant, je vous explique les fonctionnalités à implémentées :

Scénario - nouvelle entrée

- Paul, qui vient pour la première fois à la piscine, demande une entrée simple.
- Un ticket est imprimé, ses informations sont automatiquement ajoutées dans la base.
- Paul scanne son ticket.
- Dans le système, le code-barre est identifié comme répertorié, l'entrée est validé.
- Le tourniquet est ouvert par le système.

Scénario - Entrée avec abonnement

- Martine, qui est une nageuse aguerrie, dispose d'un abonnement annuelle.
- Elle scanne sa carte.
- Dans le système, le code barre est identifié comme répertoriée, le contrôle de validité de son abonnement est effectuée.
- Si l'abonnement est valide, le tourniquet s'ouvre.

Fonctionnalité de l'application

- Un bouton pour Imprimer un ticket, ça concernera les entrées uniques
- Un bouton pour créer un abonnement, avec des champs servant à identifier la personne. (nom, prenom, age etc..)
- Un espace de visualisation des abonnements actif, inactif etc ..
- Lorsque une personne scanne un ticket, un retour doit être fait sur l'application.
- Si c'est un abonnement, les infos de la personne + la validité de l'abonnement sont affichés.
- Si c'est une entrée unique, juste les champs générés automatiquement à la création du ticket sont affichés.
- Evidemment si l'entrée n'est pas validé, un retour est fait et le tourniquet reste bloqué.


Voilà, en gros les fonctionnalités de cette application.

Il faut donc pouvoir commander depuis l'application un tourniquet (envoyer une impulsion électrique), une imprimante à carte, éventuellement une caisse.

Techniquement

Etant encore en étude, je n'ai pas vraiment de langage de prédilection, ça explique aussi ma venu ici.

Au début, je pensais développé une application web :
- Php
- Html
- Css (bootstrap ou materialize)
- Jquery
- Mysql

Mais je ne suis pas sur que ça soit adapté, surtout pour les interactions avec les éléments externe (tourniquet, caisse, etc..).

J'ai également de bonne base en java et suis évidement ouvert à toutes propositions .. (python, C#, etc..).

Quelles sont donc vos recommandations ?

Encore merci pour l'aide que vous pourrez m’apporter.

Yanøver

[mister3957]

J'ai bien aimé la rédaction des scénarios

D'après ce que j'ai compris, il y a :
- Un besoin applicatif basique
- De l’interaction avec du matériel
- Une base de données

Soumis aux contraintes :
- Pas vraiment de contraintes de performances
- Pas vraiment de contraintes de déploiement
- Pas vraiment de contraintes réseau
- Pas vraiment de contraintes de volumétrie

J'ai quelques questions :
- Est-ce que plusieurs personnes en même temps utiliseront cette application ? (donc déploiement sur plusieurs postes)
- Faut-il respecter un OS particulier ?
- Comment s'utilisent l'imprimante et le tourniquet ? (ce que fournissent les constructeurs pour les manipuler)

[yanover]

Salut Mister !

Merci d'avoir pris le temps de me lire

Je vais essayer de répondre au mieux à tes questions.

- Est-ce que plusieurs personnes en même temps utiliseront cette application ? (donc déploiement sur plusieurs postes)

A priori non, il n'y a qu'une seule caisse, avec un seul ordinateur.

- Faut-il respecter un OS particulier ?

Les actions avec le soft seront effectué sur un client Windows 7 ou 10 (imposé).
Après rien ne m'empêche de faire un serveur pour l'application. (Linux ou Windows) ..

- Comment s'utilisent l'imprimante et le tourniquet ? (ce que fournissent les constructeurs pour les manipuler)

Comment ça s'utilise je ne sais pas encore, je n'ai pour l'instant aucune documentation à ce sujet.

Par contre j'ai la liste détaillées des éléments :

• Portique d'entrée de type Tripod KABA kerberos tpb e02
• Lecteur code-barres
• Module Velleman VM8090 (gestion des contacteurs du tripod)
• Caisse enregistreuse
• Tiroir-caisse
• PC's avec écrans
• Imprimantes à cartes plastique --> FARGO® DTC1250e

Je sais qu'à l'envoi d'un signal au module Velleman, le tourniquet s'ouvre ou se bloque.
Le module et l'imprimante possèdent un port usb.

La caisse n'est pour l'instant relié physiquement à aucun périphérique. Mais à mon avis elle sera prise en considération dans l'application dans un deuxième temps.

Encore merci pour votre aide.

Excellente soirée

[yanover]

Personne ne peut me conseiller ?

[mister3957]

Il faut savoir comment contrôler ces périphériques.

Pour le Velleman, il est indiqué "Téléchargez une DLL pour la création d'un propre logiciel sur notre site web", c'est fort bizarre qu'un constructeur indique ça "télécharger une DLL". Souvent les constructeurs parlent de SDK pour x et/ou y techno, mais "tiens voilà une DLL" c'est un peut flou, il va falloir faire des recherches.

Pour l’imprimante, je n'ai pas trouvé comment la piloter de manière informatique. Ils parlent d'un logiciel "Swift ID" mais pas de SDK. Après je n'ai pas cherché pendant 10.000 ans.

Enfin, ça imprime des cartes et ça lit des cartes. Il faut chercher s'il n'y a pas une norme, une structure à respecter des informations que l'on met dans ces cartes ou si c'est full libre. Ayant travaillé dans la billettique, je sais que le poid des informations est très important, où par exemple on utilise un octet pour faire 8 booléens, où on définit des dates 0 plus récente que l'epoch time pour que ça tienne sur moins de bits.

Donc, entre ces pilotages de machines et le stockage de données sur carte, il faudra probablement s'en remettre à du C / C++, mais pas pour l'ensemble puisque l'application, l'utilisation de la base peut et doit être fait en techno de plus haut niveau.

Je pencherais alors pour du NodeJS qui peut facilement faire le lien entre bas niveau (C / C++) / haut niveau (API Rest) et avec la techno de ton choix pour l'exploiter. Et quitte à prendre ça, autant continuer sur la même stack pour la consommer, donc du web, ou alors du client lourd comme Java / C#. Là dessus je la jouerais Web pour ne pas se fermer aux futurs évolutions.

[yanover]

Salut Mister,

Encore merci du temps que tu investis dans mon futur projet

Il faut savoir comment contrôler ces périphériques.
Pour le Velleman, il est indiqué "Téléchargez une DLL pour la création d'un propre logiciel sur notre site web", c'est fort bizarre qu'un constructeur indique ça "télécharger une DLL". Souvent les constructeurs parlent de SDK pour x et/ou y techno, mais "tiens voilà une DLL" c'est un peut flou, il va falloir faire des recherches.

Ouais j'ai déjà cherché dans ce sens aussi, sur leur fiche informatif c'est effectivement ce qui est indiqué.

La personne actuellement responsable du soft en production ma confié avoir essayé d'utiliser cette .dll, visiblement c'est pas vraiment difficile à utiliser. Envoyer le signal au Velleman ne lui a pas posé de problèmes. Par contre ça n'a pas été implémenté, pourquoi je ne sais pas.

Pour l’imprimante, je n'ai pas trouvé comment la piloter de manière informatique. Ils parlent d'un logiciel "Swift ID" mais pas de SDK. Après je n'ai pas cherché pendant 10.000 ans.

Actuellement, le serveur qui contient la base de donnée et l'application vbs est directement sur place. Les employés de la piscine travail directement sur cette machine. L'imprimante est raccordé physiquement à cette machine.

Apparemment c'est pas un soucis de communiquer avec l’imprimante via le port USB.

Enfin, ça imprime des cartes et ça lit des cartes. Il faut chercher s'il n'y a pas une norme, une structure à respecter des informations que l'on met dans ces cartes ou si c'est full libre. Ayant travaillé dans la billettique, je sais que le poid des informations est très important, où par exemple on utilise un octet pour faire 8 booléens, où on définit des dates 0 plus récente que l'epoch time pour que ça tienne sur moins de bits.

Cette problématique a déjà été étudié. Le système mis en place génère déjà un code barre respectant une convention préalablement établie. Je reprendrais donc le même modèle.

Donc, entre ces pilotages de machines et le stockage de données sur carte, il faudra probablement s'en remettre à du C / C++, mais pas pour l'ensemble puisque l'application, l'utilisation de la base peut et doit être fait en techno de plus haut niveau.

Je pencherais alors pour du NodeJS qui peut facilement faire le lien entre bas niveau (C / C++) / haut niveau (API Rest) et avec la techno de ton choix pour l'exploiter. Et quitte à prendre ça, autant continuer sur la même stack pour la consommer, donc du web, ou alors du client lourd comme Java / C#. Là dessus je la jouerais Web pour ne pas se fermer aux futurs évolutions.

Je prends en considération toutes ces recommandations. Le problème, c'est le temps.
Je n'ai jamais fait de C++, et encore moins de C. Apprendre un langage de (bas niveau) m'intéresse au plus haut point mais, je n'aurai pas forcément le temps d'apprendre toutes ces nouvelles technologies et en plus implémenter la totalité du projet...

Dans le cas ou d'après toi c'est indispensable de passer par un langage du genre, comment et ou pourrai-je me documenter ? J'ai franchement aucune idée par ou commencer ..

Ouais pour l'interface je part sur du web, avec des techno standard (php, MySQL).

Je donne une idée mais si part exemple je branche le Welleman sur un Raspberry Pi, avec un script python ou même .sh il est peut être facile de dialoguer avec le module et d'ensuite exécuter ces scripts depuis le serveur web (exec(...); shell_exec(...)

Merci d'avance et merci encore !!

Yanøver

[mister3957]

Si tu as le travail à exécuter dans le exec(...) ou shell_exec(...), c'est déjà une épine de moins à prendre en compte