黑咖啡的創業音符

開箱握咖啡中秋禮盒限量豆 第一次喝到握咖啡是在內湖的實體店，一次的午餐時刻點了一杯火鳳凰＋商業套餐！無論是環境以及精品咖啡主角的甜感酸值掌握都很好！溫溫的喝更明顯的果酸香氣在嘴裡環繞著！對精品咖啡執著的饕客是不能錯過。 想知道 火鳳凰 的發源可以點下去  哥斯大黎加 火鳳凰莊園 再次光顧是信義店，也是個大大的招牌烘豆冠軍，讓我們幾個朋友產生了再次踏入的興趣，一個店長講述了老闆真實的人生，一個對咖啡品質偏執，細膩的工匠精神，2014年烘豆冠軍-賴昱權  2014「WCE世界盃咖啡大賽」世界烘豆冠軍賴昱權導讀 其實我會想要寫這篇簡單的紀錄一下日記是因為，這是我買過以及自己家用烘豆以來咖啡豆開箱香氣最濃郁的一次，滿滿的草莓香！真的太屌了，我真的以為是 草莓 想要一口咬下去的那種感覺，所以才回頭看他的手法到底是甚麼這麼厲害。 咖啡的 二氧化碳浸漬法 中，咖啡櫻桃也像葡萄一樣保持完好無損，在進入密閉罐之前不去果皮果漿，並利用水的浮力去除低密度的 浮豆 (代表內容物不足)，然後以與 厭氧法相同的方式將其添加到帶有單向閥的密封罐 中。 厭氧發酵處理法與二氧化碳浸漬法 我還是很老派的沿用了有誤差值的 指針式溫度計 ，目測看是88度C 標準 V60 錐形濾杯，看看這樣的標準常用濾杯面對此精品是否能有多好的 甜感香氣表現 。 其實經過幾次的操作嘗試，這樣的豆子對我目前V60的器具來說，很明顯不斷水法中心往外繞在緩緩往中心點繞回是無法抓到莓果香氣，實際我也參考了幾個咖啡師對於這類豆性跟V60器具用 多次分段中心注水不往外繞圈 (中心往外小小幅度的一至兩圈)，基本上都是中心點水，如以下小弟的手法，發現這樣的莓果香氣甜感讓我終於有了滿足感。 PS：有咖啡師建議這類果酸香值高的最佳濾杯是 花瓣濾杯 從 花瓣尖到相鄰兩條肋骨的交匯點 ，因爲肋骨做的比較淺，而且肋骨間間距比較大，所以當水位抬升到這段位置時流速會比較慢。從兩條肋骨的交匯點開始，肋骨變得越來越尖，流速也會加快。就整體流速而言會比Hario V60慢，不過這種變速設計優勢在于可玩性，如果想要快流速的話，可以用小水柱緩慢注水，把水位保持在濾杯的下半部分；如果想要偏慢流速的話，可以先用大水流把水位抬升到七，八分滿的位置，試驗各種注水組合正是這種濾杯的好玩之處。 手沖注水手法 20克(小飛馬刻度4) 1:13.5粉水比 88-92度 40-4

  Day 30. 容器小白學習歷程及部落客試金 時間過得好快！轉眼從猶豫是否要再報名自我挑戰，到確定發文的第一天還在擔心文庫內的彈藥存量不多。 一轉眼經歷了兩次中秋與雙十連假，埋首撰寫本次的容器技術文真的需要滿大的意志力與犧牲休閒時光，不過回首過去時間心境上在即將完成的這一刻起是異常的滿足。每一次痛苦的過程，辛苦的挑戰並堅持總是讓人有莫名的開心感。 容器技術真的為了要呈現一篇篇的技術文，要實際輸出才又更深刻的覺得想要學的精通真的需要一股腦的埋頭鑽進容器的世界把自己完全融入，這才能內化成自己的，隨手捻來就是容器經。 自己還是會持續在容器的領域上面精進，這次的手札日記還是讓自己打了一點基礎，也更清楚瞭解這架構的運作全貌，也謝謝一路有在關注或是覺得哪個篇章文章有幫助到自己的IT朋友們，都非常感謝。 以下是從Day1～Day29的技術總集，讓需要的朋友更方便查找 容器故事緣起 Day 1. Docker / K8s 前世今生與所需基礎知識 Day 2. Docker / K8s 求職市場分析 Day 3. Docker / K8s 我們不一樣 Day 4. Docker 與 K8s 具體化口碑優勢，不知道也要背起來 Docker實作預習 Day 5. Docker 燒腦專有名詞與應用場景 Day 6. Docker 架構流程說明 Day 7. Docker 所需收納口袋指令 Docker由淺入深實作 Day 8. Docker Engine on Ubuntu 18.04 安裝示範 Day 9. 好奇心殺死貓，一探究竟Docker info Day 10. Docker Images 深入探討 Day11. 利用 Dockerfile 簡單撰寫自己的映像 Day12. Dockerfile 語法深入探討 Day13. Docker Container 操作日常 Day14. Docker Registry on GCR 實測 Day15. Docker Volume 入門示範 Day16. 簡單備份還原與遷移 Docker 容器 Day17. Docker 外部網路存取實記 Day18. Docker Container 服務互連串接 Day19. Docker 進階網路深入探討(一) Day20. Docker 進階網路深入探討(二) Day21. Docker Com

  Day 29. YAML 描述檔探討 科普YAML 實際上自己也常把YAML與JSON拿來做比較，我這邊非常簡易的分辨一下： YAML本身視為JSON的超集 ，故YAML本身就支援JSON的格式。 實務場景應用上JSON與YAML本身並不是很雷同。 JSON大多用於資料傳輸通訊 YAML大多用於組態設定 所以透過以上區分其實並沒有互相取代的意味，更 凸顯的雙方的共生 行列。 科普YAML維基百科 官網強調YAML並非標註語言，而是一種適用於所有語言，人性化的資料序列標準。講人話 YAML就是一種描述設定的文字檔 格式，讓生為萬物之靈的我們可以清楚了解文字內容所要表達的意思。 科普超集： 如果一個集合S2中的每一個元素都在集合S1中，且集合S1中可能包含S2中没有的元素，則集合S1就是S2的一個超集，反之，S2是S1的子集，而S1是S2的超集。 若S1中一定有S2中没有的元素，则S1是S2的真超集，反之S2是S1的真子集。 [科普JSON、XML、TOML、CSON、YAML差異化]( https://kknews.cc/code/a3ex5av.html   https://kknews.cc/zh-tw/code/a3ex5av.html) docker-compose.yml Docker Compose可讓我們用一個指定採用的描述檔 docker-compose.yml來管理多容 ，預設範本文件是docker-compose.yml，其描述檔就是 採用YAML格式 來做撰寫。 而描述檔中的服務會需要透過 image指令來指定映像 或 透過build搭配Dockerfile来做自動佈建 。 一旦透過build佈建，在Dockerfile中所設置的選項如：CMD，EXPOSE，VOLUME等．． 都是會被自動獲取而無需在docker-compose.yml中重複设置。 我們可以先比較一個個分開的前後端部署的狀態 單身前 使用Dockerfile建立新映像或是到指定的倉庫來抓取後建立所需要的容器，以下為例分別有前後端各一組容器，透過docker run指令來運行，但會需輸入很多次可能是重複性或非重複性的指令才能讓一個完整的應用服務啟動。 前端 docker run --rm -p 8000:8000 --name webapp1.frontend webapp

  GKE部署自己第一個容器實驗 容器部署前有以下幾種方式來指向 Registry API 後建立映像檔 Artifact API Container Registry的進化版 ，可讓貴機構集中 管理容器映像檔和語言套件如：Maven和Npm) 。Artifact Registry與Google Cloud的工具和執行階段完全整合，並支援原生構件通訊協定，因此您可以輕鬆將其與持續整合/持續推送軟體更新工具相互整合，進而設定自動化管道。 想試試通往此隧道 Artifact Registry Artifact已啟用 Cloud Source Repositories API 設計、開發並安全地管理程式碼，還能在功能完善且 可擴充的私人Git存放區輕鬆協作 。此外也能連線至Cloud Build、App Engine和Pub/Sub等其他Google Cloud工具，以及Cloud Monitoring、Cloud Logging等作業套件產品，以 擴展Git工作流程 。 想試試通往此隧道 Cloud Source Repositories Cloud Source Repositories已啟用 Cloud Build API 透過Cloud Build工具來 持續建立，測試及部署，就像是Jenkins ，重點是整合Google GKE自家服務，從映像打包到部署只需有極短秒級到分鐘的時間就可以完成任務，非常高效。 Cloud Build以啟用 Nginx容器服務部署 GKE支援的應用程式部署格式為 Docker ，初次見面來點輕鬆的，以下透過精靈的方式快速體驗在容器叢集環境非常輕易的部署Nginx網頁應用服務 初始我們就透過現有的Nginx容器來作部署示範，如果在上述的Registry或是他也有支援第三方的映像倉庫也可以做指定。環境變數再依據個人需求來做調整，此範例預設值保持空白即可 可以自訂我們的應用程式名稱，另外 預設佈建出來的叢集NameSpace就叫Default ，標籤可以再做增訂 K8s部署要能順利全靠 YAML描述檔 的輸入，這已經是系統貼心的範本可以直接套用，而實際上此檔內容可以大大的學問，可以自行Copy出來做進一步深入的研究或是拿來重新編修成適合自己的再部署到您自己的環境試試 最後到了部署落地階段，因為我只有一組叢集故沒有選擇權，相信未來的生產環境需

  第11屆鐵人主題博客 技能解封一次看INVISIBLE COMPUTING 技能解封初始篇章-分散式阻斷洪流攻擊防禦 (DDOS) 技能解封初始篇章-堡壘前線 (BASTION) 技能解封初始篇章-安全閘門重鎮(NSG & ASG) 技能解封初始篇章-對空對地的坦克巨塔(FIREWALL) 技能解封初始篇章-防網站惡攻的天行者(WAF) 技能解封初始篇章-非法隱身存取(CLOUD APP SECURITY) 技能解封初始篇章-攔截應用服務(APPLICATION PROXY) 技能解封初始篇章-內鬼授權加持(DYNAMIC GROUPS) 技能解封初始篇章-資源環境風險漏洞(CONDITIONAL ACCESS) 技能解封初始篇章-暴力黃袍加身(PRIVILEGED IDENTITY) 技能解封中間章程-角色權力保衛戰(RBAC) 技能解封中間章程-城內防禦機關重啟(AZURE POLICY) 技能解封中間章程-城池間的隱形之眼(AZURE METRICS) 技能解封中間章程-城池間敢死報信者(AZURE ALERT) 技能解封中間章程-城池風險維安御林軍(AZURE SECURITY CENTER) 技能解封中間章程-庇護所疫軍之亂(AZURE ANTI-MALWARE) 技能解封中間章程-場域空間強制掠奪(DISK ENCRYPTION) 技能解封中間章程-庇護所毀損時光回朔(AZURE BACKUP) 技能解封中間章程-狡兔三窟快速戰備(AZURE ASR) 技能解封最終對決-重要機要防竊攻防 (AZURE SQL STRUCTURE SECURITY) 技能解封最終對決-卷軸祕文添加神秘色彩(AZURE STATIC DATA ENCRYPTION) 技能解封最終對決-卷軸解封金鑰重鎮(AZURE KEY VAULT) 搜尋：