從昨天的結果我們看到其實每天的差異不大，但確實這些微小的差異，與先前我們對於餐廳工作量的假設是吻合的。

故我們仍然會以算術平均數當作預測基準。

進一步實作之前，讓我們處理一下目前程式最後顯示時間的方式：

轉換平均數為時間格式

為了要讓結果顯示成時間，而非 time_in_minutes，我們需要寫一個 function 再轉換回來：

def convert_int_to_time(mean: float):
    rounded_number = round(mean)
    hours = round(rounded_number/60)
    mins = rounded_number - (hours * 60)
    # if hours is rounded up
    if (mins < 0):
        mins = mins+60
        hours = hours - 1
    time_str = f"{hours}:{mins}"
    return time_str

讓我們建立另外兩個變數來存轉換過的值：

day_mean_time_format = convert_int_to_time(day_mean)
night_mean_time_format = night_mean.map(convert_int_to_time)

其中 night_mean 雖然型別是 pandas 的 Series 而非單純 list of float，仍可使用以上轉換的 function 處理。

讓我們看一下轉換後的成果：

是不是有比較好看呀～

選擇通知方式

讓我們回顧一下 Day 03 提到的專案需求：

1. 希望可以在關門前，可能前十分鐘，透過某個平台發出一個推播通知，告訴我可能樓下馬上準備要關門了
2. 希望預測準確率可以超過 7 成，不會有太多失誤沒有預測到或是預測遲到的情形
3. 可以在不斷累積新資料的同時，加強準確率
4. 如果可以，會希望有一個界面，可以快速增加開門聲的記錄

以下逐一分析目前需求達成的狀況：

1. 需求 1：目前已有預測的時間了，但缺少平台。
2. 需求 2：需要完成才能驗收，在鐵人賽剩餘的期間可能無法蒐集足夠數據確認準確率。
3. 需求 3：依照 Day 21 的結論，會同時記錄實際發生時間與預測值的誤差作為後續優化的依據。
4. 需求 4：或許可以跟需求 1 一起處理。

通知平台選擇

筆者對於通知平台有以下幾種想像：

1. Google 日曆的事件通知
   1. 優：較簡單，且不論是使用何種裝置都可以看到。
   2. 劣：只能回歸土法煉鋼的方法記錄來達成需求 4，並且要進一步想辦法兼顧需求 3 額外所需要的欄位。
2. LINE 聊天機器人
   1. 優：有建置以 cronjob 發出通知的 line bot 經驗。
   2. 劣：平常社交軟體習慣開啟勿擾或不顯示通知，故推知較不易收到。其他種類的 bot 也會有同樣問題。
3. Mobile App
   1. 優：可以與社交軟體區隔，通知的顯示方式與權限可以獨立。
   2. 劣：只有稍微起過 React Native 的 hello world 專案。

經過思索，筆者決定挑戰方案三，嘗試在剩下的幾天內寫出一個 mobile app，並且搭配 fallback 的方案：如果無法順利完成，就使用方案一。

今天收工！