S'étendre à d'autres villes que Brest

[philae-ael]

Reprise des message de #6
Benvi :

+1 et pourquoi pas en gros faudrait se baser sur "l'interface" de Adafruit_NeoPixel (qui n'est pas >énorme : https://github.com/jgarff/rpi_ws281x/blob/master/python/neopixel.py ).
Mais c'est à mon sens trop complexe pour le relier à des tests unitaires ... sauf si de l'autre coté tu
as aussi des jeux de données de test bibus en entrée :)
Donc se subtituer à l'API Bibus ce qui serait intéressant ça ouvrirait aussi la porte à d'autres API >(La Star à Rennes ...) ça nécessite de revoir le code et réfléchir à quelque chose d'ultra modulable >(regarder d'autres API).

Moi :

J'y avais pensé, mais j'avais pensé à juste créer un wrapper avec une api «de base» (d'après ce
que l'on utilise) qui sera redéfinie pour chaque api que l'on ajoute le problème c'est comment
passer d'une api à l'autre sans avoir à modifier le code (j'avais pensé à un __import__(api name)
mais je trouve ça moche)

Tristanplouz:

Pour développer le projet il faudrait qu'il soit construit en 3 partie:

• Une partie API avec la gestion des API de Bibus, de la STAR, de KSMA,etc
• Une partie qui traite les infos indépendantes des API et de l'affichage
• Une partie qui gère l'affichage sur les LEDs ou sur un écran

Avec cette structure je pense que le projet sera entièrement modulable et ensuite plus simple à modifier

[Benvii]

@naegi tu auras dans tous les cas besoin de faire un import :) après tu peux utiliser un patron de conception genre Adapter, tu as une implem pour chaque API qui est potentiellement complètement différente tu défini une interface et tu adapte chaque implem pour chaque API.

[philae-ael]

C'est ce à quoi je pensais en parlant de créer un wrapper autour des api (faut vraiment que j'apprenne le nom de patrons de conception)