水林泰平花生醬: 涼拌小黃瓜雞絲

在厚生市集買了好幾次菜囉!
對水林泰平花生醬感到十分好奇, 新鮮現磨的手工花生醬到底有多厲害勒!?
上禮拜為了要湊到免運費就順手定了.

到貨後立馬烤了片土司, 開罐後花生醬真是超香的(暈眩)
花生醬本身沒加糖, 我就直接撒了點糖(細粒冰糖)上去
相當好吃, 但是我上次吃到花生醬已經不知道是多久前了, 無從比較啊XD


之後發現它的保存期限相當短
於是就驚慌的搜尋起有用到花生醬的食譜
發現小小米桶的麻將棒棒雞絲看起來相當誘人, 就來試試囉!


完全照著做就挺成功的.
為了要快速消耗花生醬我完全沒用芝麻醬(其實家裡也沒有啦XD)
雞絲有特別撕大塊一點吃起來比較過癮
感覺雞絲有點乾乾的就把它泡在蒸出來的雞汁裡放涼覺得效果還不錯
而且老乾媽辣椒的確是有必要, 畫龍點睛啊!


剩下的醬汁用醬油跟醋稀釋(也加強鹹度酸度)後就拿來拌麵也很好吃哦!

Snowboard再體驗, 迷人的小村莊 - 野澤溫泉, 開滑囉! 大雪下不停~

嘗試在今年開滑之前把去年欠的補完啊哈哈XD

抵達野澤的隔天終於要開滑了(舞動)
一早就下著毛毛雪(有這種用法嗎!!?)
吃完早餐集合完畢剛要出門就看到已經有早起鳥兒滑完收工了~

走啊走到了終於到了電扶梯的起點,
沒圖沒真相XD
很類似香港中環到半山的電扶梯的感覺, 不過不是階梯的
經過了不算短的距離之後終於到達雪場囉!
我們先到裝備出租店面搞定雪板鞋子等等東西.
再來熱身完畢就開滑囉!
早上我們都待在日影(HIKAGE)滑道,
馬克教練帶著大家滑瞭解我們的程度同時糾正跑掉的動作,
時隔一年連下纜車都好緊張! 深怕會跌倒害纜車停住那超丟臉搭.

雪越下越大,

中午我們就在雪場入口附近的餐廳吃吃,
毫不猶豫就選擇了摩斯XD

下午我們搭日影Gondola滑天堂(PARADISE)滑道
超大雪所以也沒拍照了
總之就是持續練習S-turn為明天的SKYLINE作準備啦!


用晚餐照結尾
這是一開始上桌的畫面之後又來的炸物等等東西吃好飽啊!


[野澤系列]
- Snowboard再體驗, 迷人的小村莊 - 野澤溫泉

LADURÉE百年糕點老舖的傳奇配方: 焦糖布丁

身為布丁控, 焦糖布丁是一直我很想嘗試自己做的甜點,
但都處在萬事俱備只欠東風(明明就只是懶)的狀態.
在2014年的最後一天晚上,
發現好不容易搶到的初鹿鮮乳再幾個小時就要過期.
就憑著一股衝勁開工囉!


主要是參考松露玫瑰部落格上貼的LADURÉE食譜.

照著做大致上算是挺順利, 只有幾個步驟小小卡關,
一開始取香草籽放到牛奶鮮奶油混合液稍微加熱後,
香草籽始終無法均勻的分散開來, 造成最後的成品香草籽顆粒太大不好看.
不知道這步驟有沒有什麼訣竅.
另外是不太明白做焦糖最後鍋子離火放到冷水中,
焦糖加熱水攪拌是為了什麼.
我加熱水完全攪不動 囧
只好再放回爐火上重新回到焦糖狀態,
但這次就直接把焦糖倒入小容器中冷卻了, 參不透其中的奧祕啊~

這個食譜做出來的焦糖布丁超厲害啊!
布丁非常的綿密柔滑, 吃第一口的時候我整個人有點嚇到.

最後的叮嚀就是, 把布丁倒出來的時候不要偷懶啊! 用的刀要夠利夠薄.
要不然邊邊就會跟下面這張圖一樣像是狗啃搭~

Amazon DynamoDB - Global Secondary Index (GSI)

[什麼是GSI]
Global Secondary Index跟Local Secondary Index很類似,
都是讓你可以在原有的table上選擇另一組key來幫助資料查詢.
不過GSI的彈性更大, Hash key可以是任意的attribute, 也可以跟原本的table的schema不同.
LSI只能用在原本是Hash-Range key的table,
GSI則是Hash/Hash-Range key都可以, 其所建立的index也不一定要有Range key.
但還是只能選擇單一值的attribute當key.

[對throughput的影響]
與LSI不同, GSI並不會佔用原本table的throughput,
而是需要另外指定專屬於那個index的throughput.
因為我們並不會直接寫入資料到GSI, 而是在我們新增修改刪除原始table的時候,由DynamoDB主動更新GSI的資料.
所以就是用更新的頻率來預估計寫入的throughput,
讀取的throughput就是看你的使用情境
另外, 讀取GSI的資料只能是eventually consistent哦!

ref:
- Global Secondary Index

Amazon DynamoDB:
- Local Secondary Index

Amazon DynamoDB - Local Secondary Index (LSI)

在某些情況下, 我們所定義的(Hash/Hash-Range)key並不能滿足所有查詢資料的使用情境,
這時候我們可能會利用Query加上特定的filter,或是利用Scan來找到符合的資料,
但這兩種方法不僅沒有效率(不能保證幾次來回才能拿到所有結果)我們也難以掌握需要消耗多少throughput
我們也可以用額外的table記錄相同的資料但選擇不同的key來滿足各種查詢情境,
但是要維持每個寫入都要完整更新到各個table並不是件容易的事.

為了解決這個問題, DynamoDB提供了Local Secondary Index(LSI), 其實已經推出好一段時間囉XD

[什麼是LSI]
在原本的Hash-Range key之外, 能夠利用原本的Hash key搭配其他的attribute作為新的Hash-Range key來幫助各種可能發生的查詢.
- 選擇的attribute必須是單一值不能是集合
- 此attribute的值不需要是唯一
- 寫入還是針對原本的Hash-Range key, DynamoDB會根據設定更新LSI的資料

[注意事項]
- 一個table最多只能設定五組LSI
- 可以選擇哪些其他的attribute要一起被複製進LSI(原本的Range key一定會被加進去)
- 同一個Hash key底下最多只能掛10GB的資料量, 所以得要在便利性以及資料大小間取得平衡

[對throughput的影響]
- 對LSI的讀寫是消耗整個table的throughput
- 除了10GB的限制會讓我們需要取捨要複製哪些attribute進LSI, 另外要考慮的就是資料越大讀寫時需要的throughput就越大啦
- 如果寫入會影響到LSI的資料, 則會需要消耗額外的throughput:新增,更新(刪除再新增),刪除


ref:
- Local Secondary Indexes