betagouv/comobi-core

Comobi un service de covoiturage

Le projet Comobi est issu du projet Lot'ô car.

Historique Lot'ô car

Lot'ô car a commencé avec une base de données dans un Google Spreadsheet à plusieurs feuilles gérées manuellement//.

Cette gestion et le service par-dessus sont chronophages ; notamment trouver des correspondances entre les conducteur.rice.s et les demandes de trajet. C'est pour cette raison, que nous avons travaillé à d'abord à créer de petits outils indépendants qui permettent de libérer du temps à la personne qui fait ce travail manuellement.

Le volume de données était encore raisonnable pour que Google Spreadsheet soit utile, et avait été retenu pour être utilisé comme base de données principale. Toutefois, l'interface en tableau n'est pas le bon outil pour certaines tâches (notamment la correspondance conducteur.rice.s/trajets). Une interface a donc été développée.

David Bruant, dtc innovation, a été le développeur principal et référent technique du projet pour le moment

Corresplot

Corresplot est une interface utilisateur permettant de faire la correspondance facilement entre un.e conducteur.rice et une demande de trajet dans le Lot

Comobi

L'idée est de généraliser et de rendre plus générique le projet Lot'ô car afin qu'il puisse être déployé facilement et rapidement.

Organisation générale

Le repository github comobi-core contient ce qui est commun à toutes les instances (notamment le serveur qui discute avec la base de données)

Chaque instance est créé comme un repo github contenant uniquement les fichiers de contenu (textes, image, etc.) spécifiques à cette instance. Voir le repo betagouv/neutre.comobi.fr en exemple.

Chaque instance, au déploiement, tire la dernière version de la branche main de comobi-core et redéploie la combinaison de comobi-core et de ses propres fichiers

Actuellement, et pour des raisons historiques, les données sont stockées dans un Google Spreadsheet alimenté par les réponses à un Google Form. Nous planifions de transitionner vers une base de données MongoDB

Architecture

• Jekyll permet de gérer la partie statique de l'application web :
  • _includes: les éléments pouvants être partagés entre les pages
  • _layout: les templates des pages
  • _sass: les fichiers de styles
• Le framework Svelte est utilisé pour les composants d'interface (en particulier aujourd'hui le formulaire de recherche)
  • _scripts : le code côté client dont les composants d'interface
• Express est utilisé pour la partie serveur. Les fichiers sont séparés en différents sous dossiers et utilisés à la fois par l'application principale mais pouvant être utilisée par l'application 'outil-métier' (qui n'est pas encore utilisé dans le cadre de CoMobi)
  • server : fonctions en rapport avec les trajets et les lieux
  • spreadsheetDatabase : les fonctions permettant d'accèder aux données
  • server.js : instanciation d'une application express et gestion des routes
• les pages statiques en markdown:
  • index.md
  • recherche.md

Ajouter une nouvelle page

• ajouter une page .md_
• ajouter une route dans le fichier server.js

Base de connaissance de localisation

Parfois des communes sont fusionnées ou alors, les personnes habitant quelque part utilisent des noms pour les lieux qui ne sont pas les noms officiels (source gouvernementale) ou utilisés dans les API existantes. Ou alors, elles utilisent des noms raccourcis ambigus (dans le Lot, quand on parle de "Villeneuve", il est évident duquel on parle, alors qu'il existe plusieurs villes en France avec le nom "Villeneuve") Pour ces cas-là, nous mettons en place un Google Spreadsheet qui permet de consigner cette connaissance locale

Ce Google Spreadsheet contient 3 colonnes :

• noms
  • on peut rentrer plusieurs noms en les séparant par des virgules afin de leur assigner la même position
• latitude
• longitude

Pour trouver les latitude/longitude, une manière de faire consiste à aller dans Google Maps, viser le lieu que l'on souhaite, faire un clic droit, sélectionner "Plus d'infos sur cet endroit" et en bas de l'écran, on peut voir les latitude/longitude

Pour développer en local

Installer jekyll et ses pré-requis

En suivant la documentation jekyll

Installer nodejs

En suivant la documentation nodejs

Installer les dépendances

npm install
bundle install

Première fois

• Créer un fichier _config.yml (par exemple, en prenant ce modèle : https://github.com/betagouv/neutre.comobi.fr/blob/main/_config.yml )
• Créer un projet dans la console Google
• Créer une "clé API" (pas Oauth)
• Créer un fichier .env avec les variables d'environnement:
  • GOOGLE_API_KEY : clef d'API créée ci-dessus
  • GOOGLE_DRIVER_SPREADSHEET_ID : identifiant du Google Spreadsheet qui sert de base de donnée

Lancer

# Pour créer un premier build, avec notamment la création du dossier _site
npm run build:jekyll

Au quotidien

Pour lancer l'application "trajets direct" :

npm run dev # start server

Déploiement sur Clever Cloud

Lorsque la branche main est modifiée un build automatique est lancé via une github action comprenant les étapes suivantes :

• build du JS front-end
• build de l'application avec jekyll
• git push sur une branche nommée deploy Sur Clever Cloud un build automatique est lancé quand la branche deploy est mise à jour sur github

Langue

• Documentation en français
• Code et messages de commit en anglais

Licence

MIT

comobi-core's Issues

Choix du moyen de contact n'est pas précisé

Si on choisi téléphone ou SMS ce n'est pas précisé sur l'interface

un out of memory de npm start chez Clever Cloud pour tarn.comobi.fr

Sur ce commit : https://github.com/betagouv/tarn.comobi.fr/tree/7d93eb1d42f72b9a2e7a22adc3467c0f40c6385f

Il y a un trait blanc entre le header et le main

mettre une marge négative

A partir de la page de recherche on a pas le moyen de revenir à l'accueil

Mettre un lien dans le footer/header ?

quand on est en attente de résultats, "Aucun résultat" s'affiche et c'est sûrement faux

Changer le titre du bouton pour contacter le conducteur

remplacer "contacter direct" par "Contacter"

Dans main.js, importer georgraphy/positionByPlace

Ici :

https://github.com/betagouv/comobi/blob/667a606bc89dc90a445071472c0ea423f30d6e3c/_scripts/main.js#L19

pour profiter de la normalisation du nom (même si on en profite déjà via l'appel au serveur)

Des trajets "absurdes" s'affichent parfois

On pourrait éviter les trajets dont :

• la ville d'arrivée du passager est la ville de départ du conducteur
• le temps de trajet total est supérieur à 2x le trajet initial

Après une recherche la barre de boutons disparait

Dans le footer, l'adresse du site web de comobi est erronnée

Sur chaque instance, à la fin de la page d'acceuil, il y a le message "Vous souhaitez mettre en place du covoiturage sur votre territoire ?"

Mon intuition, c'est que ça n'a rien à faire là

Éventuellement, on pourrait faire une page "à propos" où ça parlerait

1. de l'instance et du territoire qu'elle couvre
2. de comobi/ANCT/comobi.fr

Question/Issue : phase de build

Avec la manière actuelle de faire, la phase de build crée un dossier _site contentant tout les dossiers à la racine du projet.
Hors, tous ces dossiers ne sont pas nécessaires.

Le moyen de contact préféré est affiché de manière moche

refaire un petit tour sur le style mobile

La logique de modale est un peu redondante

follow-up à #26

Actuellement, on créé une modale par TripProposal, alors qu'il ne devrait y en avoir qu'une pour toute la page

On pourrait créer la modale tout en haut et on remplirait la modale en fonction de ce qu'il y a dans le store

à quoi sert "bandeau" dans _config.yml

https://github.com/betagouv/tarn.comobi.fr/blob/8d3ccf46168abadc213bf6c78f7b853ea09b394b/_config.yml#L10-L12

Alors que le bandeau est déjà sur mail : https://github.com/betagouv/tarn.comobi.fr/blob/7d93eb1d42f72b9a2e7a22adc3467c0f40c6385f/index.md

Transitionner vers une base de données MongoDB

Dans la page "comment ça marche ?", ptèt faire 2 sections : conductrices et passagères

le bandeau se change dans l'index.md et pas dans la config

Dans le config de neutre on a l'impression qu'on change l'image du bandeau à cet endroit là.
Et en fait c'est dans index.md qu'on doit le changer !

A ajouter dans la doc...

La phrase "Un détour conséquent (entre 20 et 45 minutes) sera nécessaire pour vous récupérer " s'affiche même quand il n'y a pas de trajets de ce type

La page 404 est en anglais

Transformer CODE_DEPARTEMENT en configuration plutôt qu'en variable d'environnement

Ça n'a rien de secret ou de sensible

Et ça ouvre un peu des perspectives

Nettoyer la variable LOT_CODE

comobi-core/server.js

Line 32 in 48d2541

const LOT_CODE = process.env.CODE_DEPARTEMENT || '34'

Il s'agit d'un relicat historique qui créé plus de confusion qu'autre chose

Ptèt intégrer des types pour baredux

Un pti brouillon de type de la bibliothèque peuvent être trouvés ici : DavidBruant/baredux#2 (comment)

Si y'a une valeur à les finir et les distribuer avec la lib, je peux y travailler

Les positions des villes sont calculées au moment d'une recherche

On peut imaginer que la requête à /driver-trip-proposals pourrait retourner aussi les positions pour chaque origine et destination des propositions.
Ce qui implique aussi de revoir la fonction setAndPrepareForTripRequest(tripRequest) qui serait réduite à rechercher les positions des origine et destination d'une requête. Ces places pouvant aussi déjà être dans la liste positionByPlace.
On laissera la notion de status de la requête de côté dans un premier temps.

déplacer toutes les configs dans _config.yml

et donc supprimer le fichier .env et les variables d'environnement

Le footer n'est pas customisable

il faudrait pouvoir insérer des logos par exemple

La page 404 n'est pas en markdown