Anuncian la actualización de Weather.gov 2.0

 (github.com/weather-gov)
1 puntos por GN⁺ 2024-03-04 | 1 comentarios | Compartir por WhatsApp
  • El repositorio de Weathergov 2.0 es la segunda implementación después de la base de código anterior en Drupal, y es un proyecto creado para migrar a Wagtail/Django
  • Los desarrolladores pueden clonar el repositorio y configurar los contenedores con just zap, y luego revisar la aplicación, y el estado del proxy de API
  • El directorio de documentación incluye guías para product owners, desarrolladores, diseñadores, investigadores y otros, además de los registros de decisiones de arquitectura
  • El código asistido por IA puede aceptarse siempre que siga los criterios normales de código y revisión, pero quien lo envía debe ejecutar y probar el código personalmente y revelar en la solicitud de merge la información de procedencia, como nombre del modelo, versión y entorno
  • La base de código está dividida entre Wagtail CMS, subaplicaciones de Django, una capa y proxy de API en Node.js, código de infraestructura en Terraform y pruebas E2E con Playwright

Naturaleza de Weathergov 2.0

  • Este repositorio Git corresponde a la segunda iteración de Weathergov 2.0
  • El repositorio anterior contenía la base de código en Drupal, y este repositorio fue creado para la migración a Wagtail/Django

Cómo ejecutarlo localmente

  • Después de clonar el repositorio, puedes ejecutar just zap para configurar los contenedores
  • Una vez que los contenedores estén en ejecución, se puede revisar en las siguientes direcciones

Documentación y registros de decisiones

  • En docs/ hay guías para varios roles
    • Documentación para product owners
    • Documentación para desarrolladores
    • Documentación para diseñadores
    • Documentación para investigadores
    • Documentación para otros roles
  • En docs/architecture/decisions/ están los registros de decisiones de arquitectura, que explican la estructura actual y las razones detrás de esas decisiones

Política sobre código asistido por IA

  • El proyecto puede aceptar código asistido por IA de acuerdo con NAO 216-218 Artificial Intelligence in NOAA Policy, Executive Order 14179 "Removing Barriers to American Leadership in Artificial Intelligence", America's AI Action Plan
  • El código asistido por IA debe seguir los mismos criterios de revisión que el código normal, y se le aplican estándares de calidad aún más altos
  • Quien lo envía debe cumplir lo siguiente, igual que con código escrito por una persona
    • Haber ejecutado personalmente el código y las pruebas
    • Poder explicarle al equipo qué hace el código
    • Entender el problema que se busca resolver y la solución propuesta
  • La responsabilidad por el comportamiento, los bugs y los efectos secundarios del código enviado siempre recae en el contribuidor humano
  • Todas las solicitudes de merge deben revelar si incluyen código asistido por IA
    • Nombre y versión del modelo utilizado
    • IDE, Copilot u otros entornos relacionados
    • Cualquier otra información que ayude a entender la procedencia del código
  • La checklist exige marcar los cambios de código generados por IA, confirmar que se ejecutaron directamente y poder explicar los cambios, problemas y mejoras tanto a expertos como a no expertos

Estructura del código

  • api-interop-layer: aplicación Node ubicada entre el sitio y la API
  • api-proxy: herramienta de desarrollo y depuración que hace proxy de llamadas a la API e inserta datos estáticos
  • forecast/backend: Wagtail CMS que sirve las páginas de pronóstico
  • forecast/frontend: JavaScript y otros recursos del lado del cliente
  • forecast/locale: archivos de mensajes para generar traducciones
  • forecast/spatial: subaplicación de Django que gestiona la base de datos espacial
  • spatial-data: aplicación utilitaria en Node.js para generar mapas WFO
  • terraform: código para administrar la infraestructura y desplegar el sitio
  • tests/playwright: pruebas E2E con Playwright sobre el sitio en ejecución
  • tests/translations: script de pruebas que verifica la existencia de claves de traducción y está en estado deprecated
  • justfile: archivo para ejecutar comandos de desarrollador, con un rol parecido al de un makefile moderno

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-03-04
Opiniones de Hacker News

  • Parece que se está haciendo mediante un contrato/alianza con 18F (GSA): https://18f.gsa.gov/
    Me sorprende que en el README público hayan escrito que “weather.gov refleja más los silos de la organización que las necesidades de los usuarios (ley de Conway)”. Creo que en mi organización no tendríamos el valor de poner algo así en un documento público.

    • US Digital Service y 18F han desempeñado un papel importante al normalizar un ambiente en el que las agencias pueden decir: “sí, esto no está bien, pero vamos a mejorarlo”.
      Que las partes interesadas bajen la guardia y se sientan seguras para colaborar en una solución coherente es la mitad de la batalla; en este tipo de “hackeo de la burocracia”, se subestima la construcción de confianza y relaciones.
    • Ojalá más organizaciones fueran así de transparentes.
      Los silos van a aparecer de todos modos, y no quiero culpar a nadie. Saber que se reconoce el problema y que hay voluntad de resolverlo ayuda a soltar parte de la frustración.
    • Por la expresión “feedback/monitoreo”, me preocupa que vayan a meter scripts de tracking de analíticas con esos molestos pop-ups de cookies.
    • Todavía parece haber bastantes silos. Por ejemplo, la Office of Water Prediction mantiene una organización de GitHub aparte, y también existen los sitios preview.water.noaa.gov y water.noaa.gov/map, separados de water.weather.gov.
      Pero los datos de observación en campo en realidad vienen del USGS, y los datos y servicios web también se ofrecen desde waterdata.usgs.gov.

  • Quizá sea una pregunta tonta, pero me da curiosidad si este 2.0 ya se puede probar en algún lado, o si es solo código fuente en desarrollo.
    Hace unos 8 años, uno de los productos meteorológicos aeronáuticos del gobierno de EE. UU. tenía un sitio “experimental”, y era realmente bueno. Era moderno, fácil de usar y limpio; no parecía el típico sitio gubernamental torpe, y el equipo también parecía bueno, pero estaba atado al sistema de presupuestos gubernamentales de varios años. Al final lo cerraron y, si mal no recuerdo, ese trabajo nunca llegó al sitio principal.
    EE. UU. tiene suerte de contar con un gran servicio meteorológico y con la obligación de ofrecerlo como bien público y gratuito. Pero también hay mucha presión política para que no mejore demasiado, de modo que las empresas comerciales puedan obtener ganancias. Al menos en 2005, AccuWeather era una de esas empresas: https://www.onthecommons.org/privatizing-weather/index.html

    • Barry Myers / AccuWeather querría más que nadie la privatización de todos los servicios de pronóstico meteorológico, y si eso pasara, mis colegas del SPC y yo perderíamos nuestros empleos.
    • Parece que tienen preparado un entorno de staging, pero probablemente no esté público en producción: https://github.com/weather-gov/weather.gov/tree/main/.github...
    • Hay un sitio web beta en beta.weather.gov, aunque no sé si es el mismo que el código fuente enlazado en el artículo.
    • El README dice que terminaron la etapa de prototipado y que ahora están construyendo el MVP.
    • La hoja de ruta dice mayo.
      https://github.com/weather-gov/weather.gov/blob/smh--researc...

  • Van bien. radar.weather.gov es un sitio excelente, funciona en todos los dispositivos y anda muy bien sin anuncios, así que espero que lo sigan manteniendo.

    • Mi experiencia es exactamente la opuesta. En móvil no funciona nada bien, y para quien busca algo simple y útil como antes, es demasiado complejo.
      Además es extremadamente lento, y en comparación con la versión anterior ofrece información útil más limitada.

  • Me pregunto si esto también afectará a api.weather.gov. Hace tiempo hice un pequeño dashboard inspirado en Weather Underground (https://weather.nikolaj.dev) y todavía lo uso la mayoría de los días.
    Pero el trabajo de hacer mi propio pronóstico marítimo para reportes de surf está algo detenido. Ojalá terminen llenando esos campos. Eso me ahorraría el trabajo de descifrar los archivos GRIB por mi cuenta.

    • Me gusta esto. La UI/layout del pronóstico de 10 días de Weather Underground era la mejor, pero se llenó demasiado de anuncios.
    • Como referencia, al ver uno de los diagramas de arquitectura, parece que api.weather.gov está fuera del alcance de este proyecto.
    • Buena interfaz.
      Como detalle menor, ya había ingresado otra ubicación, pero unos segundos después me redirigió al clima de San Diego. Puede que haya sido porque bloqueé la solicitud de ubicación.

  • Sería bueno que todos los proyectos open source relacionados con el gobierno estuvieran organizados en un solo lugar. Por ejemplo, que hubiera una organización usa-gov en GitHub para poder acceder fácilmente a todos los repositorios.

    • No es exactamente un solo lugar, pero esta página [0] enumera organizaciones de GitHub de varias agencias federales. Aunque no es exhaustiva y, en particular, falta la organización de la NSA [1].
      [0] https://code.gov/agencies
      [1] https://github.com/nationalsecurityagency
    • En https://government.github.com/community/ también hay organizaciones internacionales.
    • GitHub no permite bien organizaciones anidadas ni estructuras de organizaciones relacionadas, así que meter todos los repositorios en una sola organización sería una pesadilla.
      Existe GitHub para el gobierno [0], pero depende de contribuciones y no está muy completo.
      La GSA inició code.gov durante la administración Obama con el objetivo de crear un índice único de todos los proyectos gubernamentales. Se fue apagando durante la administración Trump y, durante la administración Biden, en la práctica se le cortó el presupuesto, así que ahora apenas enlaza a las agencias principales y ya no existe el requisito de indexación oportuna.
      Solo nuestra organización tiene alrededor de 1000 repositorios, y hay cientos de agencias así, por lo que no me imagino reunirlos todos sin algo de esfuerzo. Originalmente, code.gov funcionaba bastante bien: cada quien publicaba un archivo code.json en su sitio web y la GSA los recopilaba y los combinaba en uno solo. Por eso es una verdadera lástima que hayan detenido eso y también dejaran de pedir la publicación de code.json. Era una buena idea.
      [0] https://government.github.com/community/
    • Francia tiene https://code.gouv.fr/, y el código fuente está publicado en GitHub y SourceHut: https://github.com/codegouvfr
      https://git.sr.ht/~codegouvfr/

  • Parece el futuro hacia el que podrían avanzar todas las agencias federales. Aplausos al National Weather Service por liderar el camino.

  • Los gráficos de pronóstico de weather.gov son de lo más útil que conozco y lo primero que busco cuando quiero saber el clima.
    Ej.: https://forecast.weather.gov/MapClick.php?lat=37.7771&lon=-1...

    • Exacto. Tengo configurado un atajo del gestor de ventanas que abre en mpv una imagen del clima por hora para mi ubicación, y lo recomiendo como una buena forma de revisar rápidamente el clima de hoy o mañana.
      También tengo un alias de shell que lo muestra en la terminal con kitten icat, pero uso más el atajo de mpv. También tengo un alias de clima en texto, que trae con curl el archivo correspondiente a mi ubicación desde esta ruta:
      https://tgftp.nws.noaa.gov/data/forecasts/zone/
      Revisé los archivos de mi estado para encontrar el adecuado, pero parece que el enlace “More Local Wx” de la página de pronóstico a 7 días también trae el nombre de archivo correcto. En mi caso es ORZ006.
      También tengo algunos alias de icat para mostrar el radar: vista actual, secuencial y en bucle. El nombre del radar lo tomo de la página siguiente, igual que en radar.weather.gov:
      https://radar.weather.gov/ridge/standard/
      Sin embargo, creo que la mejor vista es la de acumulación de una hora (One hour accumulation view), pero no he encontrado cómo obtener la imagen de esa vista, así que normalmente veo radar.weather.gov. Últimamente ha mejorado un poco, pero a veces no me funciona en absoluto.
      No los consulto con frecuencia, pero también tengo alias de icat para las perspectivas de temperatura y precipitación de 6 a 10 días y mensuales:
      https://www.cpc.ncep.noaa.gov/products/predictions/610day/
      https://www.cpc.ncep.noaa.gov/products/predictions/30day/

  • Veo un archivo contributing.MD, pero es difícil determinar cómo se puede contribuir realmente. Como potencial contribuyente, me gustaría saber cuál es la mejor forma de aportar.

    • perspective es “perspectiva”; aquí lo correcto es prospective, es decir, “potencial”.
      No lo digo por molestar, sino con ánimo de ayudar.

  • Esperaba que se hablara más de las API para quienes crean experiencias especializadas de forma directa. NOAA hace un buen trabajo ofreciendo datos en bruto, pero el consumo y aprovechamiento de servicios gubernamentales suele darse en casos mucho más específicos.
    Estoy creando herramientas de respuesta a emergencias en este espacio. Con IA generativa como enfoque principal: monitoreo continuo → alertas, chatbots, informes de situación personalizados y cosas por el estilo. Si te interesa, puedes contactarme.
    Como varias agencias, empresas de servicios públicos, etc., necesitan variantes especializadas, cada vez noto más que las dificultades de datos y UI de última milla que weather.gov probablemente está resolviendo internamente también serían útiles para otras organizaciones.
    Hasta donde sé, Weather.gov lo opera el NWS bajo NOAA, así que me parece interesante que eso no aparezca en esta renovación de misión.

  • Es algo un poco relacionado, pero personalmente esta es la URL individual más útil en weather.gov. Solo hay que cambiar la latitud/longitud
    https://forecast.weather.gov/MapClick.php?FcstType=graphical...
    Sería genial poder ver también datos históricos con el mismo diseño