這裡要介紹的是快速將 JSON/CSV/XML檔案的內容至 wordpress 裡的方法, 介紹使用工具為:
https://wordpress.org/plugins/wp-all-import/
雖然沒有 JSON 檔案格式, 不過可以利用這個線上工具進行:
作者: tim
- 遠距醫療挑戰與契機！健保署：2021 年正式納入健保給付範圍 https://geneonline.news/index.php/2020/12/04/telemedicine-future-trend/
- 台灣遠距醫療法規現況與未來挑戰 https://udn.com/news/story/6871/5009650
- 健保署葉逢明：匡列一億臺幣預算 2021將為健保給付遠距醫療元年 https://news.gbimonthly.com/tw/article/show.php?num=35138
看起來遠距醫療因為疫情與偏鄉等資源分配議題, 加速開放了, 這個產業應用, 實際上的難度不在遠距, 而是在診斷啊, 若不是能用視訊方式來實現的檢查, 實務上真的能看診或解決病患的問題嗎?
這個方式很棒, 但是是否能有效看診, 或是解決病患的痛苦, 才是要思考的問題, 不過政府與醫界能正視與肯投入這個應用技術的方式來擴大與解決醫病問題, 的確是很值得鼓勵的!
有兩點座標在地球表面上, 要計算兩點的距離, 會用到 haversine (半正矢公式)來進行計算.
- https://zh.wikipedia.org/wiki/%E5%8D%8A%E6%AD%A3%E7%9F%A2%E5%85%AC%E5%BC%8F
- https://en.wikipedia.org/wiki/Haversine_formula
其中 Haversine 公式就是用來計算這個球面上的大圓距離, 公式如下:
利用這個公式, 可以建立一個 python function (半徑為地球半徑: 6371km):
import numpy as np def haversine_distance(lat1, lon1, lat2, lon2): r = 6371 phi1 = np.radians(lat1) phi2 = np.radians(lat2) delta_phi = np.radians(lat2 - lat1) delta_lambda = np.radians(lon2 - lon1) a = np.sin(delta_phi / 2)**2 + np.cos(phi1) * np.cos(phi2) * np.sin(delta_lambda / 2)**2 res = r * (2 * np.arctan2(np.sqrt(a), np.sqrt(1 -a))) return np.round(res, 2)
不過其實 python 原本就有函數庫: haversine 也可以直接引用:
import haversine as hs loc1=(28.426846,77.088834) loc2=(28.394231,77.050308) hs.haversine(loc1,loc2)
(上面預設單位就是 km 了)
程式碼範例與執行結果請參考:
https://colab.research.google.com/drive/1Tap7kaY-yG09OvpJKhja9ni2T8yMdxJZ?usp=sharing
參考資料:
https://towardsdatascience.com/calculating-distance-between-two-geolocations-in-python-26ad3afe287b
分類
Google表單上傳檔案
最近在填寫商場活動表單時, 需要上傳發票檔案, 才發現原來 Google 表單也可以上傳檔案, 於是動手來試試.
新增一個表單, 然後在題型這裡選擇-檔案上傳, 會跳出一個提示:
作答者可將檔案上傳到雲端硬碟
檔案會上傳到表單擁有者的 Google 雲端硬碟。在表單中新增檔案上傳問題後，作答者必須登入 Google 才能回答問題。請務必只與你信任的對象共用這份表單。
看起來可以上傳檔案, 不過需要有 google 帳號且登入 google 帳號的狀況下才能上傳.
而上傳空間也預設總量為 1GB (此限制為1張表單內的使用空間量), 量到後也會停此收集這個表單作答. 網路上查了一下, 原來在 2017 年時, 就有這個功能了, 真是後知後覺, 沒關係, 還是動手來做一下:
https://forms.gle/GhpXvKrUEQEzLQhJ6
應用在做問卷時, 需要拍照, 或是上傳文件, 非常方便實用的一個表單功能.
PS. 用戶上傳的檔案會佔用自己的 google drive 空間, 並且以新開一個目錄的方式來收集檔案. 收集的檔案名稱最後會附加上用戶的google帳號名稱(display name), 雖然會佔用空間, 但也是確保能有效收集到檔案的方式, 在使用上要留意自己的空間是否充足. (如下圖, 擁有者都會是自己)
繼續閱讀:
先來看一下之前寫的:
- Apache與IIS Web Sever URL長度上限 https://diary.tw/archives/1316
- Referer參數的最大長度 https://diary.tw/archives/455
由 browser 的上限來看是 2083, 而由 apache / iis 來看則是 8190 / 4096 兩個等級.
不過無論如何, 這個 url 上限的討論是個很熱門的問題:
https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers
除了 RFC / Browser / Web Server 外, 還多提出了 CDN (其中的 status code 414 (414 URI Too Long, https://tools.ietf.org/html/rfc7231#section-6.5.12) 就是在描述這個:
- Fastly 8Kb
- CloudFront 8Kb
- CloudFlare 32Kb
這個很重要, 因為 CDN 是轉遞內容的重要功能, 不過看起來長度也都放得很寬.
再來看個別瀏覽器利用測試的方式來查看長度:
| Browser | Address bar | document.location or anchor tag |
| Chrome | 32779 | >64k |
| Android | 2192 | >64k |
| Firefox | >64k | >64k |
| Safari | >64k | >64k |
| IE11 | 2047 | 5120 |
| Edge 16 | 2047 | 1024 |
也都有相當的長度.
不過由以上來看, 還是得保守地使用約在 2000 bytes 長度的 url 較為保險.
來寫個中油油價取得.
不過一開始原以為這頁是利用靜態的內容產出的 table:
https://www.cpc.com.tw/historyprice.aspx?n=2890
利用 beautifulsoup 時, 使用 selector 雖然可以找到對應的 element, (table#tbHistoryPrice), 但找不到該 table 以下的 tr, td 對 element, 所以無法透過 select 解析並取出資料.
於是仔細看了一下 html source code, 發現原來只有一個空的 table, 而沒有內容, 而表格內容利用是 javascript 動態生成的, 而資料來源仍為靜態的 javascript 中的變數 (pieSeries), 這樣就好解決了.
分類
好大的big sur
這個版本稱為 big sur 不是沒有道理的, 因為真的很大.
但是也是第一個同時支援 x86-64 / ARM64 處理器的 Mac OS 的版本, 這個版本就是 Mac OS 11的版本了.
https://en.wikipedia.org/wiki/MacOS_Big_Sur
在 2020/11/19 更新到 11.0.1 版本. 這個是為了Apple 自家處理器M1推出來, 無論如何, 這個同時可以用在 intel x86-64 與 ARM64 的版本第一個, 真的很有趣啊.
Apple 官網介紹: https://www.apple.com/tw/macos/big-sur/
相關新聞:
電支條例大修法 立院初審通過！金管會力拼明年上路 https://ec.ltn.com.tw/article/breakingnews/3346687
這個電子支付與電子票證整併的市場需求與管理的專法, 終於進行修法了, 早幾年的支付狀況可以參考:
其中除了第三方支付為經濟部管轄外, 另外的電子支付與電子票證皆為金管會下管理, 相關專法如下:
- 第三方支付服務定型化契約應記載及不得記載事項: https://gcis.nat.gov.tw/elaw/lawDtlAction.do?method=viewLaw&pk=209
- 電子票證發行管理條例: https://law.moj.gov.tw/Hot/AddHotLaw.ashx?pcode=G0380207&cur=Ln&kw=%e9%9b%bb%e5%ad%90%e7%a5%a8%e8%ad%89%e7%99%bc%e8%a1%8c%e7%ae%a1%e7%90%86%e6%a2%9d%e4%be%8b
- 電子支付機構管理條例: https://law.moj.gov.tw/Hot/AddHotLaw.ashx?pcode=G0380237&cur=Ln&kw=%e9%9b%bb%e5%ad%90%e6%94%af%e4%bb%98%e6%a9%9f%e6%a7%8b%e7%ae%a1%e7%90%86%e6%a2%9d%e4%be%8b
由於電子支付與電子票證使用情境已深入一般生活, 轉帳, 交易都有很大的需求與應用情境, 將其整併可以強化跨行(機構)轉帳的便利性外, 還有更多應用可能. 另外像是海外分支點(原銀行業務)的開放, 更可以強化開放支付工具在國際上的應用.
另外一則新聞則是全聯 PX Pay已遞交電子支付申請,
https://www.bnext.com.tw/article/60133/pxmart-px-pay-electronic-payment
看來交易額已可以成形一個夠大的支付工具, 並形成用戶數量夠多, 交易量夠大的單一公司支付工具, 往外走出去是很棒的規畫, 讓更多人用, 更多店家用, 來達成更大的收益.
[2020/12/28 11:32]
繼續閱讀:
這是 2020台灣人工智慧年會, 李明達的演講, 談如何選擇適合的人工智慧演算法, 很值得學習.
[2020台灣人工智慧年會] 如何選擇適合的人工智慧演算法
(引用自: https://www.youtube.com/watch?v=AD7jnsgd5Nk)
這裡有摘要: https://tw.leaderg.com/article/index?sn=11221
看起來日後的人工智慧學習更容易, 更商用, 更方便學習與應用了. 太方便太棒了!
從這裡看到一個科學家新發現:
(source: https://technews.tw/2020/10/20/zeptoseconds-time-light-particle-h2-desy/)
先來看一下仄秒這個單位是 10^-21秒, 而科學家觀測到光子穿越氫分子, 為 247zs, 這個單位真的難以想像的小啊.
來科普一下秒以下的時間單位吧:
| 單位 | 英文名 | 縮寫 | 比例 |
| 秒 | second | s | 1 |
| 毫秒 | millisecond | ms | 10^-3 |
| 微秒 | microsecond | µs | 10^-6 |
| 奈秒 | nanosecond | ns | 10^-9 |
| 皮秒 | picosecond | ps | 10^-12 |
| 飛秒 | femtosecond | fs | 10^-15 |
| 阿秒 | attosecond | as | 10^-18 |
| 仄秒 | zeptosecond | zs | 10^-21 |
這些這麼小的時間精度, 能被觀測到, 科學家們真的太厲害了.