你確定事情真的是這樣嗎 ?

但也就只有一丁點了。
之前幾次我的作法都是第悶蒸完就把粉沖高。
看來有可能是因為這樣，所以導致中間以後（含），都以比較高的流速（低翠取濃度）翠出。
而我今天這樣沖，似乎剛好讓一部份釋放甜味的區段，在最一開始的低水位。所以這次才會出現一點點的甜味。

但中間段的醇度好像因為太早拉高水位，或者我拉高水位的方式有點問題，所以導致口感變得比較清淡。
然後又因為豆子還算新鮮，排氣還算旺盛，所以翠取的時間還是達到了3分鐘。

所以會有一點苦味，並且沒有什麼香氣。

因此，下次的調整方式，至少一定要再調粗研磨度。要能夠讓香氣更出來才行。
而拉高水位的注水量點，需要再等注了更多一些水後，才開始拉高。

這樣調整，應該可以預期開始會有香味出來，不苦，然後假如抓的拉高水位的水量點沒有太少的話，應該可以再有一點甜味出來。

上禮拜在看了那本打造超人大腦那本書後，想要試著在之前寫的side project（筆記app）上面加上這種筆記。
結果在看code重新回想的時候，發現到了可以用decorator抽出一些例外處理的部分。那部分是http.Handler負責做restful note api的部分。

查了好一陣子，查到了golang怎麼寫function 的decorator之後，把幾個坑給補完。終於成功的把看起來有點複雜的code，變簡單了。

然後在今天，再回來看到python的function decorator，忽然開竅了。
我有一些decorator根本就不需要wrap成使用 args,*kwargs 的參數。
直接使用就可以了。

原本是這樣

def page_limit(func):
def wrap(args,*kwargs):
page = args[0].get.GET("page", 0)
if page > 1:
return HttpRequireLogin()
return func(args,*kwargs)

後來改成這樣

def page_limit(func):
def wrap(request):
page = request.get.GET("page", 0)
if page > 1:
return HttpRequireLogin()
return func(request)

改了幾個長這樣的decorator之後，原本一直懊惱的decorator內部實作比較難看懂的問題，解決掉一部份了（原本是向上面那樣，直接用一個變數來取代args[0]。）為什麼不是完全解決呢？因為假如decorator的通用程度更高（參數數量不定），那似乎還是得要繼續使用args,*kwargs的方式。

上面提到的把不是核心的部分抽出來前後的code如下。
原本：
update 定義：75~100行
呼叫：134行

修改成：

定義：55~64行
呼叫：106行
抽出來的decorator: middlewares

少掉了一些例外﹑非核心的判斷處理，核心code的動作就變得很清楚了。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

剛剛看了一下豆子的烘焙日期。記錯了，虎記的豆子只比步昂的豆子早一天烘好而已（之前一直記成比步昂早一個禮拜www）。
這樣的話，應該可以把研磨度拉粗到1zPresso Q2的25格。
星期六沖步昂的耶加雪非，用了25格，就有舒服的香氣還有不少的甜味出現。

假如明天衝出來有足夠的香氣的話，那就應該可以推論出，新鮮的中焙豆子，大概要用到25格粗才OK。