retrive footprint and calculate carbon-footprint

[ShanWei-Ch]

https://blog.zerozero.com.tw/30598/%E9%81%B8%E5%B0%8D%E4%BA%A4%E9%80%9A%E5%B7%A5%E5%85%B7%EF%BC%8C%E7%A2%B3%E6%8E%92%E6%94%BE%E7%9F%A5%E5%A4%9A%E5%B0%91%EF%BC%9F/

I used the data above, but where should I put the function below?

def calculate_emission(method, distance)

[kuanwen-C]

我先寫好tasks.py大概的架構，你再加到裡面

[kuanwen-C]

這個牽涉到我們計算碳足跡功能trigger的方式， 這個功能可以約個討論 再來建

想了一下，這個功能感覺有幾個呈現的方式： 1.串成一個按鈕，讓使用者自己按去計算 2.使用者輸入完哩程資料自動計算然後存回去欄位 3.產生report的時候，再後台計算直接用不存回去資料庫 目前感覺1比較不合理，2或3可以討論看看

cc. @nush-cc

[nush-cc]

我覺得可以用2+3，生成報告時再計算碳足跡可以減少程式負擔，計算完後再存回資料庫，可以完成我們預設的排名功能

[nush-cc]

食物的碳足跡計算應該也要一起處理，上次教授說的那個部分

[kuanwen-C]

那我感覺有兩個要處理 1.感覺食物可以先粗略分成蔬菜,肉類,之類的，可能需要參考食物那邊的type一起設計選項 2.admin碳足跡那個欄位要改成readonly不能手動修改，然後一率在產生報表的時候做更新

剛剛有想到的一個問題（承2.) 因為既然是產報表的時候trigger，我們就要限制產報表的時間點還有計算的時間範圍，避免重複計算更新已經計算過的碳足跡： 例如，對於使用者Ａ有以下幾個footprint紀錄： 情況1.沒有限制，使者可以隨時觸發報表 5/30 5/31 6/1 6/2 如過使用者在5/31觸發報表，那5/30,5/31這兩個已經算過，6/2又觸發一次，那5/30. 5/31就是重複算過的

雖然說重複算重複更新也沒差，但假如使用者紀錄多了，重複不必要的計算跟更新對程式就是loading，所以可能需要讓程式自動在月底之類的觸發報表，然後算的就是當月的紀錄，這樣也蠻符合原本月報表的概念

[kuanwen-C]

那我感覺有兩個要處理 1.感覺食物可以先粗略分成蔬菜,肉類,之類的，可能需要參考食物那邊的type一起設計選項 2.admin碳足跡那個欄位要改成readonly不能手動修改，然後一率在產生報表的時候做更新

剛剛有想到的一個問題（承2.) 因為既然是產報表的時候trigger，我們就要限制產報表的時間點還有計算的時間範圍，避免重複計算更新已經計算過的碳足跡： 例如，對於使用者Ａ有以下幾個footprint紀錄： 情況1.沒有限制，使者可以隨時觸發報表 5/30 5/31 6/1 6/2 如過使用者在5/31觸發報表，那5/30,5/31這兩個已經算過，6/2又觸發一次，那5/30. 5/31就是重複算過的

雖然說重複算重複更新也沒差，但假如使用者紀錄多了，重複不必要的計算跟更新對程式就是loading，所以可能需要讓程式自動在月底之類的觸發報表，然後算的就是當月的紀錄，這樣也蠻符合原本月報表的概念

不對，感覺這樣設計彈性也太少，不是很好的設計，感覺不用這樣複雜，可以簡單變成這樣： 使用者可以隨時觸發報表，但使用者要輸入期望報表開始與結束的日期，等於說可以掉過去任何一段時間的資料分析，不過我們可以給資料加上一個標籤，紀錄這個算過沒有，算過就不重複更新 加標籤可以： 取出使用者指定時間區間的資料之後，先判斷碳足跡欄位是否為空值，如果是空值才最後續計算，如果非空值則跳過

[kuanwen-C]

如果是

那我感覺有兩個要處理 1.感覺食物可以先粗略分成蔬菜,肉類,之類的，可能需要參考食物那邊的type一起設計選項 2.admin碳足跡那個欄位要改成readonly不能手動修改，然後一率在產生報表的時候做更新 剛剛有想到的一個問題（承2.) 因為既然是產報表的時候trigger，我們就要限制產報表的時間點還有計算的時間範圍，避免重複計算更新已經計算過的碳足跡： 例如，對於使用者Ａ有以下幾個footprint紀錄： 情況1.沒有限制，使者可以隨時觸發報表 5/30 5/31 6/1 6/2 如過使用者在5/31觸發報表，那5/30,5/31這兩個已經算過，6/2又觸發一次，那5/30. 5/31就是重複算過的 雖然說重複算重複更新也沒差，但假如使用者紀錄多了，重複不必要的計算跟更新對程式就是loading，所以可能需要讓程式自動在月底之類的觸發報表，然後算的就是當月的紀錄，這樣也蠻符合原本月報表的概念

不對，感覺這樣設計彈性也太少，不是很好的設計，感覺可以變成這樣： 使用者可以隨時觸發報表，但使用者要輸入期望報表開始與結束的日期，等於說可以掉過去任何一段時間的資料分析，不過我們可以給資料加上一個標籤，紀錄這個算過沒有，算過就不重複更新 加標籤可以： 取出使用者指定時間區間的資料之後，先判斷碳足跡欄位是否為空值，如果是空值才最後續計算，如果非空值則跳過

@ShanWei-Ch 如過是這個做法，那應該會在ECO開一個產生報表的task，之後更新的功能可以放這邊，這部分我會先寫主功能，這樣你會比較有方向

[nush-cc]

那我感覺有兩個要處理 1.感覺食物可以先粗略分成蔬菜,肉類,之類的，可能需要參考食物那邊的type一起設計選項 2.admin碳足跡那個欄位要改成readonly不能手動修改，然後一率在產生報表的時候做更新 剛剛有想到的一個問題（承2.) 因為既然是產報表的時候trigger，我們就要限制產報表的時間點還有計算的時間範圍，避免重複計算更新已經計算過的碳足跡： 例如，對於使用者Ａ有以下幾個footprint紀錄： 情況1.沒有限制，使者可以隨時觸發報表 5/30 5/31 6/1 6/2 如過使用者在5/31觸發報表，那5/30,5/31這兩個已經算過，6/2又觸發一次，那5/30. 5/31就是重複算過的 雖然說重複算重複更新也沒差，但假如使用者紀錄多了，重複不必要的計算跟更新對程式就是loading，所以可能需要讓程式自動在月底之類的觸發報表，然後算的就是當月的紀錄，這樣也蠻符合原本月報表的概念

不對，感覺這樣設計彈性也太少，不是很好的設計，感覺不用這樣複雜，可以簡單變成這樣： 使用者可以隨時觸發報表，但使用者要輸入期望報表開始與結束的日期，等於說可以掉過去任何一段時間的資料分析，不過我們可以給資料加上一個標籤，紀錄這個算過沒有，算過就不重複更新 加標籤可以： 取出使用者指定時間區間的資料之後，先判斷碳足跡欄位是否為空值，如果是空值才最後續計算，如果非空值則跳過

這做法不錯 透過使用者自行給時間 加已計算/未計算的label 在database中判斷是否計算過 👍 nice work!

[kuanwen-C]

那我感覺有兩個要處理 1.感覺食物可以先粗略分成蔬菜,肉類,之類的，可能需要參考食物那邊的type一起設計選項 2.admin碳足跡那個欄位要改成readonly不能手動修改，然後一率在產生報表的時候做更新 剛剛有想到的一個問題（承2.) 因為既然是產報表的時候trigger，我們就要限制產報表的時間點還有計算的時間範圍，避免重複計算更新已經計算過的碳足跡： 例如，對於使用者Ａ有以下幾個footprint紀錄： 情況1.沒有限制，使者可以隨時觸發報表 5/30 5/31 6/1 6/2 如過使用者在5/31觸發報表，那5/30,5/31這兩個已經算過，6/2又觸發一次，那5/30. 5/31就是重複算過的 雖然說重複算重複更新也沒差，但假如使用者紀錄多了，重複不必要的計算跟更新對程式就是loading，所以可能需要讓程式自動在月底之類的觸發報表，然後算的就是當月的紀錄，這樣也蠻符合原本月報表的概念

不對，感覺這樣設計彈性也太少，不是很好的設計，感覺不用這樣複雜，可以簡單變成這樣： 使用者可以隨時觸發報表，但使用者要輸入期望報表開始與結束的日期，等於說可以掉過去任何一段時間的資料分析，不過我們可以給資料加上一個標籤，紀錄這個算過沒有，算過就不重複更新 加標籤可以： 取出使用者指定時間區間的資料之後，先判斷碳足跡欄位是否為空值，如果是空值才最後續計算，如果非空值則跳過

這做法不錯 透過使用者自行給時間 加已計算/未計算的label 在database中判斷是否計算過 👍 nice work!

label我在想要不要加，在想可以query完直接判斷就好，加了label除了會多了欄位空間，還會增加access DB的時間，之後還是會有一次if else判斷，所以感覺可以每次query完再判斷就好

[nush-cc]

那我感覺有兩個要處理 1.感覺食物可以先粗略分成蔬菜,肉類,之類的，可能需要參考食物那邊的type一起設計選項 2.admin碳足跡那個欄位要改成readonly不能手動修改，然後一率在產生報表的時候做更新 剛剛有想到的一個問題（承2.) 因為既然是產報表的時候trigger，我們就要限制產報表的時間點還有計算的時間範圍，避免重複計算更新已經計算過的碳足跡： 例如，對於使用者Ａ有以下幾個footprint紀錄： 情況1.沒有限制，使者可以隨時觸發報表 5/30 5/31 6/1 6/2 如過使用者在5/31觸發報表，那5/30,5/31這兩個已經算過，6/2又觸發一次，那5/30. 5/31就是重複算過的 雖然說重複算重複更新也沒差，但假如使用者紀錄多了，重複不必要的計算跟更新對程式就是loading，所以可能需要讓程式自動在月底之類的觸發報表，然後算的就是當月的紀錄，這樣也蠻符合原本月報表的概念

不對，感覺這樣設計彈性也太少，不是很好的設計，感覺不用這樣複雜，可以簡單變成這樣： 使用者可以隨時觸發報表，但使用者要輸入期望報表開始與結束的日期，等於說可以掉過去任何一段時間的資料分析，不過我們可以給資料加上一個標籤，紀錄這個算過沒有，算過就不重複更新 加標籤可以： 取出使用者指定時間區間的資料之後，先判斷碳足跡欄位是否為空值，如果是空值才最後續計算，如果非空值則跳過

這做法不錯 透過使用者自行給時間 加已計算/未計算的label 在database中判斷是否計算過 👍 nice work!

label我在想要不要加，在想可以query完直接判斷就好，加了label除了會多了欄位空間，還會增加access DB的時間，之後還是會有一次if else判斷，所以感覺可以每次query完再判斷就好

ok, sounds good

[ShanWei-Ch]

如果是

那我感覺有兩個要處理 1.感覺食物可以先粗略分成蔬菜,肉類,之類的，可能需要參考食物那邊的type一起設計選項 2.admin碳足跡那個欄位要改成readonly不能手動修改，然後一率在產生報表的時候做更新 剛剛有想到的一個問題（承2.) 因為既然是產報表的時候trigger，我們就要限制產報表的時間點還有計算的時間範圍，避免重複計算更新已經計算過的碳足跡： 例如，對於使用者Ａ有以下幾個footprint紀錄： 情況1.沒有限制，使者可以隨時觸發報表 5/30 5/31 6/1 6/2 如過使用者在5/31觸發報表，那5/30,5/31這兩個已經算過，6/2又觸發一次，那5/30. 5/31就是重複算過的 雖然說重複算重複更新也沒差，但假如使用者紀錄多了，重複不必要的計算跟更新對程式就是loading，所以可能需要讓程式自動在月底之類的觸發報表，然後算的就是當月的紀錄，這樣也蠻符合原本月報表的概念

不對，感覺這樣設計彈性也太少，不是很好的設計，感覺可以變成這樣： 使用者可以隨時觸發報表，但使用者要輸入期望報表開始與結束的日期，等於說可以掉過去任何一段時間的資料分析，不過我們可以給資料加上一個標籤，紀錄這個算過沒有，算過就不重複更新 加標籤可以： 取出使用者指定時間區間的資料之後，先判斷碳足跡欄位是否為空值，如果是空值才最後續計算，如果非空值則跳過

@ShanWei-Ch 如過是這個做法，那應該會在ECO開一個產生報表的task，之後更新的功能可以放這邊，這部分我會先寫主功能，這樣你會比較有方向

收到

[ShanWei-Ch]

那我感覺有兩個要處理 1.感覺食物可以先粗略分成蔬菜,肉類,之類的，可能需要參考食物那邊的type一起設計選項 2.admin碳足跡那個欄位要改成readonly不能手動修改，然後一率在產生報表的時候做更新

剛剛有想到的一個問題（承2.) 因為既然是產報表的時候trigger，我們就要限制產報表的時間點還有計算的時間範圍，避免重複計算更新已經計算過的碳足跡： 例如，對於使用者Ａ有以下幾個footprint紀錄： 情況1.沒有限制，使者可以隨時觸發報表 5/30 5/31 6/1 6/2 如過使用者在5/31觸發報表，那5/30,5/31這兩個已經算過，6/2又觸發一次，那5/30. 5/31就是重複算過的

雖然說重複算重複更新也沒差，但假如使用者紀錄多了，重複不必要的計算跟更新對程式就是loading，所以可能需要讓程式自動在月底之類的觸發報表，然後算的就是當月的紀錄，這樣也蠻符合原本月報表的概念

https://www.greenpeace.org/taiwan/update/18386/%E6%88%91%E5%80%91%E5%90%83%E7%9A%84%E9%A3%9F%E7%89%A9%E5%92%8C%E6%B0%A3%E5%80%99%E6%9C%89%E9%97%9C%EF%BC%9F%E9%A3%9F%E7%89%A9%E7%A2%B3%E6%8E%92%E6%94%BE%E4%B9%8B%E7%8E%8B%E6%98%AF%E2%8B%AF/ 食物的碳足跡計算參考這的圖表感覺可行，提供使用者選擇再進行計算碳足跡，可能我再加一個 def food_calculate_emission(food_type, grams)