Quand j’ai compris comment GTFS Schedule et GTFS Realtime pouvaient fonctionner ensemble, j’ai vu une matrice de questions utiles sur le transport collectif montréalais. GTFS Schedule fournissait le volet planifié : les lignes, les trajets, les arrêts et les horaires. GTFS Realtime pouvait ajouter les mises à jour des trajets en temps réel, la position des véhicules, la valeur numérique du retard et des renseignements facultatifs sur l’occupation. Une seule date, une plage de dates ou une période plus longue ajoutait une autre dimension. transit.yesid.dev est né en partie du fait que je voyais comment ces dimensions pouvaient se croiser, plutôt que de traiter chaque flux ou chaque mesure comme un fait séparé.
Placez une ligne sur un axe et le temps sur l’autre, puis demandez-vous où le service planifié et les observations en temps réel divergent. Quelles lignes sont en retard durant la période choisie? Le motif change-t-il lorsque la plage de dates change? À quel endroit l’information disponible sur l’occupation montre-t-elle un motif différent à une certaine heure? Quels trajets d’autobus planifiés devraient être en service maintenant, mais n’ont aucun véhicule en temps réel correspondant? Chaque question vient d’un croisement différent entre le service planifié, l’information en temps réel, une interprétation du produit et un contrôle temporel. La matrice transforme une liste de champs en quelque chose que je peux examiner.
Ces questions exigent que les couches de la source et du produit restent distinctes. Le retard est une valeur numérique, tandis que les catégories en avance, à l’heure, en retard et retard important sont des interprétations créées par le produit. Les données d’occupation sont facultatives et expérimentales : elles peuvent donc être absentes ou incomplètes, et rien ne garantit qu’elles forment une échelle linéaire. Le statut de non-transmission est distinct : c’est un signal dérivé par le produit pour un trajet d’autobus planifié qui devrait être en service maintenant, mais auquel aucun véhicule en temps réel ne correspond. Ce n’est pas une valeur temporelle officielle du standard GTFS.
Je vois une vraie matrice. Je vois des lignes et des colonnes. C’est visuel. La granularité peut faire partie de l’image : un élément, un groupe ou un niveau plus large. Les filtres et les options qu’ils laissent peuvent en former une autre partie. Les décisions, les champs de base de données et les combinaisons occupent le même genre d’espace visuel. Le contenu change selon le sujet, mais les lignes et les colonnes restent visibles pour moi.
Pour une décision, je peux imaginer les options comme des lignes et les contraintes comme des colonnes. Un filtre réduit les options; un autre ajoute une condition. Je peux voir quelles combinaisons restent. Les entrées exactes dépendent de la décision, mais je continue de voir les relations comme une grille.
SQL correspond à cette image. Dans une table, chaque ligne est un enregistrement et chaque colonne est un champ. Les filtres choisissent les enregistrements à afficher, et une requête peut combiner plusieurs conditions. Les relations me permettent de passer d’un enregistrement aux enregistrements associés lorsqu’une seule table ne suffit pas à expliquer la situation. La granularité change aussi l’image : un seul enregistrement, un résultat groupé et un ensemble plus large répondent à des questions différentes. SQL donne des noms et des opérations précis aux lignes, aux colonnes, aux filtres, aux champs de base de données et aux combinaisons que je vois.
La comptabilité et SQL se rejoignent dans ma tête. Avant de travailler comme développeur SQL, j’ai étudié la comptabilité. Quand un montant était incertain, une date et un montant constituaient un point de départ. C’étaient des indices, pas des clés dont l’unicité était garantie, puisqu’un autre enregistrement pouvait partager ces deux valeurs. Le contexte pouvait se trouver dans les flux de trésorerie, un budget, un état financier ou une transaction. Parfois, la date pouvait orienter vers le bon compte; parfois, le montant ne faisait que réduire le champ de recherche. Je pouvais parcourir ces enregistrements et demander où le montant apparaissait, à quoi il était relié et si un autre enregistrement l’expliquait mieux. Les JOINs et la normalisation m’ont ensuite donné des outils et un vocabulaire plus précis pour suivre les relations dans les données. Ce qui les relie pour moi, c’est le fait de remonter une piste : la première valeur pointe quelque part, les enregistrements associés réduisent l’incertitude et la réponse complète dépend du contexte.
Je me souviens d’une femme qui, quand je travaillais à la plonge, m’a dit : « Tu as deux mains. Sers-toi des deux. »
J’ai gardé cette consigne. Je remarque encore quand une main est libre et pourrait déjà aider. Une main peut poursuivre un geste pendant que l’autre commence le suivant. Les deux mains peuvent aller dans des directions différentes et s’occuper de tâches différentes. Cette habitude ne s’est pas arrêtée à la plonge; je l’ai gardée dans d’autres emplois physiques. Quand je travaille ou fais quelque chose de physique, je cherche cette possibilité au lieu d’attendre qu’un geste soit terminé. Cela fait gagner du temps, et je me surprends encore à appliquer cette habitude. Le changement est physique et précis : remarquer la main libre, lui confier une partie du travail et laisser les deux gestes avancer ensemble.
Les données fonctionnent parce que les champs ont des définitions. Un retard peut être enregistré sous forme de nombre, une plage de dates a des limites, et un produit peut regrouper des observations dans des catégories déclarées. Les gens ne sont pas des paramètres rigides de la même façon. Vous pouvez recueillir les mesures les plus importantes sans jamais mesurer pleinement une personne. Une note, une catégorie ou une observation peut décrire quelque chose de réel, mais ne peut appuyer qu’une affirmation limitée.
L’habitude des deux mains rend la différence claire. Je peux décrire ce qui a changé : les deux mains travaillent, les actions avancent dans des directions différentes et du temps est économisé. Ces mesures peuvent décrire l’habitude, mais elles ne peuvent contenir la personne qui me l’a enseignée.
C’est aussi ainsi que je travaille avec l’IA : elle peut transformer une conversation en structure, mais je lis chaque bloc du début à la fin et je prends la décision finale.
Voici le chapitre 3 d’une épopée en six chapitres. Chapitres 1 à 3 : qui je suis. Chapitres 4 à 6 : ce que je construis. Précédent : Comment j’apprends : graviter autour d’un système jusqu’au déclic · Suivant : Accéléré par l’IA, piloté par l’humain : mon vrai flux de travail.
Besoin d’un système qui reste éditable?