โปรเจกต์ Rust เพื่อไม่ให้พลาดรถไฟ

 (lilymara.xyz)
2 คะแนน โดย GN⁺ 2024-10-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • สำหรับชีวิตที่เดินทางในซานฟรานซิสโกโดยไม่มีรถยนต์ อุปกรณ์ที่ใช้ดู เวลามาถึงรอบถัดไปของป้ายใกล้บ้าน ได้ทันที ก่อนออกจากบ้าน จะใช้งานได้จริงมากกว่า
  • เจลเบรก Kindle เก่าแล้วดัดแปลงเป็นป้ายข้อมูล e-ink ติดผนัง โดยช่วงแรกแสดงภาพแคปหน้าจอเว็บเพจ BART เป็นระยะ
  • เมื่อเพิ่ม MUNI เข้าไปด้วย ความน่าเชื่อถือของโครงสร้างที่อิงสกรีนช็อตก็ลดลง เพราะต้องมีแท็บเบราว์เซอร์หลายแท็บ, ภาระหน่วยความจำบน Raspberry Pi และ HTTP 429 ซ้อนกัน
  • เวอร์ชันที่เขียนใหม่ด้วย Rust ดึงข้อมูลจาก Stop Monitoring API ของ 511.org และใช้ skia-safe สร้าง PNG โดยตรงให้ตรงกับความละเอียดและความลึกสี 8-bit ของ Kindle
  • เมื่อตัดเอนจินเบราว์เซอร์ออก และเพิ่มแคช การแสดงข้อผิดพลาด รวมถึงการปรับเลย์เอาต์ ก็กลายเป็น ป้ายแสดงข้อมูลขนส่งสาธารณะบน Kindle ที่ใช้งานจริงได้

ข้อมูลที่ต้องใช้ตอนออกจากบ้านนั้นเรียบง่าย

  • ผู้เขียนเดินทางในซานฟรานซิสโกโดยไม่มีรถยนต์ และใช้ขนส่งสาธารณะอย่างรถบัส รถไฟ รถราง รถรางไฟฟ้า เคเบิลคาร์ และเรือเฟอร์รีเป็นประจำ
  • แอปอย่าง CityMapper มีประโยชน์สำหรับการนำทางไปยังจุดหมาย แต่หน้าบ้านนั้น สิ่งที่สำคัญกว่า “จะไปที่ไหน” คือ เวลามาถึงรอบถัดไปของแต่ละสาย
  • หากรู้อยู่แล้วว่าจะใช้ป้ายและสายไหน โมเดลตำแหน่งปัจจุบัน·จุดหมายปลายทางของแอปนำทางทั่วไปก็ซับซ้อนเกินความจำเป็น
  • ได้แรงบันดาลใจจาก บทความของ Matt Healy ที่ใช้ Kindle เก่าเป็นสมาร์ตโฮมดิสเพลย์ และ บทความของ Ben Borgers ที่ใช้ Nook เก่าเป็นกรอบรูป iCloud

กว่าจะทำให้ Kindle แสดงภาพได้

  • ขั้นแรกคือเจลเบรก Kindle เพื่อเปิดใช้ USBNet และให้เชื่อมต่อ SSH ได้
    • จากนั้นใช้ cron job อัปเดตหน้าจอเป็นระยะ
    • ใช้เอกสารเกี่ยวกับการแฮ็ก Kindle จากวิกิและฟอรัมของ mobileread เป็นแหล่งอ้างอิง
  • หน้า Real Time Departure ของ BART เหมาะเป็นแหล่งข้อมูลเริ่มต้น เพราะให้ข้อมูลรถไฟขบวนถัดไปของสถานีที่ต้องการและรีเฟรชอัตโนมัติ
  • พยายามแสดง PNG ด้วย eips ใน Kindle CLI แต่ช่วงแรกภาพถูกยืดหรือถูกตัดอย่างหนักจนใช้งานไม่ได้
  • สาเหตุคือเครื่องมือแสดงผลของ Kindle จัดการ 24-bit RGB PNG ได้ไม่ถูกต้อง และอ่านเหมือนเป็นภาพ 8-bit
    • เมื่อใช้ -colorspace gray -depth 8 ใน ImageMagick convert แล้วจึงแสดงผลได้ปกติ
    • ภาพที่มีขนาดตรงกับหน้าจอ Kindle และ ความลึกสี 8-bit กลายเป็นเงื่อนไขสำคัญ

การทำครั้งแรก: Node.js, Puppeteer, Raspberry Pi

  • เซิร์ฟเวอร์รุ่นแรกใช้ Node.js และ Puppeteer เพื่อแคปเจอร์ส่วนที่ต้องการจากเว็บเพจ BART
  • ภาพที่แคปเจอร์ได้ถูกแปลงให้ตรงกับขนาดหน้าจอ Kindle และเป็นเกรย์สเกล 8-bit ก่อนส่งกลับผ่าน HTTP endpoint
  • รันเซิร์ฟเวอร์บน Raspberry Pi และให้ Kindle ใช้ cron ดึงภาพทุกนาทีมาแสดงด้วย eips
  • เนื่องจากหน้า BART รองรับการรีเฟรชอัตโนมัติอยู่แล้ว จึงเปิดหน้าไว้ครั้งเดียวตอนเริ่มเซิร์ฟเวอร์ และไม่โหลดใหม่ทุกครั้งที่มีคำขอ
  • เวอร์ชันนี้ทำงานได้ดีอยู่พักหนึ่ง แต่บางครั้งการรีเฟรชหยุดทำงาน หรือเซิร์ฟเวอร์ต้องรีสตาร์ตเพราะหน่วยความจำไม่พอ

ข้อจำกัดที่เผยออกมาเมื่อขยายไปยัง MUNI

  • ในเขตอ่าวซานฟรานซิสโกมีผู้ให้บริการขนส่งสาธารณะ 27 ราย และการทำครั้งแรกครอบคลุมเฉพาะ BART ซึ่งเป็นรถไฟด่วนประจำภูมิภาค
  • ต่อมาผู้เขียนอยากดูเวลามาถึงของรถบัสและรถไฟฟ้ารางเบาของ MUNI ด้วย
  • เว็บเพจของ MUNI ก็ให้เวลามาถึงตามป้ายเช่นกัน ช่วงแรกจึงลองใช้ Puppeteer แคปเจอร์หน้าของหลายป้าย แล้วรวมภาพด้วย ImageMagick
  • 7 ส่วนบนหน้าจอแต่ละส่วนสอดคล้องกับ แท็บเบราว์เซอร์ ที่ Puppeteer ต้องคงไว้
    • Raspberry Pi มีหน่วยความจำไม่พอ และ Chrome ก็ไม่ได้เบา
    • หน้า MUNI จะส่ง HTTP 429 กลับมาหากร้องขอบ่อย
  • หน้าจอที่แสดง BART และ MUNI ร่วมกันไม่เสถียรกว่าหน้าจอ BART อย่างเดียวมาก และสำหรับป้ายข้อมูลที่ต้องมองเห็นได้ในครั้งเดียว จำเป็นต้องมีโครงสร้างที่เชื่อถือได้มากกว่า

โครงสร้างที่ออกแบบใหม่ด้วย Rust

  • เวอร์ชันที่เขียนใหม่ตัด Puppeteer ออก และเปลี่ยนเป็นโครงสร้างที่เซิร์ฟเวอร์ HTTP ใน Rust สร้าง PNG โดยตรง
  • ยังคงอินเทอร์เฟซสาธารณะให้คล้ายกับเซิร์ฟเวอร์ Node.js แต่เปลี่ยนการทำงานภายในทั้งหมด
  • องค์ประกอบหลักมีสามอย่าง
    • ดึงเวลามาถึงรอบถัดไปจาก 511.org
    • เรนเดอร์เวลามาถึงเป็นภาพ 8-bit PNG
    • ส่ง PNG ที่สร้างขึ้นกลับผ่านเซิร์ฟเวอร์ HTTP
  • ใช้ Axum สำหรับเซิร์ฟเวอร์ HTTP
  • ใช้ rust-skia สำหรับการเรนเดอร์ PNG
    • Skia เป็นไลบรารีกราฟิกพื้นฐานของ Chrome ด้วย จึงใช้เทคนิคการเรนเดอร์ได้โดยมีภาระน้อยกว่า Puppeteer
  • โค้ดเซิร์ฟเวอร์สุดท้ายมีประมาณ 1,200 บรรทัด และมีการสรุปเฉพาะส่วนสำคัญ

ดึงข้อมูลจาก Stop Monitoring API ของ 511.org

  • Stop Monitoring API ของ 511.org ให้ข้อมูลเวลามาถึง·ออกเดินทางโดยประมาณของป้ายในเขตอ่าว ทั้งในรูปแบบ XML และ JSON
  • endpoint ที่ใช้มีรูปแบบ http://api.511.org/transit/StopMonitoring/…]
  • agency ใช้ระบุหนึ่งในผู้ให้บริการขนส่งสาธารณะ 27 รายในเขตอ่าว โดยโค้ดของ SF MUNI คือ SF
  • API ดึงข้อมูลได้ครั้งละหนึ่งผู้ให้บริการเท่านั้น
    • ส่งกลับเวลามาถึงของป้ายเดียว หรือข้อมูล ทุกป้าย ของผู้ให้บริการรายนั้น
    • ไม่พบวิธีดึงข้อมูลหลายป้ายแบบเป็น subset ในครั้งเดียว
  • ขีดจำกัดของ API 511.org คือ 60 คำขอต่อชั่วโมง ดังนั้นวิธีร้องขอหลายครั้งแยกตามป้ายจึงไม่เหมาะกับการแสดงผลแบบเรียลไทม์
  • เมื่อร้องขอข้อมูลทั้งหมดของ SF MUNI คำขอ HTTP ใช้เวลาประมาณ 5 วินาที และส่งข้อมูลกลับมาประมาณ 27 MiB โดย JSON ที่จัดรูปแบบแล้วมีมากกว่า 1 ล้านบรรทัด
  • ในการตอบกลับทั้งหมดมีรายการ MonitoredStopVisit ประมาณ 26k รายการ แต่หน้าจอจริงต้องใช้เพียง LineRef, DirectionRef, DestinationName, StopPointRef, ExpectedArrivalTime, DestinationDisplay ของป้ายและสายที่กำหนด

รายละเอียดปลีกย่อยที่พบในการประมวลผลข้อมูลด้วย Rust

  • ใช้ reqwest, serde, serde_json, chrono, tokio, eyre เพื่อประกอบการร้องขอ HTTP, การพาร์ส JSON, การคำนวณเวลา, การทำงานแบบอะซิงโครนัส และการจัดการข้อผิดพลาด
  • ตรวจสอบ ID ป้าย MUNI ได้จากหน้าป้ายบนเว็บไซต์ SF MUNI
    • เช่น Persia Ave & Paris St มี 15918 สำหรับ inbound และ 15919 สำหรับ outbound แยกกัน
    • ป้าย MUNI มี ID แยกตามทิศทาง
  • การตอบกลับของ 511.org แนบ UTF-8 Byte Order Mark ไว้หน้า JSON และหากพาร์สด้วย .json() ทันทีจะเกิดข้อผิดพลาด expected value at line 1 column 1
  • เมื่ออ่านการตอบกลับเป็นสตริง UTF-8 ด้วย .text() แล้ว BOM จะถูกลบออก จึงพาร์สด้วย serde_json::from_str ได้
  • หลังกรองแล้วเหลือข้อมูลเวลามาถึงราว 20 รายการของป้ายที่สนใจ ทำให้จัดการได้ง่ายกว่ารายการ 26k ในตอนแรกมาก
  • จัดกลุ่มตาม LineRef และ DirectionRef เรียงตาม ExpectedArrivalTime แล้วแปลง timestamp แบบ UTC เป็นรูปแบบ “อีกกี่นาที”

สร้าง PNG สำหรับ Kindle ด้วย Skia

  • การเรนเดอร์ PNG ใช้ skia-safe
  • สร้างบิตแมป Gray8 ให้ตรงกับขนาดหน้าจอ Kindle คือ 1024x758 เติมพื้นหลังเป็นสีขาว แล้ววาดข้อความและเส้น
  • เริ่มจากสร้างภาพ PNG8 ที่พิมพ์ “Hello World” เพื่อตรวจสอบ pipeline การเรนเดอร์
  • จากนั้นใช้ข้อมูลเวลามาถึงปลอมสร้างภาพรูปแบบตารางที่มีสองคอลัมน์ inbound และ outbound
  • เมื่อรวมกับข้อมูล API จริง จุดหมายและเวลามาถึงหลากหลายกว่าข้อมูลทดสอบ ทำให้เกิดข้อความทับกันในเลย์เอาต์แบบตายตัว
  • เพื่อให้วนทดสอบได้เร็วและเลี่ยงขีดจำกัด API จึงเพิ่มโค้ดชั่วคราวสำหรับแคชการตอบกลับไว้ใน data.json

ปรับแต่งเลย์เอาต์การแสดงผล

  • หน้าจอข้อมูลจริงในช่วงแรกอ่านยาก เพราะแต่ละแถวมีปริมาณข้อมูลที่ต้องแสดงต่างกัน
  • สิ่งที่ปรับปรุงมีดังนี้
    • จัดเวลามาถึงชิดขวาเพื่อลดพื้นที่ว่างท้ายตาราง
    • เอา min หลังเวลาแต่ละตัวออก และใส่ min ไว้เฉพาะท้ายรายการ
    • แสดงเฉพาะรถ 3 คัน ถัดไป
    • เลื่อนชื่อจุดหมายไปทางขวาเพื่อรองรับชื่อสายที่ยาว
  • ต่อมาคำนวณขอบเขตข้อความด้วย measure_str เพื่อแสดง ID สายเป็นกล่องคำพูดกลมสีเทา
  • วางสตริงจุดหมายไว้ห่างจากขอบขวาของกล่องคำพูด ID สาย 15 พิกเซล
  • ด้านบนเพิ่มเฮดเดอร์สีเทาอ่อน และจัด Muni Inbound, Muni Outbound ให้อยู่กึ่งกลาง

ให้บริการ PNG ด้วย Axum

  • สร้างเซิร์ฟเวอร์ HTTP ด้วย Axum 0.7 และส่ง PNG ที่ route /stops.png
  • ตั้งค่า header การตอบกลับเป็น Content-Type: image/png
  • ตอนแรกตรวจสอบ HTTP 200 ด้วย body ว่าง จากนั้นเชื่อมฟังก์ชันสร้างภาพให้ส่งคืนไบต์ PNG จากหน่วยความจำโดยตรง
  • เมื่อใช้ wget บน Kindle ดึงภาพมาแสดงด้วย eips ตอนแรกพบปัญหาภาพหมุนและถูกตัด
  • Kindle ใช้งานแนวตั้งเป็นค่าเริ่มต้น ดังนั้นหากต้องการให้ดูเป็นหน้าจอแนวนอน ต้องใช้เมทริกซ์หมุนก่อนเรนเดอร์
    • สลับขนาดภาพเป็น (758, 1024)
    • หมุนแคนวาส 90.0 องศา

ฟีเจอร์ที่เพิ่มในเวอร์ชันใช้งานจริง

  • เวอร์ชันใช้งานจริงเพิ่มฟีเจอร์ต่อไปนี้
    • ระบบแคช ที่ดึงข้อมูล API ต่อเนื่องในเบื้องหลัง เพื่อให้เซิร์ฟเวอร์ HTTP ตอบสนองได้รวดเร็ว
    • การแสดงเวลาไว้ที่มุมล่างซ้าย และสถานะแคชข้อมูลไว้ที่มุมล่างขวา
    • anti-aliasing
    • การตัดชื่อจุดหมายไม่ให้ทับกับพื้นที่เวลามาถึง
    • การใช้สีเทาต่างกันตามสาย เพื่อให้แยกได้รวดเร็ว
    • การตั้งค่าผ่านไฟล์ config
    • หากเกิดข้อผิดพลาด ให้เรนเดอร์ข้อผิดพลาดและเชน .source() เป็น PNG เพื่อดูได้ทันทีบน Kindle
  • โค้ดเซิร์ฟเวอร์แบบย่อที่ทำร่วมกันอยู่ที่ transit-kindle-simplified
  • โค้ดเซิร์ฟเวอร์ที่ขับ Kindle ติดผนังจริงอยู่ที่ transit-kindle
  • เวอร์ชันที่อิงสกรีนช็อต BART ทำงานได้ราวเดือนกุมภาพันธ์ 2023 และการปรับ UI ขั้นสุดท้ายของเวอร์ชันที่เขียนใหม่ด้วย Rust เสร็จในเดือนมกราคม 2024

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-10-25
ความคิดเห็นจาก Hacker News

  • ฉันทำงานอยู่ที่องค์กรไม่แสวงหากำไรเบื้องหลัง OneBusAway โดย OneBusAway เป็นโปรเจกต์โอเพนซอร์สที่มีผู้คนหลายล้านคนใช้ทุกวันเพื่อตรวจสอบตำแหน่งและเวลาเดินทางมาถึงของรถบัส รถไฟ รถราง และ funicular
    ถ้าเป็นเมืองที่มีเซิร์ฟเวอร์ OneBusAway อยู่แล้ว ก็สามารถใช้ SDK ใหม่เพื่อสร้างแอปแบบกำหนดเองได้: https://github.com/onebusAway/?q=sdk&type=all&language=&sort...
    ถ้าเป็นเมืองที่ยังไม่มีเซิร์ฟเวอร์ ก็สามารถใช้ Docker image และการตั้งค่า OpenTofu ที่ทำไว้ในปีนี้เพื่อแปลงฟีด GTFS/GTFS-RT ให้เป็น REST API ได้
    BART ก็ให้บริการ GTFS และ GTFS-RT เช่นกัน: https://mobilitydatabase.org/feeds/mdb-53
    หน่วยงานขนส่งสาธารณะอื่น ๆ ในสหรัฐก็อยู่ในสถานการณ์ที่อย่างน้อยต้องเผยแพร่ข้อมูลตารางเวลาแบบคงที่ในรูปแบบ GTFS ตามกฎของรัฐบาลกลางใหม่
    เรายินดีต้อนรับนักพัฒนาที่อยากมีส่วนร่วมกับซอฟต์แวร์ที่เกี่ยวข้องเสมอ โดยเฉพาะ นักพัฒนา iOS ที่จำเป็นมากเพื่อช่วยปรับปรุงประสบการณ์ให้ผู้ใช้วันละ 250,000 คน ติดต่อได้ที่ aaron@onebusaway.org
    Docker: https://github.com/OneBusAway/onebusaway-docker / OpenTofu: https://github.com/OneBusAway/onebusaway-deployment

    • ตอนนี้เมืองที่รองรับทั่วโลกมีแค่ 9 เมือง และในนั้น 2 เมืองยังเป็นเบตาอยู่ ดังนั้นถ้ากระจายให้กว้างกว่านี้ได้ก็น่าจะทำให้การมีส่วนร่วมแบบโอเพนซอร์สง่ายขึ้น
      เมืองของฉันเองก็อยากเพิ่มเข้าไปเหมือนกันถ้าขั้นตอนไม่ยุ่งยากนัก ช่วงหลังดูเหมือนจะทุ่มเวลาเชิงวิศวกรรมไปกับการรองรับไลบรารีและ SDK มากพอสมควร แต่ดูแล้วน่าจะดีกว่าถ้าลงทุนกับ เส้นทางที่ง่ายในแง่ประสบการณ์นักพัฒนา เพื่อให้ผู้ร่วมพัฒนาใหม่เริ่มลงมือได้สะดวก
      ตัวอย่างเช่น เอกสารนี้ค่อนข้างซับซ้อน: https://github.com/OneBusAway/onebusaway/wiki/Multi-Region
    • สงสัยว่าจะหารายชื่อเมืองที่มีการติดตั้งใช้งาน OneBusAway ได้จากที่ไหน พอค้นหา “onebusaway cities” ก็เจอ https://onebusaway.org/onebusaway-deployments/ แต่ไม่มีเมืองอย่าง Adelaide ที่ถูกพูดถึงอยู่ในนั้น
    • ถ้าเป็นโอเพนซอร์ส ทำไมถึงขึ้นแค่ Play Store แล้วไม่แจกบน F-Droid ด้วย
    • สงสัยว่าทำไมแอปติดตามรถบัสอย่าง OneBusAway หรือแม้แต่ Google Maps ถึงไม่แม่นกันขนาดนี้
      มันบอกว่า “จะมาถึงใน 4 นาที” แต่รถบัสกลับออกไปต่อหน้าต่อตา หรือบอกว่า “ล่าช้า 5 นาที” แต่จริง ๆ ดันมาเร็วกว่าเวลา 2 นาที บางทีก็ไม่มาเลย
      เดาว่าน่าจะเป็นปัญหาจากข้อมูลต้นทาง แต่อยากรู้รายละเอียดวงในว่ามันไม่น่าเชื่อถือได้เพราะอะไร อ้างอิงจากประสบการณ์ใน Seattle

  • ทั้ง BART และ MUNI รองรับ General Transit Feed Specification และมีวิธีมาตรฐานในการดึงข้อมูลนี้
    https://gtfs.org/documentation/overview/#gtfs-realtime

    • สงสัยว่าข้อมูลเรียลไทม์เชื่อถือได้มากแค่ไหน Google Maps บอกว่า “รถบัสจะมาใน 4 นาที” แต่ฉันกำลังเห็นมันออกไปพอดี หรือบอกว่า “ช้า 5 นาที” แต่จริง ๆ กลับมาเร็วกว่าเวลา 2 นาทีบ่อยมาก

  • ชอบมากจริง ๆ เมื่อก่อนตอนอยู่ Boston โดยไม่มีรถ ฉันเคยต่อของแบบบ้าน ๆ ที่แย่กว่านี้มากขึ้นมาเอง เพื่อจัดการกรณีที่มีหลายวิธีในการไปจาก A ไป B และคำว่า “ดีที่สุด” เปลี่ยนไปตามเวลาหรือสถานที่ที่ต้องแวะระหว่างทาง
    เช่น ก่อนออกไปทำงานฉันต้องพาลูกชายไปส่งที่โรงเรียน และบางครั้งก็แวะกินเช้าหลังส่งเสร็จ ถ้ามีฟีเจอร์ ดูเวลาออกเดินทางถัดไป มันจะช่วยให้ตัดสินใจได้ยืดหยุ่นขึ้นมาก ในสถานการณ์ที่คาดเดาไม่ได้อย่างการเดินเล่นกับเด็ก 4 ขวบในที่น่าสนใจ หรือจะต้องรีบเพื่อให้ทันรถไฟขบวนที่ถ้าพลาดแล้วจะมีช่วงห่างระหว่างขบวน

  • แปลกใจที่ยังไม่มีใครพูดถึง https://oeffi.schildbach.de/index.html ทั้งที่มันทำสิ่งที่ต้องการตรงนี้ได้พอดี

    • มีแอปที่ทำอะไรคล้าย ๆ กันอยู่ไม่น้อย แต่แน่นอนว่าไม่ค่อยมีตัวไหนรันอยู่บน Kindle ที่ติดผนัง
    • พวกนี้ก็น่าพูดถึงเหมือนกัน
      https://play.google.com/store/apps/details?id=nl.skywave.ovi... / https://apps.apple.com/nl/app/ovinfo/id1144468923
      https://drgl.nl/
      https://www.rijdendetreinen.nl/
      https://spoorkaart.mwnn.nl/
    • ไม่คิดเลยว่าแม้แต่ในป่าลึกทางตอนเหนือของสวีเดน ของแบบนี้ก็ยังทำงานแบบ อัปเดตเรียลไทม์ ได้
      มันดีกว่าแอปทางการมาก และแสดงข้อมูลที่ต้องการที่สุดได้ทันที คือป้ายรถเมล์ใกล้ที่สุดกับเวลาจริงของรถบัสคันถัดไป

  • ถ้าอยู่ในสหราชอาณาจักร คุณสามารถซื้ออุปกรณ์ป้ายแสดงเวลาออกเดินทางที่เลียนแบบบอร์ดประกาศเวลาออกจากสถานีได้
    https://ukdepartureboards.co.uk/store/product/desktop-depart...

    • ยังมี https://departureboards.mobi/departures/BTH ที่เลียนแบบป้ายออกเดินทางที่ใช้ในบางสถานีด้วย
    • มันก็ดีนะ แต่ค่อนข้างแพงเกินกว่าจะหาเหตุผลมารองรับการซื้อแบบหุนหันพลันแล่นได้
    • ที่สวิตเซอร์แลนด์ก็มีสินค้าคล้ายกันที่เลียนแบบป้ายรถรางด้วย
      https://tramli.ch/en

  • ฉันก็อยู่ที่ SF เหมือนกัน และได้ทำแอป iOS ชื่อ A Better Ride เพื่อแก้ปัญหาเดียวกัน
    มันแสดงเฉพาะเวลาออกเดินทางของขนส่งสาธารณะจากป้ายใกล้ตัว เป้าหมายคือทำให้การใช้ขนส่งสาธารณะคาดเดาได้และสำรวจได้ง่ายขึ้นเพื่อลดความเครียด เป็นโปรเจกต์ส่วนตัวที่ทำในเวลาว่างโดยไม่ได้หารายได้จากมัน

    • แอปนี้ยอดเยี่ยมมาก ต่างจากแอปขนส่งสาธารณะอื่นตรงที่มันแสดงแค่เส้นทางใกล้ตัวและบอกว่าเส้นทางนั้นไปที่ไหน
      ทำให้คุณสำรวจสถานที่ที่ไปถึงได้โดยไม่ต้องกังวลเรื่องการต่อรถ
    • แอปเจ๋งมาก โดยเฉพาะแผนที่แบบเรียลไทม์
      ฉันเองก็ทำฮาร์ดแวร์ในสายนี้อยู่และเพิ่งทำงานกับ GTFS ไปเยอะ เลยเห็นได้ทันทีว่าต้องใช้แรงมากแค่ไหนในการพาร์สและแสดงข้อมูลการเดินทาง
      ถ้าคุณโอเค ฉันอยากคุยเรื่องการตัดสินใจด้าน UX ในการสรุปและจัดกลุ่มตัวเลือกการเดินทางจากแต่ละป้าย รวมถึงเรื่องแบ็กเอนด์ด้วย
    • ดีมากจริงๆ มีรายละเอียดเล็กๆ ที่ใส่ใจเยอะมาก เช่น บอกว่าต้องอยู่ฝั่งไหนของถนน และทิศทางรวมของการเดินทางเป็นอย่างไร

  • ไม่จำเป็นต้องเจลเบรก Kindle หรือเรนเดอร์ภาพก็ได้
    แค่เปิดหน้าเว็บที่ทำเองด้วยเบราว์เซอร์บน Kindle แล้วใช้คำสั่งดีบักเพื่อปิดโฆษณา “สกรีนเซฟเวอร์” หรือหน้าจอพักของ Kindle
    แม้ว่าแถบเบราว์เซอร์จะยังค้างอยู่ที่ขอบด้านหนึ่งของ Kindle แต่คุณสามารถหมุนเครื่องให้มันไปอยู่ด้านล่างหรือด้านขวาได้ จากนั้นก็ทำหน้าจออากาศ·การจราจร·ข่าวด้วย HTML/CSS/JS แบบง่ายๆ และใช้ภาษาแบ็กเอนด์อะไรก็ได้ตามต้องการ แล้วรันมันบนที่อย่างอินสแตนซ์ราคา 4 ดอลลาร์ของ DigitalOcean ก็พอ
    https://blog.notfaqs.com/2018/06/kindle-e-reader-disable-scr...
    https://www.mobileread.com/forums/showthread.php?t=198334

    • คงจะเจ๋งกว่านี้ถ้า Amazon สนับสนุนและทำโหมดคีออสก์ให้กับเบราว์เซอร์ Kindle สำหรับการแฮ็กจอแบบนี้
    • ฉันเคยทำแบบนี้กับ inkBOOK ที่รัน Android ติดตั้ง Chrome APK แล้วเปิดหน้าเว็บที่ทำเอง
      ใช้ document.documentElement.requestFullscreen() เพื่อเข้าเต็มจอจริงๆ จนไม่เห็นแม้แต่แถบสถานะ และเพราะ API ขนส่งสาธารณะในพื้นที่เข้าถึงได้จากหน้าเว็บโดยตรง ก็เลยไม่ต้องมีแบ็กเอนด์เลย
    • ฉันลองดูด้วย Kindle รุ่นที่ 4 แล้ว ดูเหมือนว่าจะใช้เว็บไซต์ HTTPS แทบไม่ได้เลย เพราะใบรับรองไม่ยังใช้ไม่ได้แล้ว
      แต่ถ้าทำให้มันคุยกับเซิร์ฟเวอร์ในเครือข่ายท้องถิ่นก็น่าจะพอไหว
    • ค่อนข้างแน่ใจว่า Kindle รุ่นหลังจากนั้นได้ถอดความสามารถในการปิดสกรีนเซฟเวอร์ออกไปแล้ว

  • ฉันคิดว่าคุณอาจยังไม่เข้าใจกรณีใช้งานนี้นัก ไม่ใช่ว่าอยาก “ขึ้นรถไฟ” แต่คืออยากไปจาก A ไป B
    ถ้ารถไฟเสีย มีการนัดหยุดงาน เส้นทางปิดช่วงบ่าย 1 ถึง 4 โมง หรือยังไม่ถึงเวลาวิ่ง ฉันก็อยากได้ทางเลือกอื่น นั่นจึงเป็นเหตุผลว่าทำไมสำหรับฉัน สิ่งที่ Google Maps ให้หรือพยายามจะให้จึงจำเป็น
    ถ้าจะไป Oakland จาก Ferry Building แล้ว BART เสีย เรือเฟอร์รี่อาจดีกว่า และถ้าดึกมากแล้วก็อาจเหลือแค่แท็กซี่หรือ Uber
    ถ้าอยู่ที่ Tokyo แล้วจะไป Azabujuban จาก Shibuya ก็มีตัวเลือกอย่าง Ginza Line→Namboku Line, Hanzomon Line→Oedo Line, Yamanote Line→Namboku Line, รถบัสสาย 6, แท็กซี่ ฯลฯ
    และระหว่างสถานีแต่ละสายกับป้ายรถบัสก็ต้องเดินอีก 3-8 นาที ซึ่งความใกล้กับจุดไหนในตอนนั้นก็มีผลต่อการเลือก นอกจากนี้ยังขึ้นอยู่กับว่าคุณสายหรือไม่ หรือมีกระเป๋าใหญ่และหนักแค่ไหน

    • ดูเหมือนว่า Google Maps จะตั้งสมมติฐานอย่างแรงว่าการเดินเป็นสิ่งที่แย่มากและไม่มีใครต้องการ
      เช่น เวลาไปบางที่ คุณนั่งรถบัสสาย 39 แล้วเดิน 15 นาทีก็ถึง แต่ถ้าถาม Google มันจะให้เส้นทางที่ต้องต่อรถ 2 ครั้ง ถ้าโชคดีก็แค่ใช้เวลาใกล้เคียงกับขึ้นรถบัสครั้งเดียวแล้วเดิน
      เพราะงั้นถ้าฉันอยากรู้ว่ารถบัสสาย 39 จะมาตอนไหน ฉันต้องตั้งใจบอกจุดหมายปลายทางเป็นที่อื่น
      อีกอย่าง ในที่ที่ฉันอยู่ ข้อมูลเรียลไทม์ของ Google ก็ดูน่าสงสัย และข้อมูลจากผู้ให้บริการหรือบางแหล่งข้อมูลภายนอกกลับน่าเชื่อถือกว่า
    • กรณีใช้งานคือการเดินทางในชีวิตประจำวัน หลายคนส่วนใหญ่แล้วก็แค่อยาก “ขึ้นรถไฟ” จริงๆ
      บางครั้งก็มีสถานการณ์ที่ต้องวางแผนแบบซับซ้อนแบบเรียลไทม์ และเครื่องมือแบบนั้นก็ดี แต่การเดินทางประจำวันครอบคลุมได้ด้วยเครื่องมือที่ง่ายกว่ามาก
      ตัวอย่าง Tokyo ที่ยกมาก็น่าสนใจ แต่ตามเกณฑ์ของ Google ตัวเลือกขนส่งสาธารณะส่วนใหญ่ใช้เวลา 30-40 นาทีพอๆ กัน จึงแทบเท่ากันสำหรับการวางแผนคร่าวๆ แท็กซี่เร็วกว่า และจักรยานก็ใกล้เคียงกันมาก
    • เวลาเดินทางไปทำงานทุกวัน ฉันก็แค่อยาก “ขึ้นรถไฟ” จริงๆ
      ถ้ารถไฟเสียหรือมีการนัดหยุดงาน มันก็จะเห็นได้จากช่องว่างที่ไม่คาดคิดในรายการรถไฟแบบเรียลไทม์
      ตอนเดินทางไปรอบเมือง ฉันจะเปิด Google Maps แล้วใส่จุดหมาย แต่ตอนออกจากบ้านไปที่ที่เคยไปมาแล้ว 500 ครั้ง ฉันไม่จำเป็นต้องเปิดมันเลย
    • ประสบการณ์ขนส่งสาธารณะในใจกลาง Tokyo เอาไปเหมารวมกับทั้งโลกไม่ได้
      มันมีความหมายพอๆ กับการพูดถึงการช็อปปิ้งหรือการกินข้าวโดยอิงจากประสบการณ์ใน Disneyland เท่านั้น แค่แตะ Suica ก็เร็วกว่าอีกหลายที่หลายเท่าแล้ว และบางที่ก็ไม่มีระบบรองรับแบบนั้นตั้งแต่แรก
    • คุณอาจชอบ https://citymapper.com
      มันมีฟีเจอร์เยอะ แต่ฉันไม่รู้ว่ารองรับ Tokyo ดีแค่ไหน ใน London ถ้าคุณบอกให้พากลับบ้าน มันจะแสดงหลายวิธีโดยปรับให้เหมาะตามค่าใช้จ่าย ระยะเดิน ความเร็ว การต่อรถ การเข้าถึง และอื่นๆ

  • กำลังใช้อะไรที่คล้ายกันอยู่ โดยนำแท็บเล็ต/อุปกรณ์ห้องประชุม Lenovo ThinkSmart View ที่นำกลับมาใช้ใหม่มาต่อกับ Home Assistant และระบบของหน่วยงานขนส่งท้องถิ่น
    ข้อดีคือพร้อมใช้งานได้ทันทีมากกว่าเยอะ แน่นอนว่าต้องลง custom Android ROM บน Lenovo แต่ก็สามารถแสดงอะไรก็ได้ตามต้องการ และควบคุมสิ่งต่าง ๆ อย่างไฟหรือหุ่นยนต์ดูดฝุ่นก็ได้

  • ยังมีผลิตภัณฑ์สวย ๆ ที่ทำแผนที่ BART เป็นป้าย LED แบบกายภาพด้วย: https://www.designrules.co/