ประกาศอัปเดต Weather.gov 2.0

• รีโพซิทอรี Weathergov 2.0 เป็นการพัฒนารอบที่สองหลังจากโค้ดเบส Drupal เดิม และเป็นโปรเจกต์ที่สร้างขึ้นเพื่อย้ายไปยัง Wagtail/Django
• นักพัฒนาสามารถโคลนรีโพซิทอรีแล้วตั้งค่าคอนเทนเนอร์ด้วย just zap และสามารถตรวจสอบแอปได้ที่ http://localhost:8080 และตรวจสอบ สถานะ API proxy ได้ที่ http://localhost:8081
• ไดเรกทอรีเอกสารมีคู่มือสำหรับ product owner, นักพัฒนา, ดีไซเนอร์, นักวิจัย และบทบาทอื่น ๆ รวมถึง บันทึกการตัดสินใจด้านสถาปัตยกรรม
• โค้ดที่มี AI ช่วยเขียนสามารถรับได้ตามเกณฑ์เดียวกับโค้ดทั่วไปและการรีวิวทั่วไป แต่ผู้ส่งต้องรันโค้ดและทดสอบด้วยตนเอง และเปิดเผยข้อมูลแหล่งที่มา เช่น ชื่อโมเดล·เวอร์ชัน·สภาพแวดล้อม ใน merge request
• โค้ดเบสถูกแบ่งและดูแลเป็นส่วนต่าง ๆ เช่น Wagtail CMS, แอปย่อยของ Django, ชั้น API และ proxy ของ Node.js, โค้ดโครงสร้างพื้นฐาน Terraform, การทดสอบ E2E ด้วย Playwright เป็นต้น

---

ลักษณะของ Weathergov 2.0

• Git repository นี้เป็น การทำซ้ำรอบที่สองของ Weathergov 2.0
• repository ก่อนหน้าเก็บโค้ดเบส Drupal ไว้ ส่วน repository นี้ถูกสร้างขึ้นเพื่อ ย้ายไปยัง Wagtail/Django

วิธีรันในเครื่อง

• หลังจากโคลน repository แล้ว รัน just zap เพื่อ ตั้งค่าคอนเทนเนอร์ได้
• เมื่อคอนเทนเนอร์ทำงานแล้ว สามารถตรวจสอบได้ที่ที่อยู่ต่อไปนี้
  • http://localhost:8080: หน้าจอการทำงานของแอปพลิเคชัน
  • http://localhost:8081: สถานะ API proxy

เอกสารและบันทึกการตัดสินใจ

• ภายใต้ docs/ มีคู่มือสำหรับหลายบทบาท
  • เอกสารสำหรับ product owner
  • เอกสารสำหรับนักพัฒนา
  • เอกสารสำหรับดีไซเนอร์
  • เอกสารสำหรับนักวิจัย
  • เอกสารสำหรับบทบาทอื่น ๆ
• ใน docs/architecture/decisions/ มี บันทึกการตัดสินใจด้านสถาปัตยกรรม ซึ่งอธิบายโครงสร้างปัจจุบันและเหตุผลของการตัดสินใจ

นโยบายโค้ดที่มี AI ช่วยเขียน

• โปรเจกต์สามารถรับ โค้ดที่มี AI ช่วยเขียน ได้ตาม NAO 216-218 Artificial Intelligence in NOAA Policy, Executive Order 14179 "Removing Barriers to American Leadership in Artificial Intelligence", America's AI Action Plan
• โค้ดที่มี AI ช่วยเขียนต้องเป็นไปตามเกณฑ์ของโค้ดทั่วไปและการรีวิวทั่วไป และจะใช้มาตรฐานคุณภาพที่สูงกว่า
• ผู้ส่งต้องทำตามข้อกำหนดต่อไปนี้เช่นเดียวกับโค้ดที่มนุษย์เขียน
  • ต้องรันโค้ดและการทดสอบด้วยตนเองแล้ว
  • ต้องสามารถอธิบายให้ทีมฟังได้ว่าโค้ดทำอะไร
  • ต้องเข้าใจปัญหาที่ต้องการแก้และวิธีแก้ที่เสนอ
• ความรับผิดชอบต่อพฤติกรรม บั๊ก และผลข้างเคียงของโค้ดที่ส่งมา จะอยู่กับ ผู้ร่วมพัฒนาที่เป็นมนุษย์ เสมอ
• merge request ทั้งหมดต้องเปิดเผยว่ามีโค้ดที่ AI ช่วยเขียนหรือไม่
  • ชื่อและเวอร์ชันของโมเดลที่ใช้
  • สภาพแวดล้อมที่เกี่ยวข้อง เช่น IDE, Copilot
  • ข้อมูลอื่น ๆ ที่ช่วยให้เข้าใจแหล่งที่มาของโค้ด
• เช็กลิสต์กำหนดให้ต้องระบุการเปลี่ยนแปลงโค้ดที่สร้างโดย AI, ต้องรันด้วยตนเองแล้ว และต้องสามารถอธิบายการเปลี่ยนแปลง·ปัญหา·การปรับปรุงให้ทั้งผู้เชี่ยวชาญและผู้ที่ไม่ใช่ผู้เชี่ยวชาญเข้าใจได้

โครงสร้างโค้ด

• api-interop-layer: แอป Node ที่อยู่ระหว่างไซต์กับ API
• api-proxy: เครื่องมือสำหรับพัฒนาและดีบักที่ proxy การเรียก API และแทรกข้อมูลแบบ static
• forecast/backend: Wagtail CMS ที่ให้บริการหน้าพยากรณ์อากาศ
• forecast/frontend: JavaScript และ asset ฝั่งไคลเอนต์อื่น ๆ
• forecast/locale: ไฟล์ข้อความสำหรับสร้างคำแปล
• forecast/spatial: แอปพลิเคชันย่อย Django สำหรับจัดการฐานข้อมูลเชิงพื้นที่
• spatial-data: แอป utility บน Node.js สำหรับสร้างแผนที่ WFO
• terraform: โค้ดสำหรับจัดการโครงสร้างพื้นฐานและ deploy ไซต์
• tests/playwright: การทดสอบ E2E ด้วย Playwright สำหรับไซต์ที่กำลังทำงานอยู่
• tests/translations: สคริปต์ทดสอบสำหรับตรวจสอบว่ามี translation key อยู่หรือไม่ และอยู่ในสถานะ deprecated
• justfile: ไฟล์สำหรับรันคำสั่งของนักพัฒนา ทำหน้าที่ใกล้เคียงกับ makefile สมัยใหม่

[GN⁺]

ความคิดเห็นจาก Hacker News

• ดูเหมือนว่าจะดำเนินการผ่านสัญญา/ความร่วมมือกับ 18F(GSA): https://18f.gsa.gov/
  น่าประหลาดใจที่ใน README สาธารณะเขียนไว้ตรง ๆ ว่า “weather.gov สะท้อน ไซโล ขององค์กร มากกว่าความต้องการของผู้ใช้ (กฎของ Conway)” ถ้าเป็นองค์กรเรา คงไม่มีความกล้าเขียนแบบนั้นในเอกสารสาธารณะ

  • US Digital Service และ 18F มีบทบาทมากในแง่ที่ทำให้การที่หน่วยงานจะพูดว่า “ใช่ มันไม่ค่อยดี แต่เราจะทำให้ดีขึ้น” กลายเป็นเรื่อง ปกติ
    ครึ่งหนึ่งของชัยชนะในงานแบบนี้คือการทำให้ผู้มีส่วนได้ส่วนเสียรู้สึกปลอดภัยพอจะเลิกตั้งการ์ด และร่วมมือกันเพื่อหาทางออกที่สอดคล้องกัน และใน “การแฮ็กระบบราชการ” แบบนี้ การ สร้างความไว้วางใจและความสัมพันธ์ มักถูกประเมินค่าต่ำเกินไป
  • อยากให้มีองค์กรที่ โปร่งใส แบบนี้มากขึ้น
    ไซโลเป็นสิ่งที่เกิดขึ้นได้เสมอ และไม่อยากโยนความผิดให้ใคร ถ้ารู้ว่าปัญหาถูกยอมรับแล้วและมีความตั้งใจจะแก้ ก็ช่วยลดความอึดอัดลงได้พอสมควร
  • พอเห็นคำว่า “feedback/monitoring” ก็อดกังวลไม่ได้ว่าจะใส่ สคริปต์ติดตามวิเคราะห์ข้อมูล ที่มาพร้อมป๊อปอัปคุกกี้น่ารำคาญหรือเปล่า
  • ดูเหมือนว่ายังมีไซโลอยู่พอสมควร เช่น Office of Water Prediction มี องค์กร GitHub แยกต่างหาก และยังมีทั้ง preview.water.noaa.gov กับ water.noaa.gov/map ที่แยกจาก water.weather.gov
    แต่ข้อมูลการสังเกตการณ์ภาคสนามจริง ๆ มาจาก USGS และทั้งข้อมูลกับเว็บเซอร์วิสก็ให้บริการจาก waterdata.usgs.gov

• อาจเป็นคำถามงี่เง่า แต่สงสัยว่า 2.0 นี้อยู่ในสถานะที่ลองใช้ได้จริงที่ไหนสักแห่งแล้วหรือยัง หรือยังเป็นแค่ซอร์สโค้ดที่กำลังพัฒนาอยู่
  เมื่อราว 8 ปีก่อน เคยมีเว็บไซต์ “experimental” สำหรับผลิตภัณฑ์อุตุนิยมวิทยาการบินของรัฐบาลสหรัฐตัวหนึ่ง ซึ่งดีมาก ทันสมัย ใช้ง่าย เรียบร้อย และไม่เหมือนเว็บไซต์ราชการที่มักดูเก้ ๆ กัง ๆ ทั่วไป ทีมก็ดูดี แต่ติดอยู่กับระบบงบประมาณของรัฐแบบหลายปี สุดท้ายก็ปิดไป และถ้าจำไม่ผิด งานนั้นก็ไม่ได้ถูกย้ายขึ้นเว็บไซต์หลัก
  สหรัฐถือว่าโชคดีที่มีบริการพยากรณ์อากาศยอดเยี่ยม และมีพันธกิจว่าจะต้องให้บริการแบบฟรีและเป็นสาธารณประโยชน์ เพียงแต่ก็มีแรงกดดันทางการเมืองมากมายที่คอยไม่ให้มันดีเกินไป เพื่อให้บริษัทเชิงพาณิชย์ยังทำกำไรได้ อย่างน้อยในปี 2005 AccuWeather ก็เป็นหนึ่งในบริษัทแบบนั้น: https://www.onthecommons.org/privatizing-weather/index.html

  • Barry Myers / AccuWeather น่าจะเป็นคนที่อยากเห็น การแปรรูปบริการพยากรณ์อากาศทั้งหมด มากกว่าใคร และถ้าเป็นแบบนั้น ผมกับเพื่อนร่วมงานที่ SPC ก็คงตกงาน
  • ดูเหมือนจะมีสภาพแวดล้อม staging อยู่ แต่คงยังไม่ใช่ไลฟ์สาธารณะ: https://github.com/weather-gov/weather.gov/tree/main/.github...
  • มี เว็บไซต์เบตา อยู่ที่ beta.weather.gov แต่ไม่แน่ใจว่าเป็นตัวเดียวกับซอร์สที่ลิงก์ไว้ในโพสต์หรือเปล่า
  • ใน README ระบุว่าทำต้นแบบเสร็จแล้ว และตอนนี้กำลังทำ MVP
  • ในโรดแมประบุไว้ว่าเป็น เดือนพฤษภาคม
    https://github.com/weather-gov/weather.gov/blob/smh--researc...

• ทำได้ดีมาก radar.weather.gov เป็นเว็บไซต์ที่ยอดเยี่ยม ใช้งานได้บนทุกอุปกรณ์ ทำงานได้ดีมากโดยไม่มีโฆษณา หวังว่าจะรักษาแบบนี้ต่อไป

  • ประสบการณ์ของผมตรงกันข้ามเลย บนมือถือใช้งานได้ไม่ดีเลย และสำหรับคนที่มองหาความเรียบง่ายกับประโยชน์ใช้สอยแบบเดิม มันซับซ้อนเกินไป
    ยังช้ามากด้วย และเมื่อเทียบกับเวอร์ชันก่อนก็มีข้อมูลที่มีประโยชน์ให้จำกัดกว่าเดิม

• สงสัยว่านี่จะส่งผลกับ api.weather.gov ด้วยไหม ผมเคยทำแดชบอร์ดเล็ก ๆ ที่ได้แรงบันดาลใจจาก Weather Underground (https://weather.nikolaj.dev) และยังใช้มันอยู่เกือบทุกวัน
  แต่โปรเจ็กต์ที่พยายามทำ พยากรณ์ทางทะเล เองสำหรับรายงานโต้คลื่นค่อนข้างหยุดชะงักอยู่ หวังว่าสุดท้ายจะมีการเติมข้อมูลในฟิลด์เหล่านั้นให้ครบ จะได้ไม่ต้องไปไล่แกะไฟล์ GRIB เอง

  • ชอบอันนี้นะ UI/เลย์เอาต์ของ พยากรณ์ 10 วัน ของ Weather Underground ดีที่สุดแล้ว แต่โฆษณาหนักเกินไป
  • เผื่อเป็นข้อมูล จากแผนภาพสถาปัตยกรรมอันหนึ่ง ดูเหมือนว่า api.weather.gov จะอยู่นอก ขอบเขต ของโปรเจ็กต์นี้
  • อินเทอร์เฟซดีนะ
    มีปัญหาเล็กน้อยคือผมกรอกตำแหน่งอื่นไปแล้ว แต่ไม่กี่วินาทีถัดมากลับถูกรีไดเร็กต์ไปเป็นสภาพอากาศของ San Diego อาจเป็นเพราะบล็อกการขอพิกัดตำแหน่งไว้ก็ได้

• คงจะดีถ้ามีการรวบรวม โครงการโอเพนซอร์ส ที่เกี่ยวข้องกับรัฐบาลทั้งหมดไว้ในที่เดียว เช่น ถ้ามีองค์กร usa-gov บน GitHub เพื่อให้เข้าถึงทุกรีโพซิทอรีได้ง่าย

  • แม้จะไม่ใช่ที่เดียวแบบเป๊ะ ๆ แต่หน้านี้ [0] แสดงรายชื่อองค์กร GitHub ของหน่วยงานรัฐบาลกลางหลายแห่ง อย่างไรก็ตามก็ไม่ได้ครอบคลุมทั้งหมด โดยเฉพาะองค์กรของ NSA [1] ที่ไม่มีอยู่ในนั้น
    [0] https://code.gov/agencies
    [1] https://github.com/nationalsecurityagency
  • https://government.github.com/community/ มี หน่วยงานนานาชาติ ด้วย
  • GitHub ไม่ได้รองรับองค์กรแบบซ้อนกันหรือโครงสร้างองค์กรที่เกี่ยวเนื่องกันได้ดีนัก ดังนั้นถ้าจะเอารีโพซิทอรีทั้งหมดไปไว้ในองค์กรเดียวก็น่าจะเป็นฝันร้าย
    แม้จะมี GitHub สำหรับภาครัฐ [0] อยู่ แต่ก็อาศัยการมีส่วนร่วมและยังไม่สมบูรณ์มาก
    GSA เริ่ม code.gov ในยุครัฐบาล Obama โดยมีเป้าหมายจะสร้างดัชนีรวมเดียวของทุกโครงการภาครัฐ มันซบเซาลงในยุครัฐบาล Trump และในยุครัฐบาล Biden ก็แทบไม่มีงบแล้ว ทุกวันนี้เลยทำได้แค่ลิงก์ไปยังหน่วยงานหลัก ๆ และก็ไม่มีข้อกำหนดเรื่องการทำดัชนีแบบทันเวลาอีกต่อไป
    แค่องค์กรของเราก็มีรีโพซิทอรีราว 1000 อันแล้ว และมีหน่วยงานแบบนี้อีกหลายร้อยแห่ง จึงนึกไม่ออกเลยว่าจะรวบรวมทั้งหมดได้โดยไม่ลงแรงพอสมควร เดิมที code.gov ทำงานได้ค่อนข้างดี เพราะแต่ละที่แค่อัปโหลดไฟล์ code.json ไว้บนเว็บไซต์ของตัวเอง แล้ว GSA ก็ไปเก็บรวบรวมและรวมเข้าด้วยกัน ดังนั้นจึงน่าเสียดายมากที่หยุดทำแบบนั้นและหยุดขอให้เผยแพร่ code.json ด้วย เป็นไอเดียที่ดีมาก
    [0] https://government.github.com/community/
  • ฝรั่งเศสมี https://code.gouv.fr/ และซอร์สก็เปิดเผยบน GitHub กับ SourceHut: https://github.com/codegouvfr
    https://git.sr.ht/~codegouvfr/

• ดูเหมือนเป็นภาพอนาคตที่หน่วยงานรัฐบาลกลางทั้งหมดสามารถมุ่งไปได้ ขอชื่นชม National Weather Service ที่เป็นผู้นำ

• กราฟพยากรณ์อากาศ ของ weather.gov เป็นสิ่งที่มีประโยชน์ที่สุดอย่างหนึ่งเท่าที่ฉันรู้จัก และเป็นที่แรกที่ฉันเปิดดูเมื่ออยากเช็กอากาศ
  ตัวอย่าง: https://forecast.weather.gov/MapClick.php?lat=37.7771&lon=-1...

  • ใช่เลย ฉันทำ คีย์ลัดของตัวจัดการหน้าต่าง ไว้สำหรับเปิดภาพสภาพอากาศรายชั่วโมงของตำแหน่งฉันด้วย mpv และแนะนำว่าเป็นวิธีที่ดีสำหรับเช็กอากาศวันนี้หรือพรุ่งนี้แบบเร็ว ๆ
    ฉันก็มีเชลล์ alias สำหรับแสดงผ่าน kitten icat ในเทอร์มินัลด้วย แต่ใช้คีย์ลัด mpv บ่อยกว่า อีกทั้งยังมี alias สำหรับดูสภาพอากาศแบบข้อความ ซึ่งจะใช้ curl ไปดึงไฟล์ของตำแหน่งฉันจากพาธด้านล่าง:
    https://tgftp.nws.noaa.gov/data/forecasts/zone/
    ฉันไล่ดูไฟล์ของรัฐตัวเองเพื่อหาไฟล์ที่เหมาะสม แต่ดูเหมือนลิงก์ “More Local Wx” ในหน้าพยากรณ์ 7 วันจะมีชื่อไฟล์ที่ถูกต้องอยู่ด้วย สำหรับฉันคือ ORZ006
    ฉันยังทำ alias ของ icat ไว้ไม่กี่ตัวสำหรับแสดงเรดาร์ ทั้งแบบปัจจุบัน แบบลำดับภาพ และแบบวนซ้ำ โดยใช้ชื่อเรดาร์เดียวกับ radar.weather.gov จากหน้าด้านล่าง:
    https://radar.weather.gov/ridge/standard/
    แต่ฉันคิดว่ามุมมองปริมาณฝนสะสม 1 ชั่วโมง (One hour accumulation view) ดีที่สุด ทว่าหาวิธีดึงภาพของมุมมองนั้นไม่เจอ ก็เลยมักจะดูที่ radar.weather.gov แทน ช่วงนี้ดีขึ้นบ้างแล้ว แต่บางครั้งก็ยังไม่ทำงานกับฉันเลย
    แม้จะไม่ได้ดูบ่อย แต่ฉันก็ทำ alias ของ icat ไว้สำหรับแสดงแนวโน้มอุณหภูมิและปริมาณฝนช่วง 6–10 วันและรายเดือนด้วย:
    https://www.cpc.ncep.noaa.gov/products/predictions/610day/
    https://www.cpc.ncep.noaa.gov/products/predictions/30day/

• เห็นไฟล์ contributing.MD แต่ยากที่จะตัดสินได้ว่าจริง ๆ แล้วจะมีส่วนร่วมได้อย่างไร ในฐานะ ผู้มีแนวโน้มจะเป็นผู้ร่วมพัฒนา ก็คงดีถ้ารู้ได้ว่าวิธีที่ดีที่สุดในการช่วยคือแบบไหน

  • perspective แปลว่า “มุมมอง” และในที่นี้คำที่ถูกต้องคือ prospective ซึ่งหมายถึง “ที่อาจเป็นในอนาคต”
    ไม่ได้จะจับผิด แค่อยากช่วยเลยแชร์ไว้

• ฉันหวังว่าจะมีการพูดถึง API สำหรับคนที่สร้างประสบการณ์เฉพาะทางโดยตรงมากกว่านี้ NOAA ทำได้ดีในการให้ข้อมูลดิบ แต่การนำบริการภาครัฐไปใช้และต่อยอดมักมีกรณีใช้งานที่เฉพาะเจาะจงกว่านั้นมาก
  ตอนนี้ฉันกำลังสร้างเครื่องมือสำหรับการตอบสนองเหตุฉุกเฉิน เน้น generative AI เป็นหลัก เช่น การมอนิเตอร์ต่อเนื่อง → การแจ้งเตือน, แชตบอต, รายงานสถานการณ์แบบปรับให้เหมาะกับผู้ใช้ ถ้าสนใจก็ติดต่อมาได้
  เมื่อหน่วยงานต่าง ๆ ยูทิลิตี และองค์กรอื่น ๆ ต้องการเวอร์ชันเฉพาะทางกันมากขึ้น ก็ยิ่งทำให้เห็นชัดว่าโจทย์ข้อมูลและ UI ในช่วงปลายทางที่ weather.gov กำลังแก้อยู่ภายในนั้น น่าจะช่วยหน่วยงานอื่นได้ด้วย
  เท่าที่ฉันรู้ Weather.gov ดำเนินการโดย NWS ภายใต้ NOAA ดังนั้นจึงน่าสนใจที่ไม่มีการพูดถึงเรื่องนั้นในการปรับภารกิจครั้งนี้

• เป็นเรื่องที่เกี่ยวข้องกันเล็กน้อย แต่โดยส่วนตัวแล้ว URL เดียวที่มีประโยชน์ที่สุดใน weather.gov สำหรับผมคืออันนี้ แค่เปลี่ยนละติจูด/ลองจิจูดก็พอ
  https://forecast.weather.gov/MapClick.php?FcstType=graphical...
  ถ้าดูข้อมูลย้อนหลังได้ด้วยในเลย์เอาต์แบบเดียวกันก็คงดี

  • สำหรับผมมันวิทยาศาสตร์เกินไปหน่อย เลยชอบอันนี้มากกว่า: https://forecast.weather.gov/MapClick.php?lat=37.7771&lon=-1...