Closed patoscope closed 5 months ago
Est-ce qu'on voudrait pas être en PROD par défaut? i.e. les Flavie de ce monde seront sur la version de la plateforme où les données peuvent être exploitées sans se poser de questions. Donc les creds pour AWS_ACCESS_KEY_ID
et AWS_SECRET_ACCESS_KEY
seraient les valeurs de PROD.
Pour les intrépides, il serait possible de passer des clés de DEV à aws_connect()
pour beta-tester les pipelines en développement.
Ce que ça donne: pas de 'choix' ou de barrière pour juste exploiter les données normalement, mais aller jouer en dev doit être un acte intentionnel.
Est-ce qu'on voudrait pas être en PROD par défaut? i.e. les Flavie de ce monde seront sur la version de la plateforme où les données peuvent être exploitées sans se poser de questions. Donc les creds pour
AWS_ACCESS_KEY_ID
etAWS_SECRET_ACCESS_KEY
seraient les valeurs de PROD.Pour les intrépides, il serait possible de passer des clés de DEV à
aws_connect()
pour beta-tester les pipelines en développement.Ce que ça donne: pas de 'choix' ou de barrière pour juste exploiter les données normalement, mais aller jouer en dev doit être un acte intentionnel.
@huguesmp j'y ai bien pensé et j'anticipais ton point, je reste ouvert à ça.
Mon intention reste toutefois d'impliquer tout le monde dans le cycle de développement de pipeline de données, jusqu'au raffineurs. La notion de DEV et PROD est importante selon moi pour tout le monde et fait partie de la littéracie de développement et de données aussi. A tort ou à raison ma croyance, c'est que la notion de DEV et PROD doit faire partie de la culture numérique. Un peu comme avec les ERP comme SAP pour les UAT.
C'est aussi important que tous les chercheurs s'impliquent et se sentent concernés dans la compréhension/analyse de leurs sources de données pour un projet de recherche. À terme je pense qu'il est bénéfique pour eux de faire partie du cycle de développement d'un pipeline utile à leur recherche dès le début au moment où on décide des source de données à considérer.
C'est vrai que tous les chercheurs n'auront pas à s'impliquer à ce niveau systématiquement, mais tôt ou tard ça peut arriver à tout le monde: il faut à mon avis développer leur réflexe de ne pas juste se contenter des données qu'on collecte aujourd'hui mais de proposer la collecte de données supplémentaires et de contribuer à enrichir la plateforme: ça fait partie des formations à leur donner comme celle de vendredi 17 mai.
Ma crainte c'était que si on met PROD par défaut, j'ai peur que les intrépides fassent des bêtises en PROD sans en être conscient. Mais si on le rend explicite, ça peut éveiller des chercheurs à contribuer au développement de la plateforme de données.
Je verrais bien qu'on passe un paramètre du genre "env" à aws_session() et/ou ellipse_connect()
On peut en parler.
Ah ok oui, je comprends ton intention. Je suis conscient que je suis un peu prévisible sur ces questions, je suis ultra sensible au UX 🥲
Ça dépend à quel point la plateforme de données doit être transparente aux étudiants en SSN qui l'utilisent. Une question de vision et d'orientation de l'enseignement à laquelle je n'ai pas la réponse, mais une discussion intéressante à avoir (rapidement!) avec les parties prenantes parce qu'elle aura une influence sur plusieurs décisions de design qui vont se poser.
Ah ok oui, je comprends ton intention. Je suis conscient que je suis un peu prévisible sur ces questions, je suis ultra sensible au UX 🥲
Ça dépend à quel point la plateforme de données doit être transparente aux étudiants en SSN qui l'utilisent. Une question de vision et d'orientation de l'enseignement à laquelle je n'ai pas la réponse, mais une discussion intéressante à avoir (rapidement!) avec les parties prenantes parce qu'elle aura une influence sur plusieurs décisions de design qui vont se poser.
Je rencontre Yannick vendredi, j'aurai cette discussion avec lui pour obtenir son orientation par rapport à ça.
Fournir des instructions aux chercheurs pour passer d'un environnement à l'autre (PROD ou DEV)
Passer d'un environnement à l'autre doit être un acte intentionnel et explicite pour éviter les erreurs