Annonce de la mise à jour de Weather.gov 2.0

 (github.com/weather-gov)
1 points par GN⁺ 2024-03-04 | 1 commentaires | Partager sur WhatsApp
  • Le dépôt Weathergov 2.0 correspond à la deuxième implémentation après l’ancienne base de code Drupal, et a été créé pour la migration vers Wagtail/Django
  • Les développeurs peuvent cloner le dépôt puis configurer les conteneurs avec just zap, et vérifier ensuite l’ application ainsi que l’état du proxy API
  • Le répertoire de documentation contient des guides pour les product owners, développeurs, designers, chercheurs, etc., ainsi que des journaux de décisions d’architecture
  • Le code assisté par l’IA peut être accepté s’il respecte les critères habituels de code et de revue, mais l’auteur doit exécuter lui-même le code et les tests, et divulguer dans la merge request les informations de provenance comme le nom du modèle, sa version et l’environnement
  • La base de code est structurée autour de Wagtail CMS, de sous-applications Django, d’une couche et d’un proxy API en Node.js, de code d’infrastructure Terraform, de tests E2E Playwright, etc.

Nature de Weathergov 2.0

  • Ce dépôt Git correspond à la deuxième itération de Weathergov 2.0
  • Le dépôt précédent contenait la base de code Drupal, et celui-ci a été créé pour la migration vers Wagtail/Django

Exécution en local

  • Après avoir cloné le dépôt, il est possible de configurer les conteneurs en exécutant just zap
  • Une fois les conteneurs lancés, le service est accessible aux adresses suivantes

Documentation et historique des décisions

  • Sous docs/, on trouve des guides pour différents rôles
    • documentation pour les product owners
    • documentation pour les développeurs
    • documentation pour les designers
    • documentation pour les chercheurs
    • documentation pour d’autres rôles
  • docs/architecture/decisions/ contient les journaux de décisions d’architecture, qui expliquent la structure actuelle et les raisons des choix effectués

Politique sur le code assisté par l’IA

  • Le projet peut accepter du code assisté par l’IA conformément à NAO 216-218 Artificial Intelligence in NOAA Policy, Executive Order 14179 "Removing Barriers to American Leadership in Artificial Intelligence", America's AI Action Plan
  • Le code assisté par l’IA doit respecter les mêmes critères que le code classique et les mêmes standards de revue, avec des exigences de qualité encore plus élevées
  • Comme pour du code écrit par une personne, le contributeur doit notamment
    • avoir exécuté lui-même le code et les tests
    • être capable d’expliquer à l’équipe ce que fait le code
    • comprendre le problème visé et la solution proposée
  • La responsabilité du comportement du code soumis, de ses bugs et de ses effets de bord incombe toujours au contributeur humain
  • Toute merge request doit indiquer si elle inclut du code assisté par l’IA
    • nom et version du modèle utilisé
    • environnement concerné, comme l’IDE, Copilot, etc.
    • toute autre information utile pour comprendre la provenance du code
  • La checklist exige de signaler les modifications de code généré par l’IA, de confirmer qu’elles ont été exécutées directement, et de pouvoir expliquer les changements, les problèmes et les améliorations aussi bien à des experts qu’à des non-spécialistes

Structure du code

  • api-interop-layer : application Node située entre le site et l’API
  • api-proxy : outil de développement et de débogage qui proxy les appels API et injecte des données statiques
  • forecast/backend : Wagtail CMS qui fournit les pages de prévisions
  • forecast/frontend : JavaScript et autres ressources côté client
  • forecast/locale : fichiers de messages pour la génération des traductions
  • forecast/spatial : sous-application Django qui gère la base de données spatiale
  • spatial-data : application utilitaire Node.js qui génère les cartes WFO
  • terraform : code pour la gestion de l’infrastructure et le déploiement du site
  • tests/playwright : tests E2E Playwright sur le site en cours d’exécution
  • tests/translations : script de test vérifiant l’existence des clés de traduction, désormais deprecated
  • justfile : fichier qui exécute les commandes développeur, jouant un rôle proche d’un makefile moderne

À lire aussi

1 commentaires

 
GN⁺ 2024-03-04
Avis sur Hacker News

  • Cela semble se faire dans le cadre d’un contrat/partenariat avec 18F (GSA) : https://18f.gsa.gov/
    C’est surprenant de lire dans le README public que « weather.gov reflète davantage les silos de l’organisation que les besoins des utilisateurs (loi de Conway) ». Dans mon organisation, on n’aurait probablement pas le cran d’écrire ça dans un document public.

    • L’US Digital Service et 18F ont joué un rôle important en normalisant, au sein des agences, l’idée de pouvoir dire : « oui, ce n’est pas terrible, mais nous allons l’améliorer ».
      Le sentiment de sécurité qui permet aux parties prenantes de baisser la garde et de collaborer à une solution cohérente représente la moitié du combat ; dans ce genre de « hack de la bureaucratie », la confiance et la construction de relations sont sous-estimées.
    • J’aimerais que davantage d’organisations soient aussi transparentes.
      Les silos finissent toujours par apparaître, et je n’ai pas envie d’en attribuer la faute à quelqu’un. Savoir que le problème est reconnu et qu’il existe une volonté de le résoudre permet déjà de relâcher une partie de la frustration.
    • L’expression « feedback/monitoring » me fait craindre qu’ils n’ajoutent des scripts de suivi analytique accompagnés de pénibles pop-ups de cookies.
    • On dirait qu’il reste encore pas mal de silos. Par exemple, l’Office of Water Prediction gère une organisation GitHub séparée, ainsi que les sites preview.water.noaa.gov et water.noaa.gov/map, distincts de water.weather.gov.
      Pourtant, les données d’observation terrain viennent en réalité de l’USGS, et les données comme les services web sont fournis par waterdata.usgs.gov.

  • C’est peut-être une question idiote, mais je me demande si cette 2.0 est déjà utilisable quelque part, ou s’il s’agit seulement de code source en cours de développement.
    Il y a environ 8 ans, l’un des produits météo aéronautiques du gouvernement américain avait un site « expérimental », et il était vraiment très bon. Moderne, facile à utiliser, propre, il ne ressemblait pas à ces sites gouvernementaux souvent maladroits, et l’équipe semblait bonne, mais elle était coincée dans un système budgétaire public pluriannuel. Au final, le site a fermé, et de mémoire le travail n’a jamais été intégré au site principal.
    Les États-Unis ont la chance de disposer d’excellents services météo et d’une obligation de les fournir gratuitement comme un bien public. Mais il existe aussi beaucoup de pressions politiques pour éviter que ces services ne deviennent trop bons, afin que des entreprises commerciales puissent faire du profit. AccuWeather en faisait au moins partie en 2005 : https://www.onthecommons.org/privatizing-weather/index.html

    • Barry Myers / AccuWeather voudrait plus que quiconque la privatisation de tous les services de prévision météo, et si cela arrivait, mes collègues du SPC et moi perdrions notre emploi.
    • Ils semblent avoir mis en place un environnement de staging, mais il n’est probablement pas public en production : https://github.com/weather-gov/weather.gov/tree/main/.github...
    • Il existe bien un site bêta sur beta.weather.gov, mais je ne sais pas si c’est le même que le code source lié dans l’article.
    • Le README indique qu’ils ont terminé le prototypage et qu’ils construisent maintenant le MVP.
    • La roadmap indique mai.
      https://github.com/weather-gov/weather.gov/blob/smh--researc...

  • Beau travail. radar.weather.gov est un excellent site, il fonctionne sur tous les appareils, marche très bien sans publicité, donc j’espère qu’ils continueront à le maintenir.

    • Mon expérience est exactement inverse. Sur mobile, il ne fonctionne pas bien du tout, et il est beaucoup trop complexe pour quelqu’un qui cherche quelque chose de simple et utile comme avant.
      Il est aussi extrêmement lent, et les informations utiles sont plus limitées que dans la version précédente.

  • Je me demande si cela aura aussi un impact sur api.weather.gov. J’avais créé un petit tableau de bord inspiré de Weather Underground (https://weather.nikolaj.dev) que j’utilise encore la plupart du temps.
    En revanche, mon travail pour créer directement des prévisions marines destinées aux rapports de surf est un peu à l’arrêt. J’espère qu’ils finiront par renseigner ces champs. Cela m’éviterait d’avoir à comprendre moi-même les fichiers GRIB.

    • J’aime bien. L’interface/la mise en page des prévisions à 10 jours de Weather Underground était la meilleure, mais les publicités sont devenues vraiment envahissantes.
    • À titre de référence, d’après l’un des diagrammes d’architecture, api.weather.gov semble être hors périmètre de ce projet.
    • Bonne interface.
      Petit problème : j’avais déjà saisi un autre emplacement, mais quelques secondes plus tard j’ai été redirigé vers la météo de San Diego. C’est peut-être parce que j’ai bloqué la demande de localisation.

  • Ce serait bien que tous les projets open source liés au gouvernement soient regroupés au même endroit. Par exemple, qu’il existe une organisation usa-gov sur GitHub permettant d’accéder facilement à tous les dépôts

    • Ce n’est pas exactement un endroit unique, mais cette page [0] liste les organisations GitHub de plusieurs agences fédérales. Elle n’est toutefois pas exhaustive, et il manque notamment l’organisation de la NSA [1]
      [0] https://code.gov/agencies
      [1] https://github.com/nationalsecurityagency
    • Il y a aussi des organisations internationales sur https://government.github.com/community/
    • GitHub ne permet pas vraiment les organisations imbriquées ni les structures d’organisations associées, donc mettre tous les dépôts dans une seule organisation deviendrait un cauchemar
      Il existe bien GitHub pour les gouvernements [0], mais il dépend des contributions et n’est pas très complet
      La GSA a lancé code.gov sous l’administration Obama avec l’objectif de créer un index unique de tous les projets gouvernementaux. Le projet s’est essoufflé sous l’administration Trump et, sous l’administration Biden, son budget a quasiment été coupé ; aujourd’hui, il se contente surtout de pointer vers les grandes agences, et l’exigence d’un index à jour n’existe plus vraiment
      Rien que notre organisation compte environ 1 000 dépôts, et il y a des centaines d’agences de ce type, donc je n’imagine pas pouvoir tout rassembler sans un minimum d’effort. À l’origine, code.gov fonctionnait plutôt bien : chacun publiait un fichier code.json sur son site, puis la GSA les collectait et les fusionnait. C’est donc vraiment dommage d’avoir arrêté cela, ainsi que les demandes de publication de code.json. C’était une bonne idée
      [0] https://government.github.com/community/
    • En France, il y a https://code.gouv.fr/, et le code source est publié sur GitHub et SourceHut : https://github.com/codegouvfr
      https://git.sr.ht/~codegouvfr/

  • Cela ressemble à l’avenir vers lequel toutes les agences fédérales pourraient aller. Bravo au National Weather Service de montrer la voie

  • Le graphique de prévision de weather.gov est l’un des outils les plus utiles que je connaisse, et c’est la première chose que je consulte quand je veux connaître la météo
    Exemple : https://forecast.weather.gov/MapClick.php?lat=37.7771&lon=-1...

    • Exact. J’ai créé un raccourci de gestionnaire de fenêtres qui affiche dans mpv l’image de la météo horaire pour ma position, et je le recommande comme bon moyen de vérifier rapidement la météo d’aujourd’hui ou de demain
      J’ai aussi un alias shell qui l’affiche dans le terminal avec kitten icat, mais j’utilise plus souvent le raccourci mpv. J’ai également un alias météo en texte, qui récupère avec curl le fichier correspondant à ma position dans le chemin suivant :
      https://tgftp.nws.noaa.gov/data/forecasts/zone/
      J’ai parcouru les fichiers de mon État pour trouver le bon, mais le lien “More Local Wx” de la page des prévisions à 7 jours semble aussi contenir le nom de fichier correct. Dans mon cas, c’est ORZ006
      J’ai aussi créé quelques alias icat pour afficher le radar : vue actuelle, séquentielle et en boucle. Les noms des radars sont les mêmes que sur radar.weather.gov et proviennent de la page suivante :
      https://radar.weather.gov/ridge/standard/
      Cela dit, je trouve que la vue des précipitations cumulées sur 1 heure (One hour accumulation view) est la meilleure, mais je n’ai pas trouvé comment récupérer les images de cette vue, donc je vais généralement sur radar.weather.gov. C’est un peu mieux ces temps-ci, mais parfois ça ne fonctionne pas du tout chez moi
      Je ne les consulte pas souvent, mais j’ai aussi créé des alias icat pour afficher les prévisions de température et de précipitations à 6–10 jours et mensuelles :
      https://www.cpc.ncep.noaa.gov/products/predictions/610day/
      https://www.cpc.ncep.noaa.gov/products/predictions/30day/

  • Je vois un fichier contributing.MD, mais il est difficile de savoir concrètement comment contribuer. En tant que contributeur potentiel, j’aimerais savoir quelle serait la meilleure manière d’aider

    • perspective signifie « point de vue » ; ici, il faut dire prospective, c’est-à-dire « potentiel »
      Ce n’est pas pour chipoter, je partage ça en espérant que ce soit utile

  • J’espérais voir davantage de discussions sur les API pour les personnes qui créent des expériences spécialisées. La NOAA fournit bien les données brutes, mais la consommation et l’utilisation des services gouvernementaux relèvent souvent de cas beaucoup plus précis
    Je développe ici des outils d’intervention d’urgence. Ils sont d’abord pensés pour l’IA générative : surveillance continue → alertes, chatbots, rapports de situation personnalisés, ce genre de choses. Si cela vous intéresse, n’hésitez pas à me contacter
    Comme de nombreuses agences, utilities, etc. ont besoin de variantes spécialisées, cela me fait d’autant plus prendre conscience que les difficultés de données et d’UI de dernier kilomètre que weather.gov est probablement en train de résoudre en interne pourraient aussi aider d’autres agences
    À ma connaissance, Weather.gov est exploité par le NWS au sein de la NOAA, donc il est intéressant que cela ne figure pas dans cette refonte de mission

  • C’est un peu lié, mais personnellement, l’URL unique la plus utile sur weather.gov est celle-ci. Il suffit de changer la latitude/longitude
    https://forecast.weather.gov/MapClick.php?FcstType=graphical...
    Ce serait bien de pouvoir aussi consulter les données historiques avec la même mise en page