Stark Wong 的個人開發網站
 


 此頁面:更新於 2019 年 5 月 2 日 12 時 04 分 09 秒,頁面處理需時 0.001 秒
 網站內容版權所有(C)Stark Wong。頁面(不包括檔案)可自由連結。網站系統版本 1.90-AngularJSBase (2015/9/27)
 
網站地圖

流動巴士版圖NG緊急資料回溯

請注意,由於九巴自己的更新資料有問題 (於新安裝 APP1933 情況下更新到最新資料庫會發現部份路線不存在,例如 33 和 269S 等),以致流動巴士版圖 NG 於 2019/11/29 更新的資料庫亦出現同樣問題。流動巴士版圖的資料庫目前已回溯至 2019/11/25 的版本 (顯示的更新日期為 2019/11/30 但內容實為舊版) 並暫停處理任何更新,直至九巴修復資料庫為止。

更新:我在 APP1933 的更新 XML 看到這個

<br />
<b>Fatal error</b>:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 29374834 bytes) in <b>/home/webmaster/pda/kmb-ws/src/Mst/Model/XmlModel.php</b> on line <b>34</b><br />

似乎他們也沒料到那個 XML 會大到這個程度... (在出現這個問題前那個 XML 的大小已經達到 28.5MB,也就是說 APP1933 每次下載更新都要下載那麼大的檔案再與現存資料進行合併,相比之下流動巴士版圖下載的資料才4.7MB…)


撰寫於:2019/11/30 14:31:53 / 回應已關閉
正在讀取回響內容...
流動巴士版圖 NG iOS 版更新及新軟件開發失敗通告

這次更新的主題有兩個,第一是久違了的流動巴士版圖 NG iOS 版本終於迎來更新 (也很可能是最後一個更新)。本來這個更新是打算在四月當舊網頁托管商無法進行外送要求時發佈的,不過因為後來發現 iOS 的 CFNetworking 可自動處理網址轉向而取消了。直到現在由於 iOS13 發佈日期漸近,而我的 MacBook Air 無法安裝 MacOS 10.14 及 Xcode 12 (試過用 Mod 強制安裝但系統運行速度太慢而換回 10.13),所以趁蘋果未強制開發者使用 iOS 13 SDK 時先把程式更新會比較好。這次版本更新的內容包括:

  • 所有 UI 配置更新至支援 iPhone X
  • 套用 Firebase Remote Config (與 Android 相同),以支援基於伺服器設定的資料庫更新及程式版本更新通知
  • 其他第三方程式庫更新
  • 移除所有 WatchOS 相關的程式碼

在更新流動巴士版圖 NG iOS 版本後,下一個更新將會是舊版流動巴士版圖的功能更新至跟 NG 版接近。

-----

另一件事就是我本來打算發佈一個新的小工具,用來自動接收天文台天氣警告的推送 (因為我不太滿意天文台官方程式的背景耗電),可惜因為天文台公開 API 的各種問題,目前處於壽終正寢(撤回?)的狀態,如何處理尚未清楚。

首先說一下程式功能:

  • 當接收到天文台發出天氣警告時,會自動推送警告訊息予訂閱該類警告的用戶
  • 警告訊息的語言及類型訂閱完全以主題方式儲存於 FCM,我方伺服器完全不需要儲存任何資料 (包括 Push Token)
  • 當天文台取消警告時,會自動以取消訊息取代已推送的警告訊息
  • 當天文台的警告消息時,已推送而沒有手動抹去的訊息會自動消失

 

然後說一下開發時序:

  • 2019/6/13: 開始在 opendata.gov.hk 搜尋過去的天氣警告 xml 以取得各種資料變化
  • 2019/6/17: 完成伺服器端開發 (php7 + cron job) 並放在 AWS 上試行,然後開始 Android (Kotlin) 客戶端開發
  • 2019/6/21: Android 客戶端基本開發完成 (使用無伺服器式透過主題選擇性推送),開始內部測試
  • 2019/6/25: 發現推送訊息偶爾出現空白中文訊息,開始進行調查
  • 2019/7/4: 調查結論 - 天文台中文 xml 會出現空白檔案情況,暫時修改伺服器端以英文資料顯示
  • 2019/7/21: 發現天文台在六月底發佈了 JSON 版本的 API 且有參考文檔,即時決定轉用 JSON API
  • 2019/7/22: 再次以 JSON API 進行內部測試
  • 2019/7/27: 準備提交程式予 Play Store
  • 2019/7/28: 發現 JSON API 後並沒有推送取消通知,開始進行調查
  • 2019/7/31: 發現某些警告 (例如 WFIRE 火災危險警告) 的警告欄位名稱與參考文檔不符 (實際上應是 type 而不是 name),修改後繼續試行
  • 2019/8/8: 再次發現空白警告名稱,開始進行調查
  • 2019/8/11: 調查結論 - 天文台中文 JSON 會缺少應有警告資料 (*1)
  • 2019/8/12: 確定 JSON API 並不會顯示取消的警告 (與參考文檔第 8 頁 actionCode 所示不符) (*2)
  • 2019/8/13: 決定暫停開發

 

請問天文台可以專業一些麼? 簡直失望。

(*1) 於 2019/8/8 20:53:01 取得的資料

英文:
{"WHOT":{"name":"Very Hot Weather Warning","code":"WHOT","actionCode":"REISSUE","issueTime":"2019-08-07T12:40:00+08:00","updateTime":"2019-08-08T16:20:00+08:00"},"WTS":{"name":"Thunderstorm Warning","code":"WTS","actionCode":"ISSUE","issueTime":"2019-08-08T20:50:00+08:00","expireTime":"2019-08-08T22:00:00+08:00","updateTime":"2019-08-08T20:50:00+08:00"}}
中文:
{"WHOT":{"name":"酷熱天氣警告","code":"WHOT","actionCode":"REISSUE","issueTime":"2019-08-07T12:40:00+08:00","updateTime":"2019-08-08T16:20:00+08:00"}}

(*2) 於 2019/8/12 18:03:02 取得的資料

XML:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="style_uc.xsl" type="text/xsl"?>
    <rss version="2.0">
        <channel>
            <title>天氣警告一覽</title>
            <description>由香港天文台提供的天氣警告一覽</description>
            <link>http://www.weather.gov.hk/textonly/warning/warnc.htm</link>
            <language>zh-tw</language>
            <webMaster>[email protected]</webMaster>
            <copyright>本檔案的內容,包括但不限於所有文本、平面圖像、圖畫、圖片、照片以及數據或其他資料的匯編,均受版權保障。香港特別行政區政府是本檔案內所有版權作品的擁有人。</copyright>
            <pubDate>Mon, 12 Aug 2019 18:01:09 +0800</pubDate>
            <image>
                <title>香港天文台</title>
                <url>http://rss.weather.gov.hk/img/logo_dblue.gif</url>
                <width>333</width>
                <height>65</height>
            </image>
            <item>
                <title><![CDATA[取消酷熱天氣警告 (18:00 HKT 12/08/2019) ]]></title>
                <link>http://www.weather.gov.hk/textonly/warning/warnc.htm</link>
                <description><![CDATA[酷熱天氣警告在18時00分取消( 2019年8月12日 )。 <br/><br/>]]></description>
                <author>香港天文台</author>
                <pubDate>Mon, 12 Aug 2019 18:00:00 +0800</pubDate>
                <guid isPermaLink="false">http://rss.weather.gov.hk/rss/201908121800/取消酷熱天氣警告</guid>
            </item>
            <item>
                <title><![CDATA[發出雷暴警告 (15:50 HKT 12/08/2019) ]]></title>
                <link>http://www.weather.gov.hk/textonly/warning/warnc.htm</link>
                <description><![CDATA[雷暴警告在15時50分發出( 2019年8月12日 )。 <br/><br/>]]></description>
                <author>香港天文台</author>
                <pubDate>Mon, 12 Aug 2019 15:50:00 +0800</pubDate>
                <guid isPermaLink="false">http://rss.weather.gov.hk/rss/201908121550/發出雷暴警告</guid>
            </item>
        </channel>
    </rss>

JSON:
{"WTS":{"name":"Thunderstorm Warning","code":"WTS","actionCode":"EXTEND","issueTime":"2019-08-12T15:50:00+08:00","expireTime":"2019-08-12T19:00:00+08:00","updateTime":"2019-08-12T17:00:00+08:00"}}


撰寫於:2019/8/26 23:45:59 / 回應已關閉
正在讀取回響內容...
MagicTV 串流播放器及桌面控制端停止支援

MagicTV 串流播放器及桌面控制端即日起停止支援,現有使用者可仍可繼續使用,但 Play Store 不再提供下載及不再處理桌面控制端的申請。原因?

站長的 Magic TV 7000D 突然燒了,由於並非壞電容那種簡單的問題,所以決定報廢。由於目前市面的 MagicTV 裝置均無法滿足站長的要求,所以不會再添置其他 Magic TV 裝置,故亦無法再對 Magiv TV 系的程式進行任何支援。


撰寫於:2019/5/12 13:29:09 / 回應已關閉
正在讀取回響內容...
網站遷移完成及一些經驗談

由於舊網站托管商3天前無預警掛掉,所以我把原來打算5月15日才開始的遷移工作提早進行。用了 3 天各約半小時就已經完成整個遷移工作,全賴在遷移前有先做好準備。

這次網站遷移跟一般的網站遷移不同,是由找網站托管商改為用 Amazon Lightsail 服務構建小型網站伺服器。在我決定使用 Amazon Lightsail 前,由於我已決定使用基於 Ubuntu Server 18.04 LTS 的 VPS,所以可以先去 Ubuntu Cloud Images 網站下載適用於各虛擬機器程式用的 ova 影像檔,然後我將它匯入到 VMWare 並設定成與 Lightsail 最低規格相同的配備 (512MB 記憶體及單處理器),以可以充份評估效能及系統資源是否足夠。這裡有一點要注意是將 ova 匯入時可以指定預設密碼,但該密碼會在第二次開機時才生效,所以第一次開機時無法登入時無需驚慌,只需重新開機就好。

根據我在舊托商時所用的功能,我要安裝的只需要網站伺服器﹑MySQL﹑FTP 伺服器 (因有自動遠端上傳工作) 及 php,全部都是經 apt 直接下載就可以。

- 網站伺服器:Apache 2.4 –> Nginx 1.14.0-0
- 資料庫伺服器:MySQL 5.1 –> MariaDB 10.1.38-0
- FTP 伺服器:PureFTPd –> PureFTPd
- php: php5 –> php7.2.17-0

除架設伺服器需要進行設定外,由於 php 版本新了不少,現存的腳本有部份需要修改(尤其是使用 mysql 函數的部份要改用 mysqli)。

整個網站複製到 VMWare Ubuntu Cloud 到完成修改約需 2 天假期時間,網站完全運作時才使用了約 50% 的記憶體,所以最低規格的 Lightsail 也應足夠有餘。

到 3 天前網站突然掛掉,立即申請使用 Lightsail,然後根據 Ubuntu Cloud 安裝過的套件立即安裝一次然後把設定複製過去,很快就把 Nginx + php7.2 架好,並把流動巴士版圖的離站報時 API 恢復運作,第 1 天目標完成。

到了昨天遷移資料庫,在用 mysql 客戶端建立好帳號後,通過建立 SSH Local Tunnel 將 Lightsail 上的 MariaDB 呈現在本地網路,然後透過安裝在本地的 phpMyAdmin 進行匯入操作。資料庫匯入完成後書籍掃瞄程式 API 恢復運行,第 2 天目標完成。

最後今天就是將 Ubuntu Cloud 裡的網站檔案打包 scp 到 Lightsail 解開,檢查好權限設定後將臨時頁面 index.html 刪除,整個網站遷移完成。

至於網站前台則不變,仍然有透過 CloudFlare 進行加速、緩存及保護,至此正式擺脫 WCHost 的控制。


撰寫於:2019/5/9 21:50:54 / 回應已關閉
正在讀取回響內容...
修正流動巴士版圖NG新巴/城巴離站時間不正確

前陣子由於托管商問題導致 API 需要暫時遷往臨時伺服器,當時並未發現原來臨時伺服器的 php 並不支援 hash() 函數,以致進行新巴/城巴查詢時會因為報錯而令程式使用另一方的不準確預估時間,現已使用半繞道的方法解決,離站時間恢復正常。另外由於發現 iOS 版本流動巴士版圖對於請求重新指向有完整支援,所以已於伺服器對 iOS 版本程式也開於重新指向,恢復離站時間功能而不需要更新程式。


撰寫於:2019/3/21 23:31:41 / 回應已關閉
正在讀取回響內容...
書籍掃瞄程式線上功能恢復

待流動巴士版圖的離站時間查詢功能恢復正常後,現在亦把書籍掃瞄程式的線上查詢功能暫時修好。由於該程式所使用的網路程式庫不同,該程式庫可支援網址轉向,也就是說不需要進行程式更新已經可以自動回復正常。

WCHost 在用了那麼多年後終於給我充足的不續期理由,該開始留意還有哪家好用的網站託管商了...


撰寫於:2019/3/7 22:02:21 / 回應已關閉
正在讀取回響內容...
流動巴士版圖緊急更新

目前的流動巴士版圖由昨天開始發現無法進行離站時間查詢,經調查後發現所用的伺服器被封鎖了外出連線導致無法向第三方來源查詢時間。雖然問題已於晚上進行緊急分流修正,但由於程式本身不支援重新指向回應導致修改無效,故趕緊將自動離站查詢功能完成後上載更新版本。

Android 流動巴士版圖新版本有以下修改:

  1. 新增自動離站時間查詢功能,可讓使用者設定每天特定時間於特定位置查詢巴士離站時間,不需要每天重覆做路線搜尋動作
  2. 修正離站時間查詢功能,原因為上面所示,但注意現在的分流方法不能保證穩定性,長遠需要尋找其他方法

至於 iOS 版本由於目前的程式碼並不符合 App Store 審核要求,故暫時不作修改,看看伺服器會不會恢復正常再作決定。

除了流動巴士版圖外,書籍掃瞄程式目前也無法錄入新書資料,但由於後台比較複雜並有緩存層,目前未有決定該如何解決。


撰寫於:2019/3/2 16:05:02 / 回應已關閉
正在讀取回響內容...
流動巴士版圖資料更新恢復

站長的電腦目前已經修復完成,流動巴士版圖的資料庫亦已經恢復更新。

不過似乎發現新巴/城巴的轉乘資料無法顯示,這個會再作修正。


撰寫於:2019/1/21 23:42:23 / 回應已關閉
正在讀取回響內容...
流動巴士版圖資料庫暫緩更新
由於站長電腦故障,流動巴士版圖(所有版本)資料庫暫時無法更新,預計星期二晚恢復。
撰寫於:2019/1/20 19:13:52 / 回應已關閉
正在讀取回響內容...
流動巴士版圖 NG iOS 版本重新上架 / 最近動態

由於收到一些網友查詢有關流動巴士版圖 NG iOS 版本無法在 App Store 中找到,而且新巴/城巴 App 最近也跟隨九巴 App 一樣加上煩擾式的廣告,故決定將流動巴士版圖 iOS 版重新上架,不過暫時不會進行任何程式更新 (資料庫仍可更新)。

最近一直在開發及測試 Android 版本流動巴士版圖透過鬧鐘及 Geofence 進行定時自動離站時間通知功能,不過似乎由於 Android 系統目前增添了不少省電功能,要在不使用 Wake Lock 之下穩定操作似乎有不少難度...

目前所遇到的問題包括 (可能是 Android 問題,也有可能是 Samsung 的問題):

  1. 鬧鐘觸發時間不準確,即使用 setExact() / setRepeating() 也有可能延遲達數分鐘
  2. Geofence.Builder 裡的 setTransitionTypes() 包含 GEOFENCE_TRANSITION_DWELL 旗標時,DWELL 通知觸發一次後就不再觸發,無論 LoiteringDelay 和 NotificationResponsiveness 的值為何
  3. FusedLocationProvider 有時候座標會嚴重偏移到即使設定距離 100 米也無法觸發 GEOFENCE_TRANSITION_ENTER
  4. 即使 GEOFENCE_TRANSITION_ENTER 正常,有時候 GEOFENCE_TRANSITION_EXIT 觸發距離超過 500 米
  5. 綜合 Stackoverflow 裡建議手動強制更新定位資訊讓 Geofence 較準確的方法似乎對 Android 8 無效
  6. BroadcastReceiver 裡使用 JobService (非 JobIntentService) 好像沒有加 Wake Lock,令手機關屏時所排定的 JobService 要到屏幕打開時才開始

由於那麼多問題,這個功能是否能推出也是一個問題...OTL


撰寫於:2018/12/3 00:31:22 / 回應已關閉
正在讀取回響內容...
其他較舊內容請移步至舊部落格版面