剛好有一些資料打算封存,所以嘗試各種雲端除存服務。
以儲存空間計費 (忽略資料傳輸費用) 的話,由貴到便宜分別是:
原本以為 BackBlaze 沒有亞洲資料中心,傳輸速度會很慢,但一直都有維持在 5 MB/s 以上,還算不錯。
Azure 還沒研究,等下一輪吧
軟體開發、伺服器和生活瑣事
剛好有一些資料打算封存,所以嘗試各種雲端除存服務。
以儲存空間計費 (忽略資料傳輸費用) 的話,由貴到便宜分別是:
原本以為 BackBlaze 沒有亞洲資料中心,傳輸速度會很慢,但一直都有維持在 5 MB/s 以上,還算不錯。
Azure 還沒研究,等下一輪吧
Meilisearch 是一個以 Rust 開發的全文搜尋引擎 (full-text search engine),主打簡單好用、搜尋和回應速度都很快,另外預設就支援多國語言,不需要特別調整設定或安裝擴充套件即可使用。
覺得有趣,去年拿來當作 site project 的一部分研究。當索引檔大小漸漸增加,也開始發現一些問題。
觀察了一下運作的狀況:
在索引檔大小增加以後,增加 threading 和 RAM 對執行效率並沒有顯著的效果,瓶頸看起來是卡在 disk I/O。
手上 VPS 觀察到的 I/O 最大約 200 MB/s,應該就是極限了:
Meilisearch 並不是不能用,這邊還是簡單列幾個優缺點。
優點:
缺點:
Meilisearch 的社群蠻活躍的,歡迎大家參與討論 -> Meilisearch Roadmap
這邊用 PHP 實作,可以自己改成其他程式語言。
主要是使用 \r
來回到行首,然後使用新的文字蓋過原有的文字,就可以出現簡單的圖形變換效果:
$symbol = ['\\', '|', '/', '-']; $count = 0; echo "\n"; while(1) { echo "\rpending ..." . $symbol[$count % 4] ; $count++; sleep(1); }
不知道有沒有什麼其他符號看起來比較清楚的? O_Oa
一般在賣場結帳時,會看到店員翻轉商品並掃描張由直線組成的條碼,掃描完成收銀機便可立即顯示出商品名稱以及售價。近一年因 COVID-19 而要求大家進入公共場所需要掃描的 QR code 也是條碼的一種,只是單位面積可以儲存的資料量更多 (資料密度更高)。以下貼出幾種常見的圖形條碼。
「一維條碼」指的就是這種條碼只由直線組合而成,常見的商品條碼就是條碼的一種。依照不同的檢查碼、線條格式等,還可以細分成很多種,但大致上就是長得像 UPC code 這樣:
由於在相同面積,一條條碼可以儲存的資料有限,所以後來做出了 PDF 417 這種以方格組成的條碼:
接著為了更複雜的需求 (快速辨識圖形方向、容忍變形、容忍圖形毀損等等)、提高資料密度,開始出現了設計不一樣的長形、方形條碼 (二維條碼),最常見的就是 QR code:
再來還有幾個比較少見的圖形條碼,像是 Datamatrix 和 MaxiCode:
在約 15 年前有嘗試想要自己做一個縮網址服務 (現在我做加長網址服務 XD),當時用來產生 string ID 的方法有弱點,被學弟抓出來打爆 (可以被預測下一個產生出來的 ID,然後建立 unliminted redirection)。最近摸到 crunch 這個工具,在重新思考以後,終於搞清楚向 ppt.cc 請教時得到的說明是什麼意思。
先說明有問題的作法,先建立 valid characters list,URL 有部份特出字元是 reserve character (RFC3986),所以像是 ?
、=
、@
等字元有特殊用途不能被拿來當作參數傳遞,然後做「N 進位」轉成 string ID:
<?php $char = ['a', 'b', 'c', '.....', '7', '8', '9', '0'];
例如:數字是 1
時,產生出來的 ID 是 a
、數字是 116
時產生出來的 ID 是 a1
。當時我是依照流水號,所以 ID 是可以被預測的,導致弱點被利用。
當時得到 ptt.cc 的回覆是「先產生完 key 再隨機選取可用的 key」。
這陣子才搞懂這個說明,先用 crunch 之類的工具把所有可用的 string 都先產生出來,然後需要時再隨機選取一個 string 來當作 key/ID 使用。這個作法有些優點:
接下來要傷腦筋的,大概就是怎麼樣有效率的從 DB 隨機取 key 了。
ps. 目前使用 3 個 digits,大概就有 20 多萬個 unique string 可用了,爽。