Anunciada a atualização do Weather.gov 2.0

 (github.com/weather-gov)
1 pontos por GN⁺ 2024-03-04 | 1 comentários | Compartilhar no WhatsApp
  • O repositório Weathergov 2.0 é a segunda implementação após a antiga base de código em Drupal e foi criado para a migração para Wagtail/Django
  • Depois de clonar o repositório, o desenvolvedor pode configurar os contêineres com just zap e verificar o ` aplicativo e o status do proxy da API
  • O diretório de documentação inclui guias para product owners, desenvolvedores, designers, pesquisadores e outros, além dos registros de decisões de arquitetura
  • Código com assistência de IA também pode ser aceito seguindo os mesmos padrões de código e revisão, mas quem submete deve executar o código e os testes pessoalmente e divulgar na solicitação de merge informações de origem, como nome do modelo, versão e ambiente
  • A base de código é operada em partes divididas entre Wagtail CMS, subaplicativos Django, camada e proxy de API em Node.js, código de infraestrutura em Terraform, testes E2E com Playwright e mais

Natureza do Weathergov 2.0

  • Este repositório Git corresponde à segunda iteração do Weathergov 2.0
  • O repositório anterior continha a base de código em Drupal, e este repositório foi criado para a migração para Wagtail/Django

Como executar localmente

  • Depois de clonar o repositório, execute just zap para configurar os contêineres
  • Quando os contêineres estiverem em execução, é possível verificar nos seguintes endereços

Documentação e registros de decisões

  • Em docs/ há guias para várias funções
    • documentação para product owners
    • documentação para desenvolvedores
    • documentação para designers
    • documentação para pesquisadores
    • documentação para outras funções
  • Em docs/architecture/decisions/ há registros de decisões de arquitetura, que explicam a estrutura atual e os motivos das decisões

Política para código com assistência de IA

  • O projeto pode aceitar código com assistência de IA em conformidade com NAO 216-218 Artificial Intelligence in NOAA Policy, Executive Order 14179 "Removing Barriers to American Leadership in Artificial Intelligence", America's AI Action Plan
  • Código com assistência de IA deve seguir os mesmos padrões de revisão do código comum, com um padrão de qualidade ainda mais alto
  • Quem submete deve cumprir o seguinte, da mesma forma que com código escrito por humanos
    • deve ter executado pessoalmente o código e os testes
    • deve ser capaz de explicar à equipe o que o código faz
    • deve entender o problema que está tentando resolver e a solução proposta
  • A responsabilidade pelo comportamento do código enviado, por bugs e por efeitos colaterais permanece sempre com o contribuidor humano
  • Todas as solicitações de merge devem divulgar se incluem código com assistência de IA
    • nome e versão do modelo utilizado
    • ambiente relacionado, como IDE, Copilot etc.
    • outras informações que ajudem a entender a origem do código
  • O checklist exige marcar alterações de código geradas por IA, confirmar que foram executadas diretamente e que as mudanças, problemas e melhorias podem ser explicados tanto para especialistas quanto para não especialistas

Estrutura do código

  • api-interop-layer: aplicativo Node que fica entre o site e a API
  • api-proxy: ferramenta de desenvolvimento e depuração que faz proxy das chamadas de API e injeta dados estáticos
  • forecast/backend: Wagtail CMS que fornece as páginas de previsão
  • forecast/frontend: JavaScript e outros recursos do lado do cliente
  • forecast/locale: arquivos de mensagens para geração de traduções
  • forecast/spatial: subaplicação Django que gerencia o banco de dados espacial
  • spatial-data: aplicativo utilitário em Node.js que gera mapas WFO
  • terraform: código para gerenciamento da infraestrutura e implantação do site
  • tests/playwright: testes E2E com Playwright para o site em execução
  • tests/translations: script de teste que verifica a existência de chaves de tradução e está em estado deprecated
  • justfile: arquivo que executa comandos de desenvolvedor, com papel semelhante ao de um makefile moderno

Leituras relacionadas

1 comentários

 
GN⁺ 2024-03-04
Opiniões no Hacker News

  • Parece estar sendo feito por meio de um contrato/parceria com a 18F (GSA): https://18f.gsa.gov/
    É surpreendente que tenham escrito no README público que “o weather.gov reflete mais os silos da organização do que as necessidades dos usuários (lei de Conway)”. Na minha organização, acho que não teríamos coragem de escrever algo assim em um documento público

    • O US Digital Service e a 18F tiveram um papel enorme em normalizar um ambiente em que as agências podem dizer: “sim, isso não está bom, mas vamos melhorar”
      Fazer com que as partes interessadas baixem a guarda e se sintam seguras para colaborar em uma solução consistente é metade da batalha; nesse tipo de “hackeamento da burocracia”, construir confiança e relacionamentos é subestimado
    • Gostaria que mais organizações fossem transparentes assim
      Silos acabam surgindo, e não quero colocar a culpa em ninguém. Quando sei que o problema é reconhecido e que há vontade de resolvê-lo, consigo aliviar um pouco a frustração
    • A expressão “feedback/monitoramento” me preocupa: será que vão colocar scripts de rastreamento analítico que vêm acompanhados daqueles pop-ups irritantes de cookies?
    • Ainda parece haver bastante silo. Por exemplo, o Office of Water Prediction mantém uma organização no GitHub separada, além de sites como water.weather.gov e os separados preview.water.noaa.gov e water.noaa.gov/map
      Mas os dados de observação em campo, na prática, vêm do USGS, e os dados e serviços web também são fornecidos por waterdata.usgs.gov

  • Talvez seja uma pergunta idiota, mas queria saber se este 2.0 já está em um estado em que dá para usar de verdade em algum lugar, ou se é apenas código-fonte em desenvolvimento
    Uns 8 anos atrás, um dos produtos meteorológicos de aviação do governo dos EUA tinha um site “experimental”, e ele era realmente muito bom. Era moderno, fácil de usar e limpo, sem parecer aqueles sites governamentais esquisitos de sempre; a equipe também parecia boa, mas estava presa a um sistema de orçamento governamental de vários anos. No fim, ele foi fechado e, pelo que me lembro, o trabalho não chegou ao site principal
    Os EUA têm a sorte de contar com excelentes serviços meteorológicos e com a obrigação de oferecê-los como bem público gratuito. Mas também há muita pressão política para que eles não fiquem bons demais, permitindo que empresas comerciais lucrem. Pelo menos em 2005, a AccuWeather era uma dessas empresas: https://www.onthecommons.org/privatizing-weather/index.html

    • Barry Myers / AccuWeather desejaria mais do que qualquer um a privatização de todos os serviços de previsão do tempo; se isso acontecesse, eu e meus colegas do SPC perderíamos nossos empregos
    • Parece que eles têm um ambiente de staging configurado, mas provavelmente não é público em produção: https://github.com/weather-gov/weather.gov/tree/main/.github...
    • Existe um site beta em beta.weather.gov, mas não sei se é o mesmo código-fonte linkado no artigo
    • O README diz que eles concluíram a prototipagem e agora estão criando um MVP
    • O roadmap indica maio
      https://github.com/weather-gov/weather.gov/blob/smh--researc...

  • Estão indo bem. radar.weather.gov é um ótimo site, funciona em todos os dispositivos e funciona muito bem sem anúncios; espero que continuem mantendo-o

    • Minha experiência é exatamente o oposto. No celular, ele não funciona nada bem e é complexo demais para quem procura algo simples e útil como antes
      Também é extremamente lento, e as informações úteis são mais limitadas em comparação com a versão anterior

  • Fico curioso se isso também vai afetar api.weather.gov. Há algum tempo criei um pequeno dashboard (https://weather.nikolaj.dev) inspirado no Weather Underground e ainda o uso na maioria dos dias
    Mas o trabalho de criar minha própria previsão marítima para relatórios de surfe está meio parado. Seria ótimo se eles finalmente preenchessem esses campos. Assim eu não precisaria lidar diretamente com arquivos GRIB

    • Gostei disso. A UI/layout da previsão de 10 dias do Weather Underground era a melhor, mas os anúncios ficaram excessivos
    • Para constar, olhando um dos diagramas de arquitetura, parece que api.weather.gov está fora do escopo deste projeto
    • A interface é boa
      Um probleminha: eu já tinha digitado outro local, mas alguns segundos depois fui redirecionado para o clima de San Diego. Talvez seja porque bloqueei a solicitação de localização

  • Seria bom se todos os projetos open source relacionados ao governo estivessem organizados em um só lugar. Por exemplo, se houvesse uma organização usa-gov no GitHub, seria fácil acessar todos os repositórios

    • Não é exatamente um único lugar, mas esta página [0] lista as organizações do GitHub de várias agências federais. Só que não é abrangente e, em especial, falta a organização da NSA [1]
      [0] https://code.gov/agencies
      [1] https://github.com/nationalsecurityagency
    • Em https://government.github.com/community/ também há organizações internacionais
    • O GitHub não permite direito organizações aninhadas nem estruturas de organizações relacionadas, então colocar todos os repositórios em uma única organização viraria um pesadelo
      Existe o GitHub para governo [0], mas ele depende de contribuições e não é muito completo
      A GSA iniciou o code.gov durante o governo Obama com o objetivo de criar um índice único de todos os projetos do governo. Ele perdeu força no governo Trump e, no governo Biden, o orçamento foi praticamente cortado; hoje basicamente só há links para as principais agências, e a exigência de um índice atualizado também não existe mais
      Só na nossa organização há cerca de 1000 repositórios, e existem centenas de agências assim, então não consigo imaginar reunir tudo sem algum esforço. Originalmente, o code.gov funcionava de um jeito bem bom: cada um publicava um arquivo code.json no seu site, e a GSA coletava esses arquivos e os unificava. Por isso é realmente uma pena terem parado com isso e também deixado de solicitar a publicação do code.json. Era uma boa ideia
      [0] https://government.github.com/community/
    • Na França há https://code.gouv.fr/, e o código-fonte está público no GitHub e no SourceHut: https://github.com/codegouvfr
      https://git.sr.ht/~codegouvfr/

  • Parece o futuro para o qual todas as agências federais podem caminhar. Aplausos ao National Weather Service por liderar o caminho

  • O gráfico de previsão do weather.gov é o mais útil que conheço e é a primeira coisa que procuro quando quero saber do tempo
    Ex.: https://forecast.weather.gov/MapClick.php?lat=37.7771&lon=-1...

    • Concordo. Criei um atalho no gerenciador de janelas que abre no mpv a imagem do tempo por hora da minha localização, e recomendo como uma boa forma de conferir rapidamente o tempo de hoje ou de amanhã
      Também tenho um alias de shell que mostra isso no terminal com kitten icat, mas uso mais o atalho do mpv. Também tenho um alias de previsão em texto, que usa curl para buscar, no caminho abaixo, o arquivo correspondente à minha localização:
      https://tgftp.nws.noaa.gov/data/forecasts/zone/
      Vasculhei os arquivos do meu estado para encontrar o arquivo apropriado, mas parece que o link “More Local Wx” na página de previsão de 7 dias também tem o nome correto do arquivo. No meu caso é ORZ006
      Também criei alguns aliases do icat para mostrar o radar. São para exibição atual, sequencial e em loop, e o nome do radar é obtido da página abaixo, igual ao do radar.weather.gov:
      https://radar.weather.gov/ridge/standard/
      Só que acho que a visualização de precipitação acumulada em 1 hora (One hour accumulation view) é a melhor, mas não encontrei uma forma de obter a imagem dessa visualização, então geralmente vejo pelo radar.weather.gov. Hoje em dia está um pouco melhor, mas às vezes não funciona de jeito nenhum para mim
      Não vejo com frequência, mas também criei aliases do icat que mostram as previsões de temperatura e precipitação para 6 a 10 dias e para o mês:
      https://www.cpc.ncep.noaa.gov/products/predictions/610day/
      https://www.cpc.ncep.noaa.gov/products/predictions/30day/

  • Vejo o arquivo contributing.MD, mas é difícil decidir como realmente contribuir. Como potencial contribuidor, seria bom saber qual é a melhor forma de ajudar

    • perspective é “ponto de vista”; aqui o correto seria prospective, ou seja, “potencial”
      Não estou tentando implicar, só compartilhando na esperança de ajudar

  • Eu esperava ver mais sobre a API para pessoas que criam experiências diretamente especializadas. A NOAA é boa em fornecer dados brutos, mas o consumo e o uso de serviços governamentais costumam ser bem mais específicos
    Estou criando aqui uma ferramenta de resposta a emergências. Ela é generative AI-first, com coisas como monitoramento contínuo → alertas, chatbot e relatórios de situação personalizados. Se houver interesse, podem entrar em contato
    Como várias agências, concessionárias de serviços públicos etc. precisam de variações especializadas, fico ainda mais convencido de que as dificuldades de dados e UI da última milha que o weather.gov deve estar resolvendo internamente também seriam úteis para outras agências
    Pelo que sei, o Weather.gov é operado pelo NWS, sob a NOAA, então é interessante isso não aparecer nesta reformulação da missão

  • É um pouco relacionado, mas, pessoalmente, a URL única mais útil no weather.gov para mim é esta. Basta mudar a latitude/longitude
    https://forecast.weather.gov/MapClick.php?FcstType=graphical...
    Seria bom se também desse para ver dados históricos com o mesmo layout