Weather.gov 2.0: Update angekündigt

 (github.com/weather-gov)
1 Punkte von GN⁺ 2024-03-04 | 1 Kommentare | Auf WhatsApp teilen
  • Das Repository Weathergov 2.0 ist die zweite Implementierung nach der früheren Drupal-Codebasis und wurde für die Migration zu Wagtail/Django erstellt
  • Entwickler können nach dem Klonen des Repositorys mit just zap die Container einrichten und anschließend die App sowie den API-Proxy-Status prüfen
  • Das Dokumentationsverzeichnis enthält Leitfäden für Product Owner, Entwickler, Designer, Forschende und andere Rollen sowie Architecture Decision Records
  • KI-unterstützter Code kann nach denselben Code- und Review-Standards wie regulärer Code angenommen werden; Einreichende müssen Codeausführung und Tests jedoch selbst durchführen und Informationen zur Herkunft wie Modellname, Version und Umgebung im Merge Request offenlegen
  • Die Codebasis ist unter anderem in Wagtail CMS, Django-Unteranwendungen, eine Node.js-API-Schicht und Proxys, Terraform-Infrastrukturcode sowie Playwright-E2E-Tests gegliedert

Charakter von Weathergov 2.0

  • Dieses Git-Repository entspricht der zweiten Iteration von Weathergov 2.0
  • Das frühere Repository enthielt die Drupal-Codebasis; dieses Repository wurde für die Migration zu Wagtail/Django erstellt

Lokale Ausführung

  • Nach dem Klonen des Repositorys können mit just zap die Container eingerichtet werden
  • Sobald die Container laufen, ist Folgendes unter diesen Adressen erreichbar

Dokumentation und Entscheidungsprotokolle

  • Unter docs/ gibt es Leitfäden für verschiedene Rollen
    • Dokumentation für Product Owner
    • Dokumentation für Entwickler
    • Dokumentation für Designer
    • Dokumentation für Forschende
    • Dokumentation für weitere Rollen
  • Unter docs/architecture/decisions/ befinden sich Architecture Decision Records, die die aktuelle Struktur und die Gründe für Entscheidungen erläutern

Richtlinie zu KI-unterstütztem Code

  • Das Projekt kann im Einklang mit der NAO 216-218 Artificial Intelligence in NOAA Policy, der Executive Order 14179 „Removing Barriers to American Leadership in Artificial Intelligence“ und America's AI Action Plan KI-unterstützten Code annehmen
  • KI-unterstützter Code muss denselben Code- und Review-Standards wie regulärer Code entsprechen; es gelten höhere Qualitätsanforderungen
  • Einreichende müssen wie bei von Menschen geschriebenem Code Folgendes erfüllen
    • Sie müssen Code und Tests selbst ausgeführt haben
    • Sie müssen dem Team erklären können, was der Code tut
    • Sie müssen das zu lösende Problem und die vorgeschlagene Lösung verstehen
  • Die Verantwortung für Verhalten, Fehler und Nebenwirkungen des eingereichten Codes liegt immer bei den menschlichen Beitragenden
  • Alle Merge Requests müssen offenlegen, ob sie KI-unterstützten Code enthalten
    • Name und Version des verwendeten Modells
    • Relevante Umgebung wie IDE, Copilot usw.
    • Weitere Informationen, die helfen, die Herkunft des Codes zu verstehen
  • Die Checkliste verlangt, Änderungen durch KI-generierten Code zu kennzeichnen, sie selbst ausgeführt zu haben und sowohl Fachleuten als auch Nichtfachleuten die Änderungen, Probleme und Verbesserungen erklären zu können

Code-Struktur

  • api-interop-layer: Node-App, die zwischen Website und API liegt
  • api-proxy: Entwicklungs- und Debugging-Tool, das API-Aufrufe proxyt und statische Daten einfügt
  • forecast/backend: Wagtail CMS, das die Vorhersageseiten bereitstellt
  • forecast/frontend: JavaScript und weitere clientseitige Assets
  • forecast/locale: Message-Dateien zur Erstellung von Übersetzungen
  • forecast/spatial: Django-Unteranwendung zur Verwaltung räumlicher Datenbanken
  • spatial-data: Node.js-Utility-App zur Erstellung von WFO-Karten
  • terraform: Code für Infrastrukturverwaltung und Site-Deployment
  • tests/playwright: Playwright-E2E-Tests für die laufende Website
  • tests/translations: Testskript zur Prüfung, ob Übersetzungsschlüssel vorhanden sind; als deprecated markiert
  • justfile: Datei zum Ausführen von Entwicklerbefehlen, mit einer Rolle ähnlich einem modernen makefile

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-04
Hacker-News-Meinungen

  • Es scheint über einen Vertrag/eine Partnerschaft mit 18F (GSA) zu laufen: https://18f.gsa.gov/
    Erstaunlich, dass im öffentlichen README steht, „weather.gov spiegelt eher die Silos der Organisation wider als die Bedürfnisse der Nutzer“ (Conways Gesetz). In meiner Organisation hätten wir wohl nicht den Mut, so etwas in ein öffentliches Dokument zu schreiben.

    • US Digital Service und 18F haben viel dazu beigetragen, eine Atmosphäre zu normalisieren, in der Behörden sagen können: „Ja, das ist nicht gut, aber wir werden es besser machen.“
      Die halbe Miete ist ein Gefühl von Sicherheit, in dem Stakeholder ihre Abwehrhaltung aufgeben und an einer konsistenten Lösung zusammenarbeiten können; bei solchem „Bürokratie-Hacking“ werden Vertrauen und Beziehungsaufbau unterschätzt.
    • Ich wünschte, mehr Organisationen wären so transparent.
      Silos entstehen nun einmal, und ich möchte niemandem die Schuld geben. Wenn man weiß, dass das Problem anerkannt wird und der Wille zur Lösung da ist, kann man einen Teil der Frustration loslassen.
    • Wegen der Formulierung „Feedback/Monitoring“ mache ich mir Sorgen, dass sie ein Analyse-Tracking-Skript einbauen, das mit einem nervigen Cookie-Popup daherkommt.
    • Es scheint weiterhin ziemlich viele Silos zu geben. Zum Beispiel betreibt das Office of Water Prediction eine eigene GitHub-Organisation, und neben water.weather.gov gibt es auch die separaten Sites preview.water.noaa.gov und water.noaa.gov/map.
      Die Beobachtungsdaten vor Ort kommen tatsächlich aber vom USGS, und auch Daten sowie Webservices werden über waterdata.usgs.gov bereitgestellt.

  • Vielleicht ist das eine dumme Frage, aber ich frage mich, ob diese 2.0 irgendwo tatsächlich ausprobierbar ist oder ob es nur Quellcode in Entwicklung ist.
    Vor etwa 8 Jahren gab es für eines der US-Regierungsprodukte zur Luftfahrtmeteorologie eine „experimentelle“ Site, und die war wirklich gut. Modern, einfach zu bedienen und aufgeräumt, nicht wie die üblichen unbeholfenen Regierungswebsites; auch das Team wirkte gut, war aber an den mehrjährigen Haushaltszyklus der Regierung gebunden. Am Ende wurde sie geschlossen, und soweit ich mich erinnere, ist die Arbeit nie auf die Hauptsite gekommen.
    Die USA haben Glück, weil sie einen hervorragenden Wetterdienst und die Verpflichtung haben, ihn kostenlos als öffentliches Gut bereitzustellen. Allerdings gibt es auch viel politischen Druck, der verhindert, dass er zu gut wird, damit kommerzielle Firmen Gewinn machen können. Zumindest 2005 war AccuWeather eine dieser Firmen: https://www.onthecommons.org/privatizing-weather/index.html

    • Barry Myers / AccuWeather würde die Privatisierung aller Wettervorhersagedienste wohl mehr als jeder andere wollen, und dann würden ich und meine Kollegen beim SPC unsere Jobs verlieren.
    • Eine Staging-Umgebung scheinen sie zu haben, aber öffentlich live ist sie vermutlich nicht: https://github.com/weather-gov/weather.gov/tree/main/.github...
    • Unter beta.weather.gov gibt es zwar eine Beta-Website, aber ich weiß nicht, ob das dieselbe ist wie der im Artikel verlinkte Source.
    • Im README steht, dass sie das Prototyping abgeschlossen haben und jetzt ein MVP bauen.
    • In der Roadmap steht Mai.
      https://github.com/weather-gov/weather.gov/blob/smh--researc...

  • Sie machen das gut. radar.weather.gov ist eine hervorragende Site, funktioniert auf allen Geräten und läuft ohne Werbung sehr gut; ich hoffe, sie behalten sie weiter bei.

    • Meine Erfahrung ist genau das Gegenteil. Auf Mobilgeräten funktioniert sie überhaupt nicht gut, und für Leute, die etwas so Einfaches und Nützliches wie früher suchen, ist sie viel zu kompliziert.
      Außerdem ist sie extrem langsam, und im Vergleich zur vorherigen Version sind auch die nützlichen Informationen stärker eingeschränkt.

  • Ich frage mich, ob das auch api.weather.gov betrifft. Ich habe früher ein kleines, von Weather Underground inspiriertes Dashboard (https://weather.nikolaj.dev) gebaut und nutze es an den meisten Tagen immer noch.
    Allerdings steckt meine Arbeit daran, selbst Meeresvorhersagen für Surfberichte zu erstellen, etwas fest. Ich hoffe, sie füllen diese Felder irgendwann aus. Dann müsste ich mich nicht selbst durch GRIB-Dateien arbeiten.

    • Das gefällt mir. Die UI/das Layout der 10-Tage-Vorhersage von Weather Underground war am besten, aber die Werbung ist zu schlimm geworden.
    • Zur Info: Wenn man sich eines der Architekturdiagramme ansieht, scheint api.weather.gov außerhalb des Umfangs dieses Projekts zu liegen.
    • Die Oberfläche ist gut.
      Kleines Problem: Ich hatte bereits einen anderen Standort eingegeben, wurde aber ein paar Sekunden später zum Wetter für San Diego weitergeleitet. Vielleicht lag es daran, dass ich die Standortanfrage blockiert hatte.

  • Es wäre gut, wenn alle Open-Source-Projekte der Regierung an einem Ort gebündelt wären. Zum Beispiel wäre es praktisch, wenn es auf GitHub eine usa-gov-Organisation gäbe, über die man leicht auf alle Repositories zugreifen könnte.

    • Nicht ganz an einem Ort, aber diese Seite [0] listet die GitHub-Organisationen mehrerer Bundesbehörden auf. Sie ist allerdings nicht vollständig; insbesondere fehlt die NSA-Organisation [1].
      [0] https://code.gov/agencies
      [1] https://github.com/nationalsecurityagency
    • Unter https://government.github.com/community/ gibt es auch internationale Organisationen.
    • GitHub erlaubt verschachtelte Organisationen oder Strukturen für verwandte Organisationen nicht wirklich, daher wäre es ein Albtraum, alle Repositories in eine einzige Organisation zu packen.
      GitHub für Regierungen [0] gibt es zwar, aber es hängt von Beiträgen ab und ist nicht besonders vollständig.
      Die GSA startete code.gov während der Obama-Regierung mit dem Ziel, einen zentralen Index aller Regierungsprojekte zu schaffen. Unter der Trump-Regierung schlief das ein, und unter der Biden-Regierung wurde das Budget praktisch gestrichen; heute verlinkt es im Wesentlichen nur noch auf große Behörden, und die Anforderung eines aktuellen Index gibt es nicht mehr.
      Allein unsere Organisation hat rund 1000 Repositories, und es gibt Hunderte solcher Behörden; ohne einen gewissen Aufwand ist kaum vorstellbar, das alles zusammenzutragen. Ursprünglich funktionierte code.gov ziemlich gut: Jede Stelle stellte auf ihrer Website eine code.json-Datei bereit, und die GSA sammelte diese ein und führte sie zusammen. Deshalb ist es wirklich schade, dass man damit aufgehört und auch die Bitte eingestellt hat, code.json zu veröffentlichen. Das war eine gute Idee.
      [0] https://government.github.com/community/
    • In Frankreich gibt es https://code.gouv.fr/, und der Quellcode ist auf GitHub und SourceHut öffentlich: https://github.com/codegouvfr
      https://git.sr.ht/~codegouvfr/

  • Das wirkt wie die Zukunft, in die sich alle Bundesbehörden entwickeln könnten. Applaus dafür, dass der National Weather Service hier vorangeht.

  • Die Vorhersagegrafik von weather.gov ist eine der nützlichsten, die ich kenne, und das Erste, wonach ich schaue, wenn ich das Wetter wissen will.
    Beispiel: https://forecast.weather.gov/MapClick.php?lat=37.7771&lon=-1...

    • Stimmt. Ich habe mir ein Window-Manager-Shortcut gebaut, das das stündliche Wetterbild für meinen Standort mit mpv öffnet; ich empfehle das als gute Möglichkeit, schnell das Wetter für heute oder morgen zu prüfen.
      Ich habe auch ein Shell-Alias, das es im Terminal mit kitten icat anzeigt, aber das mpv-Shortcut nutze ich häufiger. Außerdem habe ich ein Alias für die Textwettervorhersage, das per curl die zu meinem Standort passende Datei aus folgendem Pfad holt:
      https://tgftp.nws.noaa.gov/data/forecasts/zone/
      Ich habe die Dateien für meinen Bundesstaat durchgesehen und die passende gefunden, aber der Link „More Local Wx“ auf der 7-Tage-Vorhersageseite scheint ebenfalls den richtigen Dateinamen zu enthalten. In meinem Fall ist es ORZ006.
      Ich habe auch ein paar icat-Aliasse eingerichtet, die Radar anzeigen: aktuell, sequenziell und in Schleife. Die Radarnamen sind dieselben wie auf radar.weather.gov und stammen von dieser Seite:
      https://radar.weather.gov/ridge/standard/
      Allerdings finde ich die Ansicht für die einstündige Niederschlagsakkumulation am besten, und ich habe nicht herausgefunden, wie man das Bild für diese Ansicht abruft; deshalb schaue ich meist auf radar.weather.gov. In letzter Zeit ist es etwas besser geworden, aber manchmal funktioniert es bei mir überhaupt nicht.
      Ich schaue nicht oft hinein, habe aber auch icat-Aliasse für die 6- bis 10-Tage- sowie Monatsausblicke für Temperatur und Niederschlag angelegt:
      https://www.cpc.ncep.noaa.gov/products/predictions/610day/
      https://www.cpc.ncep.noaa.gov/products/predictions/30day/

  • Ich sehe eine contributing.MD-Datei, aber es ist schwer einzuschätzen, wie man tatsächlich beitragen kann. Als potenzieller Mitwirkender wäre es gut zu wissen, auf welche Weise man am besten beitragen sollte.

    • perspective bedeutet „Perspektive“; hier wäre prospective, also „potenziell“, richtig.
      Ich will nicht kleinlich sein, sondern hoffe, dass es hilfreich ist.

  • Ich hatte gehofft, mehr über eine API für Leute zu hören, die direkt spezialisierte Erlebnisse bauen. NOAA ist gut darin, Rohdaten bereitzustellen, aber die Nutzung und Weiterverarbeitung staatlicher Dienste ist oft deutlich konkreter.
    Ich baue hier ein Tool für Notfallmaßnahmen. Es ist Generative-AI-first, mit Dingen wie kontinuierlichem Monitoring → Benachrichtigungen, Chatbots und maßgeschneiderten Lageberichten. Wer Interesse hat, kann sich gern melden.
    Weil viele Behörden, Versorger usw. spezialisierte Varianten benötigen, wird mir immer klarer, dass die Daten- und UI-Probleme auf der letzten Meile, die weather.gov intern lösen dürfte, auch anderen Behörden helfen würden.
    Soweit ich weiß, wird Weather.gov vom NWS unter NOAA betrieben; daher ist es interessant, dass das in dieser Neuausrichtung der Mission nicht vorkommt.

  • Das ist nur am Rande verwandt, aber persönlich ist dies für mich die nützlichste einzelne URL auf weather.gov. Man muss nur Breiten- und Längengrad ändern
    https://forecast.weather.gov/MapClick.php?FcstType=graphical...
    Es wäre schön, wenn man im gleichen Layout auch Vergangenheitsdaten sehen könnte