by:陳澤榮 (timothychenpc@gmail.com)
日期：0124
改動：
一、構思之後要如何實現提醒功能：
先大概前情提要一下好了，我們的客戶有大概4000筆資料，然後每一筆資料都包含不同部件的上次更換時間，而我們需要針對每一個部件的壽命計算下一次更換的時間，並提前n天（會設定）提醒他。
那怎麼實現每天的通知呢？
（同時也要可以同步在網頁上顯示當天需要更換的）。因為我們的伺服器上線之後會是7*24小時不間斷運作，所以我就想每天伺服器只主動跟數據庫請求兩次更新資料（除非伺服器意外重啟）：
第一次（大概早上1點左右）
第二次（設定的提醒時間前）
第一次主要就是用於顯示到網頁的資料來源，第二次的話是防止第一次獲取的資料在運行的過程中因為某些神奇原因丟失（主要還是要確保
linebot的推送不會受影響啦）*如果有因為特殊原因新增的資料（通過網頁UI，或者後端），則會手動觸發一次更新（聽起來跟我處理settings的方法一樣）
在確定了什麼時間需要去獲取資料，那要怎麼獲取？以及要獲取什麼呢？
我覺得這部分才是真正難的，因為這兩個問題的答案都會因為實現的方法不同而不一樣（然而目前我也不知道方法裡面哪一個比較棒）。
我先說明一下我想做什麼好了，我想在每一次獲取資料的時候就確定
當天需要更換的以及當天需要提醒更換的，也就是說每一次的獲取資料（從資料庫）我都需要做一次針對裡面的一堆時間進行搜索（所以我才盡可能的減少需要重複獲取的次數）。然後目前的兩個方法：
- 把資料庫的所有資料要過來，自己爆搜
(已經差不多完成了)
- 使用資料庫內建的搜索方式進行搜索
使用內建的搜索是因為我覺得畢竟有經過別人的優化，所以速度的話應該會好很多，只是不確定有沒有支援這樣的搜索（因為我需要同時針對多個部件，多組條件進行搜索，所以一般的
.find應該是不行的）。目前的搜索：
以下就是搜索的一些結果
之後的計畫：
- 應該就是試試看是否可以使用內建的方法進行搜索（反正不管怎麼樣都是要把搜索系統改以下），以及完善整個的搜索系統。
- 針對不同搜索方法量化進行測試（包含4000筆資料的壓力測試）
- 使用
APScheduler對伺服器進行定時設定（搜索以及獲取需要提醒的資料等...），然後定時執行
- 想辦法增加程式碼的可讀性（本來想直接用
Blueprint拆分，但是上次試的時候好像遇到了一些不知名的問題），如果實在不行的話，在這次專案之後我可能就會跳槽去用Django了
心得：
今天在寫code的時候（其實這段時間都有），腦袋就一直想到一句話
“獨學無友，則孤陋而難成。”。仔細想了以下，似乎確實是這樣，因為目前身邊會寫後端的人真的不多，某方面也導致，我過於執著於鑽研自己的東西，自己去研究。我覺得這裡的“難成”可能更多的是在說，因為沒有跟別人有這方面的討論，可能就會因此喪失很多可能的想法，以及很可能就會在研究過後，因為自己目前的想法可以解決目前的問題，所以就直接結案，導致很可能在後端的思維上很難有進步（或者說因為沒有去了解別人在從事這方面的想法，或者沒有去看別人的code導致滿足於現在可能不完美的解決方案）。
所以我覺得之後可能應該安排一些參訪（實際的去了解產業上或者其他人在這方面的想法），否則可能就會卡在
“學”而不是“精進”然後就是我覺得之後還是有必要找個時間學一下Django和SQL，以及其他的數據庫類型，因為目前就是處於一個遇事不決Flask+Mongodb的情況（感覺手牌不是很多，能做的選擇也不會太多）
然後我覺得我們可能要提前進入用Git進行團隊的版本管理了（之前都是個人使用），因為這兩天，出現太多前端之間用傳統的方式要同步版本出現的問題（像是一直在群組傳zip還有就是每一個人改完之後要同步到另一個人都相當的麻煩）。然而關於git的團隊管理這部分我也不是很熟（可能要加速學習以下）
然後就在寫這個心得的剛剛，這台mac好像被我玩到死當了（小尷尬😅
學長推薦了notion的blog功能，似乎比sharelink好用，但是目前blog首頁才弄到一半，所以目前還是先以sharelink的方式跟大家去分享了。