Lors de l’atelier Atelier foire au Raspberry Pi, un participant avait une démonstration d’un programme permettant d’afficher des vidéos et des photos sur un écran distant (ici une télévision au fond de la salle). Ne trouvant plus le nom de l’application, je me suis dit, pourquoi pas essayer de faire la même chose?

Je suis parti sur l’idée suivante:

  • Il faut un appareil physique à brancher sur une télévision/projecteur.
  • Il faut que la communication soit local et hors ligne.
  • Il faut qu’à la fin de l’événement, en éteignant l’appareil, tout est soit supprimé, soit sauvegarder et disponible physiquement pour récupération (toujours hors ligne).
  • L’utilisation doit être le plus simple possible.
  • Que n’importe qui avec un ordiphone peut ajouter des photos et/ou des vidéos.
  • L’installation doit être la plus simple possible.
  • Que du logiciel libre.
  • Ça juste marche.

Coté fun, j’ai voulu m’obliger à utiliser des outils que je n’utilise jamais ou très (trop?) peu. Je me suis ajouté les challenges suivant:

  • Résumé le projet correctement en y utilisant des méthodes/outils de Gestion de projet.
  • Utiliser du Python
  • Utiliser Chatgpt et Claude.ia pour la génération de la documentation.
  • Utiliser Chatgpt et Claude.ia pour la partie affichage utilisateur.
  • Utiliser du matériel que j’ai à ma disposition.
  • Concept du “Good enough” OBLIGATOIRE (je me trouve trop perfectionniste, je travaille la dessus).

C’est parti!

Introduction

Il faut voir cet article comme un récit chronologique du projet.

Je prépare mon projet

Mind mapping et brainstorming

Une feuille, un bic, c’est tout ce qu’il faut pour faire une carte heuristique (mindmap).

Je note note tout ce qui me passe par la tête pour le projet. Après un certain temps, je résume mes idées dans une seul carte mentale, que je fais sur mon ordinateur (avec le logiciel Minder). Ce qui me donne une idée assez précise de ce que je veux faire.

Alt text
Carte mentale du projet

Mon projet

Je veux un système clé en main, simple, qui me créer un réseau local dédié et qui permet à des utilisateurs de partager des médias sur un écran commun sans devoir expliquer son utilisation.

J’analyse, je cherche et je teste

Avec l’aide de la carte carte heuristique et de la définition de mon projet, je peux, sans me perdre dans les détails, commencer à décortiquer le projet en plus petites actions. De ces actions, je peux en sortir de plus petites tâches.

Certaines actions me demande de faire des recherches:

  • Quelles librairies en Python?
  • Je crée un programme moi même pour l’affichage? Il n’y a pas déjà quelque chose?

De ces actions et de ces tâches, je peux facilement créer un tableau des tâches de type Kanban

Tableau Kanban

Pour me faciliter la tâche et ne pas trop encombrer mon espace, j’utilise l’application Kanboard. Merci à Frédéric Guillot et à sa communauté pour le travail!

Alt text
Vue de mon tableau Kanboard. Il y a quelques ticket de visible.

À la fin d’un premier tour d’ajout, je vois déjà plus clair sur ce que je vais utiliser, le temps que cela me prendra et les technologies à utiliser.

Les technologies que j’utilise

Matériels

  • Raspberry Pi 3 modèle B ( matériel dont je n’avait plus d’utilité).
  • Ma télévision.
  • Mon ordinateur.

Application externe

Je ne veux pas ré-inventer la roue. J’ai recherché des applications qui me permettent de faire mon projet.

Je trouve plusieurs applications faisant une partie du travail.

Pas totalement.

Pas libre.

Je continue mes recherches. Je tombe un peu par hasard sur la partie libre et gratuite de Screenly:

Anthias:

Après quelques testes de charge avec la Pi (qui est vielle et pas très puissante), je trouve l’application parfaite pour ce que je veux faire. Seul bémol, les grosses latences lors de la compression de vidéo (tout, même l’affichage est figé).

Langages utilisés

Je pars sur du Python et du Bash.

Le Python me servira pour la partie site internet et appelle à l’API de Anthias.

Je cherche un peu une librairie qui me permettrait de faire des requêtes à l’API d’Anthias et je tombe sur Flask. Il s’agit d’une application qui fait l’interface entre une application web et un serveur. Ce qui est parfait pour faire communiquer mon site web utilisateur avec l’API de Anthias! Et la documentation est bien faite.

Le Bash me permettra d’automatiser les installations et les configurations des dépendances à Anthias et à mon application Python. Je le maîtrise assez bien et il me sera utile pour avoir un environment propre pour travailler sur l’application.

Système d’exploitation et applications système

Vu que je vais travailler avec une vieille Raspberry Pi, je préfère utiliser le système d’exploitation le plus léger possible.

Anthias a un Operating System (Système d’exploitation) tout fait pour ma machine! Il est même disponible directement sur le Raspberry Pi Imager ou, si on veut la dernière version Dernière version!

De plus, je peux faire la même chose manuellement, en me basant sur ce tutorial.

Ma partie préférée, le développement de l’application!

J’ai regroupé tout ce qu’il me faut pour commencer à faire mon projet.

Mes tickets sont prêts, j’en ai même ajoutés au vu de que j’ai lu dans la documentation de Flask et de Anthias.

Il s’agit de la partie la plus longue à faire. C’est aussi la partie que je préfère. Un problème, une solution, un code. Les heures passent et mon prototype d’application prend vie.

Malheureusement, c’est aussi la partie la moins intéressante tous le monde, sauf les développeur. Je ferai un autre article plus technique dans la partie tuto!

Pour simplifier:

je lis un ticket, j’effectue ce qui à écrit dessus, je le teste , je le documente et je ferme le ticket.

Et je recommence!

A la fin de cette partie, j’ai une application fonctionnelle et qui respecte ce que je me suis défini au début.

S’il y a un comportement que je n’aime pas ou que je ne trouve pas pratique, je fais un ticket pour me rappeler plus tard sur quoi travailler.

L’utilisation de l’application

Je laisse quelques jours passer pour ne plus avoir la tête dans l’application. Cela me permet de tester la facilité de l’application. J’essaie de l’utiliser sans regarder la documentation.

C’est OK, j’y arrive! J’avance sur la dernière étape!

Vérifier la documentation pour l’utilisation

J’ai une application qui fonctionne bien. J’ai un boîtier avec tous les cables qui vont bien. Il ne reste plus qu’à proposer son utilisation en test réel!

Mais avant cela, il faut être sûr que la documentation est suffisante pour que tout le monde puisse l’utiliser.

Je dois encore finaliser cette partie

  • Je compte faire un dessin expliquant comment connecter l’appareil à une télévision
  • Expliquer comment envoyer un média.
  • Comment éteindre l’appareil
  • Expliquer la partie administration (un peu plus technique)

Tester l’application

  • Un bon premier test utilisateur est de les laisser utiliser le boîtier sans regarder la documentation.

Résultat: C’est mitigé: Une fois expliquer quel qr-code permet de se connecter et arriver au site, c’est parti! Il faudrait sûrement que je fais une image beaucoup plus claire.

  • En réalisant le test, j’ai remarqué quelques comportements non pratique:
    • Si l’image avec les deux qr-code de connexion n’est pas la seule présente, elle change après 20 secondes. Ce n’est pas pratique pour montrer aux utilisateurs que faire.
  • Les GIF fonctionnent (chose positive)
  • Je n’ai pas encore de page d’administration, ce qui est problématique pour faire une archive des photos. Je suis obliger de me connecter en ssh et le faire manuellement.

Clôture du projet

Il ne me reste plus qu’à vérifier que mon code est bien versionné et documenté.

Que ma documentation utilisateur et développeur soient suffisantes et correctes.

Et je peux clôturer ce projet!

Conclusion et fin de développement de l’application

Un petit projet qui m’a permis de refaire de la gestion de projet de A à Z.

J’ai pu réutiliser des outils que je n’avais plus utilisé depuis longtemps. Généralement, je faisais vite une carte mentale de mes projets personnels sans continuer avec un gestionnaire de ticket (Kanboard). Cela m’a fait du bien de couper le développement en plusieurs parties. On voit directement qu’on avance! Le nombre de ticket diminue, les différentes parties du projet commencent à communiquer entre elles!

Je n’ai pas trop succombé au perfectionnisme! Les scripts d’installation et d’administration peuvent être améliorés. Le site internet des utilisateurs peut être plus fonctionnel. Mais je vais laisser le projet tel quel pour l’instant.

L’utilisation du Python était sympa. Je reste quand même sur ma préférence pour des langages statiques (les types sont vérifiés à la compilation) et fortement typés (les erreurs de typages sont détectés à la compilation/exécution et la conversion entre type incompatible n’est possible que via cast/conversion explicite).

La partie HTML/CSS est en grande partie générée par Claude.ia. Je ne voulais pas passer énormément de temps dessus et éviter au maximum mon perfectionnisme (un changement de couleur, une typographie plus visible, etc).

Pour terminer, je relis ce que j’avais comme projet:

Je veux un système clé en main, simple, qui me créer un réseau local dédié et qui permet à des utilisateurs de partager des médias sur un écran commun sans devoir expliquer son utilisation.

et je me rend compte que c’est exactement ce que fait mon petit boîtier.