覺得公視新聞實驗室這集整理的蠻清楚的。
影響人判斷真假訊息有幾個要素：
- 真實偏誤
- 記憶與知識
- 情緒
現在不少文章、影片為了流量 (?) 內容都刻意做的比較偏激，容易造成判斷錯誤，要多注意不要被情緒影響。
ps. 影片前 30 秒很讚 XD
Laravel 立即 dispatch jobs 的方法
在 Laravel Queue 的文件中，要 dispatch job 到 queue 中，語法如下：
MyJob::dispatch($data);
如果有注意的話，這段執行以後，job 並不會馬上進 queue，而是會先得到一個 PendingDispatch 物件。
由網路上的說明 PendingDispatch 物件，會在 response 完成、程式正常結束時，才會觸發並將 job 放進 queue。
若要在 Laravel Tinker 或是 console 中，不等待、直接將 job 放進 queue，則語法須改為下方所示：
$job = new MyJob($data);
app(\Illuminate\Contracts\Bus\Dispatcher::class)
->dispatch($job);
將檔案複製到 AWS S3 並設定為公開讀取
bucket 預設為公開，但檔案上傳到 bucket 上預設並不會是公開的。
可以在上傳檔案時指定 --acl 來設定 object 的權限：
aws s3 cp --recursive files/ s3://my-bucket/files/ --acl public-readaws s3 sync files s3://my-bucket/files --acl public-readMeilisearch 建立索引遇到的瓶頸
Meilisearch 是一個以 Rust 開發的全文搜尋引擎 (full-text search engine)，主打簡單好用、搜尋和回應速度都很快，另外預設就支援多國語言，不需要特別調整設定或安裝擴充套件即可使用。
覺得有趣，去年拿來當作 site project 的一部分研究。當索引檔大小漸漸增加，也開始發現一些問題。
觀察了一下運作的狀況：
- 索引大小約 1 GB 時，使用 1 thread + 1 GB RAM，新增資料約 3 秒
- 索引大小在 5 GB 時，使用 4 thread + 2 GB RAM，新增資料至少 15 秒起跳
在索引檔大小增加以後，增加 threading 和 RAM 對執行效率並沒有顯著的效果，瓶頸看起來是卡在 disk I/O。
手上 VPS 觀察到的 I/O 最大約 200 MB/s，應該就是極限了：
Meilisearch 並不是不能用，這邊還是簡單列幾個優缺點。
優點：
- 就一個執行檔而已，不用下參數就可以正常運作
- 走 RESTful API，curl 就可以操作。因為簡單，所以幾乎這種程式語言已都有 API 可用。
- document based data，不需要事先定義 field / column (我覺得這也可以算是一個缺點)
- 隨時調整 searchable / sortable / displayable doument field
- 內建 dump & snapshot
缺點：
- 覺得算是一個迭代速度蠻快的專案，所以文件沒有很完整 (或說明不好找)
- 透過 master key 和 API key 來限制使用、操作，略顯不足
- 部份覺得蠻重要的功能尚在開發中，例如透過 rank 來排序之類的
- 查詢功能、查詢結果列表有一些限制，但可以透過其他功能來避免 (known limitations)
Meilisearch 的社群蠻活躍的，歡迎大家參與討論 -> Meilisearch Roadmap
自訂等待的動畫示意符號
這邊用 PHP 實作，可以自己改成其他程式語言。
主要是使用 \r 來回到行首，然後使用新的文字蓋過原有的文字，就可以出現簡單的圖形變換效果：
$symbol = ['\\', '|', '/', '-'];
$count = 0;
echo "\n";
while(1) {
echo "\rpending ..." . $symbol[$count % 4] ;
$count++;
sleep(1);
}
不知道有沒有什麼其他符號看起來比較清楚的？ O_Oa