Richard Sutton評論LLM

 LLM

最近幾年大語言模型 (LLM; Large Language Model)已經風靡了世界，無論各行各業都想盡辦法要跟LLM沾上邊。但是，LLM真的是未來發展的聖杯嗎？

最近，強化學習之父Richard Sutton跳出來提到LLM是死路一條 (LLMs are a dead end)。圖靈獎楊立昆(LeCun Yann)，深度學習的先驅、CNN的重要發明者，也有相同的見解

Richard Sutton認為強化學習是著重於理解你的世界；LLM則是著重在學習模仿人類。Sutton認為智慧是在理解與行動，而LLM則是卡在模仿這一層。他認為LLM有三個致命的缺陷：

• LLM缺乏真正的世界模型
  預測人會說什麼，與預測世界會發生什麼，是完全不同的兩件事
  例如一個燒開的熱水壺，LLM中知道「燙」、「別碰」，但不知道碰觸與燙傷之間的因果關係，沒有世界中的運作邏輯
• LLM沒有Ground Truth
  沒有正確答案的定義，因此沒有回饋給LLM來進行修正改進
  例如打乒乓球的電玩，將球回擊就得分，沒接到球就失分，正確的定義很簡單且明確，因此就很容易進行訓練、模型也能調整其策略；LLM在生成的時候，並沒有正確的概念，例如要求生成提升注意力的文章，很難有標準答案來判斷其生成的內容對錯，因此很難讓模型可以精進
• LLM沒辦法從經驗中學習
  人類的學習是透過預期與實踐偏差來調整認知
  例如今天下雨但沒有帶傘，多數人便會在未來關注氣象預報來決定是否帶傘；但LLM缺乏這樣的適應性(adaption)
  另一個例子是你問LLM把冰塊放進微波爐會怎樣，LLM會回答你冰塊會融化。但如果經過5分鐘還沒完全融化，人多半會修正說微波爐沒有啟動，或是功率太低，但下次你問LLM，他還是回答會融化，而不會從上次的經驗來學習

Sutton認為目標是智慧的本質。沒有目標的系統只是一個行為系統，不是智慧系統。有人反駁LLM也有目標，預測下一個token就是他的目標。Sutton解釋LLM沒有主動實現某個目標的動力，只是執行預設的計算任務

Sutton提出了經驗學習範式(experiential paradigm)概念。核心是一個簡單且強大的感知、行動、獎勵 (Observation, Action, Reward)的循環。智慧就是這個flow不斷循環，不斷調整行動來增加獎勵

這個paradigm與LLM的差別在於學習的來源

• LLM學習的來源是文件網頁，是間接的
• 經驗學習的來源是與系統與世界互動的，是直接的

Sutton舉嬰兒為例，認為嬰兒是透過try-n-error來學習，而不是單純的模仿。例如嬰兒碰觸玩具，而玩具發出聲音，嬰兒便會嘗試再碰觸玩具來驗證是否仍發出聲音。這就是一個observation-action-reward的循環。而現今的學校教育，是一種訓練而不是學習。他還舉例松鼠不上學，但透過與世界的互動，也可以知道怎麼找食物、如何躲避天敵、如何繁衍。

Sutton提出了Temporal difference (TD) learning，認為智慧系統是由四個元件組合而成：

• 策略 (Policy)
  當前的情境下應該做什麼，從狀態到行動的映射
  例如行進的前方有一扇門，那應該要想辦法打該這扇門
  好的策略應該要能泛化，就是能處理沒見過的新情境，例如開門方式有些推，有些是拉，有些是側拉
• 價值函數 (Value Function)
  TD學習核心作用是用來評估當前狀態的好壞，作為策略調整的依據
  例如下棋時，下在A位與B位，何者贏棋的機會較高
  TD的價值評估的是長期收益，而非短期收益，依據當前預測與未來實際結果的差異來修正評估
• 感知 (Perception)
  將雜亂的感知數據，整理為有意義的內部表示
  例如感知到紅色、圓形、有斑點的物體，感知元件會將他整合，判別為狀似蘋果的內部表示，方便策略與價值函數來作出反應。這是與世界互動的第一線
• 世界轉換模型 (Transition Model)
  負責預測行動會帶來的狀態變化，理解因果關係
  例如知道按下開關燈會亮
  除了物理規律，此模型還包含抽象規律 。這個模型不僅僅是從獎勵學習來的，而更是觀察行動與結果的對應關係中獲得

LeCun Yann則提出了JEPA(Joint Embedding Predictive Architecture)

Sutton認為LLM依賴人類創作的文件，那些是人對世界的描述，而非對世界本身的經驗。即使這些文件可以詳述人類的經驗，那也只是讓LLM達到local optima，而非global optima，從而失去真正通用的方法

除了上述的缺陷，Sutton指出LLM另一個大問題：泛化能力差
泛化指的是在一個任務學習到的知識，映射到另一個任務的能力。當前泛化的問題有兩方面

• 災難性遺忘(Catastrophic Forgotting)
  當訓練新事物時，會遺忘掉所有的就事物
• 缺乏自動化的泛化機制
  深度學習依賴梯度下降來優化模型參數，但無法歸納出新規律來應對新場景
  好的泛化可以找出解決問題的多種方法，且能依照context來選擇最優的方法 (note: 就如Grand Truth知道何者為優，何者適合)
  世界太大太複雜，不可能將所有的cases都納入訓練，因此需要系統能自動且持續的學習

另外，LLM還有一個問題，就是學習的頻寬不只來自於獎勵，更來自於感知數據。透過整合所有的感知訊號，來建構對世界的理解。人類是動物，如果能了解動物的智慧、了解松鼠的智慧，就可以了解AGI。

Sutton還提出了宇宙演化的四階段

References:

• https://www.youtube.com/watch?v=RLR4OpetiEc

雜記

價值的多寡，來自於是否放對了地方

０放在分子，它就是０，但如果放在分母，就會變成無限大

◆

當你做的事，無法跟成就感連結，或是不能與分享喜悲作連結，那所做的事是否還有足夠的價值與意義？一切的一切，是否只剩下為生存而作的努力？

◆

儀式感為生活中的行為注入意義與價值，讓日常不再那麼日常，能有一些不一樣的風格與調性，為人帶來不一樣的愉悅與滿足

◆

年輕人就別花時間在短影音了。當你逐漸長大，會發現這個世界越來越沒有耐性，只要短、小、精、實。

趁著年輕，還有青春能揮霍，多花點時間在細節上吧

看影片，去品味為何要用一個十幾二十秒的鏡頭，只拍稻穗搖擺發出如浪潮的聲音
賞一幅畫，去思考一個留白的空間如果塞進幾個筆觸貨色塊，會有怎樣的不同
念一首詩，去回溯詩人怎樣用這樣的聲韻來營造那個情緒或情境

當一切都要求精煉時，掌握細節的底蘊，就會是你與他人不同的關鍵

◆

家不是一個地方、一個場所，它是一個熱源
當感到寒冷，它能給你溫暖
當失去動能，它能為你添加柴火
當心死了，它讓你在火柴的星火中看到希望

但當家不再是個熱源
就會潰縮成一個場地，就是一個場地

◆

要推測一個人的目的並不容易
但可以用「永續」來檢視政治人物
如果永續不在他的思慮中
那他的作為只是想殺鵝拿金蛋

數位競爭策略

數位競爭策略 (The Future of Competitive Strategy)

對傳統產業，較常見的競爭策略有競爭論中的五力分析。但在未來數位時代，企業必須思考數位導向的競爭策略。

傳統企業數位轉型的四個進程：

1. 提升營運效率
   利用互動是數據，改善生產流程與內部效率
   如即時監控感測器數據，減少生產設備停工時間
2. 進階營運效率
   數據來自用戶與產品間的互動，提升營運效率與產品設計優化
   
3. 數據驅動型服務
   將數據轉化為新產品/服務，為客戶創造新價值
4. 平台化競爭
   結合生產與消費生態系，透過數位平台與多方協作，形成新的商業模式

將書中內容彙整如下圖

企業必須具有數位能力，才能企劃數位策略

數位能力：

• 資源
• 基礎設施
• 資料
• 流程
• API

互相

在電梯大樓的公共電梯間，某甲說話大聲了些，另一人出聲要他低聲些，別吵了鄰居。他冒出了一句：「如果怕吵，就不應該來住集合住宅」

很難相信我耳朵所聽到的

在台灣的文化，或是台語中，我們常常會說「互相互相」

這個互相，除了彼此之間相互協助、幫忙外，更重要的人與人之間的互信、體諒、同理。我們常說台灣最美的風景是人，我相信這個「互相」一定是很重要的一個元素

大概三十多年前，我跟一位企業家前輩常有機會聊天，從他身上學習到很多待人識人的觀點。他曾經告訴我，一個人能否做朋友，就看他有沒有「互相互相」的心。如果有，表示他在思考時，也會從你的角度思考，這種人值得深交；如果沒有，他看事情多半只從他的角度出發，這種人大概很難長久相處

你跟身邊的人也能「互相互相」嗎？

「反對完美」 摘要與省思

 反對完美 : 科技與人性的正義之戰

Michael Sandel

• 這本書探討的是透過科技來改造人類，達到臻於完美，這是否是好的、對的方向
• Sandel基本上是不贊同這樣的科技應用於「改良」，但可以接受於「治療」
• 人類透過許多方式，希望能讓人類更美好
• 基因(先天)
• 優生學
• 基因工程
• 產前檢驗
• 後天
• 美容
• 菁英教育
• 藥物
• 後天的方式不易有長期的改變，但先天的方式則會影響物種發展
• 我們應該如何定義「完美」？這樣的完美是否在長期上，能讓這個物種更適應生存環境；或是讓這個物種限於local optimal，而失去走向global optimum，走向另一個更佳的另一個local optimal的機會
• 複製人是否符合於倫理、道德、法律？複製人的地位？
• 幹細胞/胚胎的道德疑慮
• 幹細胞來自
• 無性複製胚胎
• 剩餘胚胎 (生育治療診所產出的受精卵多於植入的數量)
• 這些胚胎是否算是生命？
• 從胚胎取得幹細胞，讓一個生命死亡、來幫助另一個人，是否合乎道德？
• 目前美國法律只允許使用多餘的胚胎，不贊成為了研究製造胚胎
• 美國每年有數萬個多餘胚胎
• 德國禁止醫師培育多於植入的受精卵

軟體架構

軟體架構

• 定義
• 組成系統的組件、組件間的關係、以及治理其設計與使其能持續演進的原則及方針
• 包含了有意義的決策(架構性決策)
• 需求或環境等情境引發的難題，會驅動進行決策，決定哪種設計來克服此難題
• 例如右邊房子的屋頂較左邊的更為直陡，其目的是當房子在雪地時，直陡屋頂的積雪會更容易因為重力影響而自動滑落，屋頂比較不會被壓垮。這就是架構性的決策
  
  
  
  
  
• 沒有架構設計，一團大泥球也是一種架構
• 架構沒有好壞之分，只有是否合適於目的
• 架構主要在達成非功能性需求(non-functional requirements)
• 必須要有基於明確理由而為的決策之紀錄
• 就像是上圖，為何要採用較直陡的屋頂
• 記錄下WHY
• 架構師
• 考量環境，並找出其中的限制條件與假設，是架構師的主要責任
• 架構師的最重要工作，在於排除軟體設計中的不可逆性

領域故事化 (Domain Storytelling)

 領域故事化 (Domain Storytelling)

WHY:

• 化解軟體開發人員與商業(business)部門的認知落差
• 理解領域
• 釐清軟體需求

WHAT:

提供口語化與視覺化的建模工具與方法

WHO:

• 領域專家
• 軟體開發人員
• UX設計師
• PM
• 商業分析師

WHEN:

• business modeling
• system modeling

HOW:

透過下列建構元件來組成視覺化模型：

• Actor
• Work Object
• Activity
• Sequence Number
• Anotation (optional)
• Group (optional)

範例

下圖描述電影觀眾購票的流程

個人理解：

• 這樣的建模方式，涵蓋了UML中的use case diagram, activity diagram, sequence
• Agile時代，將多個圖融合為一，更符合敏捷之精神
• Actor, Work Object, Activity其實便隱含了glossary的目的

紅隊測試 (Red Team)

 紅隊測試 (Red Team)

這本書的副標 "How To Succeed By Thinking Like The Enemy" 就已經很清楚說出了Red Team的目的。

看完這本書的引言，就可以對紅隊的運作方式有七八成的概念了。

• 緣起
  起源於十三世紀梵諦岡教廷的魔鬼代言人(Devil's Advocate)，透過魔鬼代言人的檢驗，來省視封聖的過程
• 角色
  提供決策參考資料
• 核心主題
  你不能替自己的表現評分
• 個人認知偏差
• 鏡像效應
  假定對手面對相同類似情況時，想法會和自己相同
• 定錨效應
  過度仰賴最初的資料或印象，以致難以顯著改變之後的判斷
• 驗證偏差
  偏重支持自己想法的發現與證據
• 組織偏差
  已成為組織文化的俘虜，難以擺脫慣常習性
• 作業方式
• 模擬
  針對預定事件或可能發生的情況，事先演練，藉以檢驗、改善策略、戰術與流程
• 探查弱點
  扮演敵方角色，測試架構、機制的可靠性，進而強化弱點
• 另類分析
  利用解放手段或結構化分析，對問題假設、人性、組織限制、作業流程等進行質疑，提出不同的思考
• 成敗因素
• 組織領袖之意願與接受度
• 紅隊須在組織(策略、文化、結構、流程)的邊緣或外部，以發揮作用
• 紅隊人員
• 須充分了解組織(策略、文化、結構、流程)，並是反向思考者
• 成員需不拘泥於方法與技巧
• 不斷精進自身能力、觀念、性格、心理素質的深度與廣度
• 領導者必須有足夠的溝通與社交技巧
• 須抱著「或許相反才對」的精神看待事物
• 保護異議者的文化
• 紅隊的誠實報告須有豁免權，不因牴觸組織領袖之決策與意志而受懲處
• 紅隊須受制度保護，但不能被組織俘虜
• 組織架構的位置
• 活動範圍與自主性
• 作業模式(如怎麼瞭解組織，以及報告對象、報告方式)
• 紅隊作業心態
• 紅隊也是組織的一分子，生存的目的是協助組織永續強固，而非將之擊倒
• 紅隊亦需肩負教育組織之責
• 紅隊測試週期
• 太過頻繁容易打擊士氣
• 頻率太低容易僵化自滿
• 頻率須視領域變動的速度做調整

其他觀念

• 1-2-4-Whloe
  針對問題，先各自思考策略與解決方案，接著兩人一組分享想法，然後四人一組，最後在全體一起討論
• 在聽其他人發表意見前，選定自己的立場並寫下來
• 先少數人討論，能有充分的陳述，透過說出想法的方式來讓自己的想法更完整
• 避免社會從眾(social conformity)，發揮思想警衛(mind gurads)與阻擋者(blockers)
• 在每個人都講過話前，沒有人可以第二次發言
• GICOT
  Good Idea Cut Off Time
• 美軍對Red Team定義：
  由受過相關訓練和教育、並有經驗的專家構成，使聯合作戰指揮官得以獨立完成以下工作：
• 針對特定議題做批判審查和分析
• 探索各種計劃與行動
• 從另類角度分析敵方能力
• 紅隊大學課程四大支柱
• 批判思考
• 減輕團體盲思
• 文化同理心
• 自我察覺
• Red Team Handbook
  https://usacac.army.mil/organizations/ufmcs-red-teaming/schedules-and-handbooks
• 死前分析(Premortem Analysis)
  專案開始前的會議，團隊在會議中想像可能會發生什麼事導致專案失敗。然後逆向制定計劃，以幫助防止潛在的障礙並增加成功的機會。
  行為心理學家和神經科學家推薦該技術作為對抗認知偏差和降低專案風險的特別有效的方法。
• 第十人理論
  如果有九人看過相同資料，得出相同結論，則第十人有責任提出反對意見。他必須假定前九人都錯了，開始思考其他的可能，無論這個結論多麼荒謬。
  抑制團體盲思

給學生們的一段話

 常常聽人抱怨，「某某同事能力沒有我強，但老闆卻重用他而忽略我」

如果你要從台中到台南，你會選擇時速只有90Km但數年都無誤的巴士，還是據說可以時速200Km但還沒充分試車的跑車？

一般老闆在面對資源時(員工也是資源)，看的是信任與穩定。只要他能掌握手上資源的可信賴度與穩定性，他就能擬定可行的計畫來達成預期的目標

如果資源難以信賴、不夠穩定，他就難以預估計畫的可行性。跑車夠快，但我們不知道他是不是能到終點；老巴士雖慢，但總是會到

你是員工，會希望老闆重用你；如果你是老闆，更希望客戶會重用你。想要讓別人重用你，一定要學會跟習慣呈現自己，讓別人記得你、記得你的穩定，進而能信任你

不過許多人都不習慣展現自己，很多人的原因是怕別人笑、怕別人異樣的眼光

努力呈現自己也是檢視自己的好時機，當你發表想法而有回饋時，如果這個回饋是有價值的，那你就賺到了，你不用花錢找顧問就可以修正自己的想法；如果這個回饋是沒有根據的，那你也賺到了，因為你不用繳學費就能知道這個人不能合作

課堂上要努力展示自己，被笑也無所謂。他笑你也不過這四年，如果你不斷修正自己、努力讓別人看見而成功了，你可以笑他一輩子 (其實那時候你也不在意了)

跟白沙屯/山邊媽祖進香去

這裡整理一下跟著白沙屯/山邊媽祖進香的一些大小事，備忘也供大家參考。

白沙屯拱天宮官方網站

一些大大小小的事，請以官方網站的宣布為準 https://www.baishatun.com.tw

進香與報名日期

每年尾牙(農曆12月15日)會在拱天宮擲茭向媽祖請示進香日期，然後公告於拱天宮官方網站。報名日期也會隨後公告於官網，一般報名日期大約在出發前一個月到前三四天左右。

進香配備

單日行程

許多人由於工作或家庭關係，無法全程跟隨媽祖，只能在有時間時跟隨媽祖走一段。這時要準備一些配備：

• 健保卡

• 口罩、酒精噴瓶
  疫情期間，帶好口罩勤洗手

• 隨身藥品 (慢性疾病常用藥、蚊蟲叮咬用藥等)

• 好鞋 (不是新鞋，最好是有氣墊的，也跟你的腳磨合一段時間了)、好襪(有人推薦五指襪，舒適有緩衝力就好)

• 排汗衫、褲、毛巾

• 防曬

• 抗UV袖套 (若穿短袖)
  一般流汗量多，塗防曬油不太實際，若是穿短袖則建議用袖套防曬

• 帽子
  若有報名，應該都有拿到進香帽；若無報名，可自行準備
  沿途有時風大，小心帽子被吹跑

• 頸部防曬
  可考慮帽沿大的帽子，或是脖圍、毛巾

• 環保餐具

• 錢
  不要帶太多，沿途都有善心人士，飲食不用擔心。帶一點錢，再帶張提款卡應該就夠了 (錢跟提款卡分開放)

• 白沙屯GPS定位APP 被海放時才能知道媽祖婆在哪裡了，另外上面會公告停駕駐駕等等訊息，才會知道可以休息多久

• 行動電源 現代人可以沒帶錢包，不能沒有手機 但沒但的手機跟帶個石頭沒什麼兩樣

過夜配備

若要過夜且沒有報名遊覽車，每天駐駕後就要自行尋找過夜處。由於很難預測能找到怎樣地過夜處，也許學校廟宇民宅走廊、也許有善心大德提供倉庫。疫情期間，很多地方都關閉謝絕香丁腳休息了，能過夜的地方不容易尋覓，最好的心理準備是把自己當街友，隨遇而安。

至於配備則是能少就少，因為除了走路與休息外，你大概都不會想做其他的事。所以別讓背包的重量壓垮你。

• 背包
  好的背包可以讓負重平均分攤到全身。好的背包用個五年十年沒有問題，所以別吝惜這方面的投資

• 防蚊帳、個人帳、睡袋
  怎麼過夜每個人的盤算都不一樣。如果想要有隱私，帶個個人帳是不錯的考量，但要考慮到重量。更重要的是防蚊。有些地方的蚊子真的很大隻。不管想用什麼方法對抗蚊子，一定要考慮配備的大小重量是否適合攜帶

• 鋁箔/塑膠墊
  如果不想攜帶帳篷，可以考慮鋁箔或塑膠墊 晚上睡覺時還是要有個地墊來隔絕地面的溼氣寒氣。有些人會隨地找一些紙箱來使用，但不見得能找得到，如果能自備個輕便的墊子會比較好。墊子有一些厚度，休息時會較舒適；有些墊子折疊後大概像便當盒大小，可以方便攜帶；這就視個人需要來選擇

• 防蚊頭罩、薄風衣
  有些地方的蚊子很可怕，會讓人徹夜難眠。我儘量減輕行李重量，所以晚上休息時除了鋁箔墊，就是長褲、薄風衣、再加上防蚊頭罩，減少蚊蟲侵擾的機會

• 換洗衣褲襪
  一般大概很難有能盥洗的地方，能找到水龍頭可以擦洗一下就不錯
  在衛生的前提下，有機會能換一下衣褲襪也是不錯

• 潔牙工具
  不一定有地方可以刷牙洗臉，或許可以帶牙線、牙線棒、牙間刷等慣用的工具來潔牙

行前準備

• 放頭旗當天開始吃齋(至少早齋)三天，出發後便無葷素限制

• 出發前幾天要修剪腳趾甲 (正確的修剪方法網路上都可以找到)

進香途中

一些進香途中應該注意的事情，官網上面就有了，可以參考這裡。一些基本應該知道的事項就列在這裡了：

• 不碰觸神轎頭旗

• 不碰觸神轎頭旗

• 不碰觸神轎頭旗 說三次了，也用不同顏色標註，夠明白了吧

• 不浪費食物 沿路隨時都有善心人士，需要的時候再拿就好，不要拿了一堆增加自己的負擔 最近幾年會發現路邊有被丟棄的食物，可能是有人拿了太多沒有需要食物，後來發現有更多好吃的食物，但是行囊已滿，就把一些丟掉了，走在進香的行列中卻浪費丟棄食物，媽祖會怎麼看你呢？

• 保持一顆感謝的心 沿路都有很多善心人士提供有形或無形的物資或服務，別人沒有欠你，受人點滴當湧泉以報 雙手合十，心懷誠意的感謝，即使他們只是在路邊跟你說句加油，都是值得你向他們表達感激

• 不貪心 結緣品不是進香的戰利品，沿路有很多結緣品，若沒有需求就留給別人，不要拿了沒用，帶回家又占位置，最後又丟掉，這樣就浪費了
  結緣本來就該是隨緣，有緣無緣都是因果 這幾年看到很多人為了「結緣品」而有些糾紛，這應該都違背了初衷吧。再媽祖進香的行列中，是不是應該先把貪念修掉呢？

• 綁緊鞋帶
  把腳固定好，避免指甲不斷往前頂到鞋尖，如果讓腳尖不斷頂到鞋子，這樣走久了指甲可能就會陣亡了

• 該休息就要休息 當走累時還硬著頭皮走，走路的姿勢就會改變，會用到以前沒有用的的肌肉。因為這些肌肉是你之前沒有訓練的，這可能會讓你走得更累，甚至容易造成傷害。所以定時休息一下，做一些收操伸展的動作，可以讓你的肌肉不再那麼緊繃，可以走得更遠

• 休息時脫鞋
  把鞋子脫掉，讓腳透透氣降一下溫，按摩一下，避免長時間行走起水泡

其他習俗

個人認為媽祖慈悲，只要心誠行正，出發良善，媽祖都會保佑大家。一些常見的習俗問題，參考參考。

• 家中有人過往
  https://www.facebook.com/groups/632716536831984/posts/4203255929778009/

心得

慘痛的第一年

我的第一年是2018 (可以查一下那一年的進香時程)

憑著當兵的經驗，就輕忽了，穿著一雙舊布鞋就上場了。

第一年總是想跟著神轎走，希望能目睹一些神蹟。神轎旁人超多，根本難以邁開步伐走，幾乎都是小碎步走，這樣的走法走沒走多久就會累了，沒有辦法用自己的步調去走，完全受制於人群。當然很快就被海放了。從一開始還能走在神轎旁，然後逐漸拉開距離，到還沒走到清水，聽到兩三公里外的炮竹聲，就知道跟神轎差距多遠了。想急起直追，已經因為前面的體力耗損追不上了。

舊布鞋鞋底本來就磨損了，經過這樣折騰，鞋底也磨穿了。加上忘了把鞋帶綁很緊，腳尖不斷往前頂到鞋尖，走到沙鹿童綜合附近，我就掛點了。回家！

回家檢視，兩腳整個腳底都起水泡，三片指甲壞死拔除。

個人心得

• 找一雙有氣墊的鞋 (我是偏好亞瑟士有亞瑟士膠的鞋，愛迪達的Air系列聽說也不錯，不是置入行銷，歡迎大家也提供你覺得的好鞋)，如果有需要，趕快買雙好鞋，現在還有時間磨合

• 腳指甲一定要修剪(如何修剪可以google一下)

• 鞋帶一定要綁緊，不要讓腳尖不斷頂到鞋尖

• 休息時就脫鞋，讓雙腳透氣散熱

• 別執著走在神轎旁，你一定會被海放。後來幾年我都跟頭旗走

• 該休息一定要休息，該上車就上車，路很長，別為了一時想趕上，反而犧牲了全程

意見溝通的策略

在TED上讀到這篇文章 6 tactics to help you turn heated dinner arguments into real conversations，

• 說出不同意見
• 熱烈討論是強化信念的方式，也有助於破除盲點
• 保持冷靜，不作人身攻擊
• 言詞避用你我他，主詞儘量用我們
• 釐清並對現況與議題建立共識
• 避免雞同鴨講
• 透過提問來釐清現況與問題，趨近出第一步的共識
• 有助於雙方開放想法
• 對事不對人
• 討論是思想的競賽，不是攻擊他人
• 每個人都是獨特的個體，不可一竿子打翻一船人
• 營造可接受錯誤的討論平台
• 營造更大更發散的空間，讓創新的想法得以孕育
• 可讓討論者更開放心胸
• 透過語言、語氣、肢體動作等來引導更發散的想法
• 只使用可靠到事實
• 假設與事實是不同的
• 若要將一事視為事實，必須確認其來源、內容的可靠性
• 若無法完全確認可信度，就應該稍作存疑
• 適時停止
• 感謝對方的意見、欣賞對方的論點，將發言權交回對方

討論過程必須有公正第三者來管理討論，隨時制止或中斷討論，避免陷入情緒，第三者不可有預設立場選邊站
別急著將自己的想法放進別人的腦子。聆聽，找出機會與契機，然後再行動

Planning Process

 Planning Process (計畫流程)

結合「主管這樣帶人就對了」一書第九章以及個人經驗之心得整理。

把餅做大，聚眾共好

在現代社會，有越來越多事情是無法一個人獨力完成，需要團隊合作與各方參與才有辦法成事。例如說想要開發新產品，技術的需求是跑不掉的，這裡又包含了軟體與硬體等方面的技術，除此之外，一定會有資金面的需求，也需要管理者來掌控工作的進展，還要有行銷與銷售方面的能量才能把新產品推出去，進而開始營利。

由於需要各方面的人才，因此「把餅做大，聚眾共好」就是領導者很重要的工作。

把餅做大，不能想著獨善其身或是自己獨吃，而是要思考一個系統、流程、商業模式，可以容納更多的人進來，雨露均霑，讓計畫中的工作有更多人支持，大家齊力往好的方向推進。當然要記得一句名言：樹大必有枯枝、人多必有白癡，因此在聚眾時，就一定要慎選，找對的人進來，找可以同心合作的人進來，大家都能在計畫上有正面的貢獻，達到共好。

也因此領導者必須人脈夠，才有辦法母體中找出對的人；如果自身朋友不多，能有的選擇就少，就不容易找到對的人。因此在平時就需要廣結善緣，能發掘每個人的長處(每個人都有缺點，找別人的缺點不是能力，能找到每個人的優點才是真能力)，不斷充實自己的口袋名單，這是領導者平日很需要做的事。

此外，人多意見也就會多，領導者就必須要有協調的能力，彙整所有人的意見想法，在不同意見中綜理出最大公約數，讓大家仍能齊心向前，並掌控局勢，讓事情往你想要發展的方向走，這部分的能力就需要時日下的修練才能精進。

把餅做大，聚眾共好！

把餅做大，聚眾共好！

把餅做大，聚眾共好！

How many documents should we have?

Documents are of little importance, but documenting is essential.

Documents are valuable but costly. How many documents should we have? "Less is more". How less is enough?

You will need more documents until you can synchronize your team.

So, how many is enough?
It depends on the culture, quality, workflow of your team, and mutual understanding between members. The less stable your team, the more documents you need.

2019白沙屯媽進香後記

跟白沙媽進香最大的副作用
不是曬傷脫皮
不是筋骨痠痛起水泡
不是指甲掀開脫落

而是哭點變得超低

看到神轎很超脫自己想法時想哭
看到香丁腳們彼此扶持時想哭
看到沿途鄉親堅持把各種資源塞進你手中時想哭
…

我以為只我有這副作用

午休跟其他香丁腳聊起，發現很多人都是這樣

也因為這副作用
大家雖然走到很想#@$*&%!#
可是隔年大家都失憶
乖乖又自動報到了

唉…沒藥醫

獨角獸與承諾思維

從未來地圖一書中得到的概念

獨角獸

• 讓人思考未來會怎樣
• 使人自然改變自己
• 創造社會價值

承諾思維 (Thinking in Promises)：以終為始來思考如何做事

以Python程式產生InfluxDB資料

我們接下來將寫個Python程式，來模擬溫度sensor產生資料並寫入InfluxDB中。然後利用這些資料，在Chronograf中設定dashboard的樣式。

要讓Python連上InfluxDB，我們需要Python-InfluxDB connection。我們可以使用pip來安裝這個connection元件："pip install influxdb"。詳細指令介紹可參考這一頁。(此範例使用的是Python 3.x)

接下來的程式是模擬廚房、臥室、客廳三個溫度感應器，每秒鐘會回報溫度到InfluxDB。程式一開始，會先建立與InfluxDB server的連結，並建立一個 "sample"的database。我們準備了一個obj的json物件樣板。大家可以把measurement想像成表格(table)名稱。這裡有兩個columns，一個是location用來存放感應器位置，另一個是value來存放溫度。前面有提過，tag是indexed column，field是non-indexed column。由於InfluxDB是時間序列資料庫，因此每筆資料都隱含了一個time的column。

開始執行此Python程式後，就可以看到InfluxDB視窗一直有log message在跑，如果沒有error message，就表示此python程式正在餵資料到InfluxDB。

from influxdb import InfluxDBClient
import random
import time

host = "localhost" #influxdb IP
port = 8086 #influxdb port
username = "root" #influxdb username
password = "root" #influxdb password
dbname = "sample" #database name

# json object template
obj = {'measurement':'temperature', 'tags':{'location':''}, 'fields':{'value':0}}

# arrays for location names and temperatures
locations = ['kitchen', 'bedroom', 'living room']
t = [20] * len(locations)

client = InfluxDBClient(host, port, username, password) # connect influxdb
client.create_database(dbname) # create database

while True:
 for i in range(0,len(locations)):
  t[i] = round(t[i] + random.uniform(-0.5, 0.5), 2) # generate temperature

  # prepare data object
  obj['tags']['location'] = locations[i]
  obj['fields']['value'] = t[i]
  print(obj)

  # write data to influxdb
  client.write_points([obj], 'ms', dbname)

 time.sleep(1)

Python-InfluxDB connection元件的相關資料，可參考這頁的說明。

我們可以把InfluxDB client開啟，打入下列指令，來看最近三秒寫入InfluxDB的資料，確認資料確實有寫入。從這裡我們也可看到，除了location與value這兩個我們設定的欄位外，還有一個time欄位。

接著我們再用瀏覽器進入Chronograf網頁介面。(http://localhost:8888)
我們到Dashboard這頁，可以看到下面的畫面。

點選line，然後add data，接下來都可以用點選的方式來產生dashboard圖樣。我們先產生一個彙總的圖表。點選sample，再點選temperature，把三個地點都勾起來，並點選group by location，然後再把value勾起來。這個操作過程會自動幫我們產生InfluxQL。完成後點選右上角的綠色勾即可儲存。

回到Dashboard頁面，可以設定此圖表之位置與大小，並可在右上角設定更新速度與資料顯示長度。

正上方有Add a Cell to Dashboard藍色按鈕，可以加入更多圖表。大家可以去玩玩各種圖表，了解Chronograf。Chronograf的使用說明可以參考官網的文件。

InfluxDB

若想了解時間序列資料，可參考這篇簡述。
InfluxDB應該是目前佔有率最高的TSDB了，因此我們利用InfluxDB來了解TSDB的運作。

這裡是InfluxData的官網，其open source的版本中有一個TICK stack的架構，包含了四個元件：

• Telegraf：資料收集元件
• InfluxDB：資料儲存元件
• Chronograf：視覺化操作介面
• Kapacitor：資料處理引擎

這四個元件組合起來，對大部分的應用來說，應該是相當充足了。

為熟悉InfluxDB，我們透過關聯式資料庫的概念來了解一下InfluxDB的架構。你也可以透過官網的Key concepts來做更深入的了解。

• database：這個概念跟關聯式資料庫一樣
• measurement：相當於表格(table)
• tag：有索引的欄位 (indexed column)
• field：沒有索引的欄位 (non-indexed column)

先提這四個名詞。如果各位想了解更多詞彙，可以參考官網上的Glossary。

為了快速達到了解InfluxDB，我們只先專注在InfluxDB與Chronograf。首先先來安裝這兩個元件。我們以Windows為使用環境。請先到官網的下載頁面進行下載。

下載的是zip格式檔案，只要將之解壓縮即可。我們先來看influxdb.zip，解開後會有5個exe執行檔。主要的有兩個：influxd.exe是InfluxDB server，執行起來後可以看到這樣的畫面。server預設會使用port 8086來接收API指令。因此系統的安全設定上要允許使用這個port。資料庫預設的username及password都是root。

influx.exe 是client程式，我們可以利用這個程式來操作資料庫。直接執行後便可以連接到本機上資料庫。我們可以先試一個指令 "show databases" 來看看資料庫是否正常運作。如果有回應目前資料庫中databases清單，便表示系統正常運作。 (由於才剛剛安裝，應該只有 _internal 這個內部資料庫)

我們可以用exit指令來離開client程式。

InfluxDB使用的query language是InfluxQL，官網上有一頁做了與SQL的比較，大家可以參考一下。

接下來解開chronograf.zip後，有兩個exe。chronograf.exe是web server程式。執行後以瀏覽器連接 http://localhost:8888，就可以進入到視覺化界面。

我們可以先到configuration頁面檢視目前與InfluxDB server的連線狀況

到目前InfluxDB與Chronograf都完成安裝並可以正常執行。要停止這兩個server的執行，只要按ctrl-C即可。

下一篇，我們將寫個Python程式來為資料進資料庫，並在Chronograf中設定dashboard的圖表。

時間序列資料與資料庫

再資料處理領域中，有一類型的資料是跟時間有密切關係的，這類的資料紀錄了某事物隨著時間變動的狀態，例如某商品的價格資訊、某廠房的環境溫溼度、某物流車的位置與速度等等。這些資料都屬於時間序列資料(Time-Series Data)。

這類型的資料有一些特質：

• 資料是用時間排序的一組隨機變量，例如下圖，數值會隨著時間的變化而改變，因此時間是很重要的資料維度之一
  
  
  
• 資料的產生可能是快速、大量且持續
  例如某個機台，每秒鐘會產生100筆資料，每筆資料約250KB，一天下來單單一個機台的資料量就高達2TB了，而且只要生產線保持運作，資料就不斷的產生

有相當多領域的資料都具有時間序列的特性，如計量經濟學、數學金融、天氣預報、地震預測、通信工程等等。尤其IoT物聯網應用蓬勃發展，時間序列資料的相關研究更會受到重視。

資料若要利用資訊系統來處理，儲存便是一個重要的課題。目前許多的應用中，會使用關聯式資料庫加上一個time-stamp欄位來解決這問題。若檢視時間序列資料的特質，我們要考量的因素有：

• 資料是源源不斷產生，而且鮮少需要修改，因此insert的效能會是重要因素，update反而不那麼重要
• 在一些應用中，資料的產生是快速且大量的，因此擴展性(scalability)就相當重要
• 時間的運算常會是取回資料時常用到的功能，所以時間運算的效能很重要

對關聯式或其他資料庫來說，對上述的幾點的表現並沒有那麼亮眼，因此，有一時間序列資料庫(TSDB; Time-Series Database)這個分支，針對了時間序列資料的特質來量身打造了。目前市場上有相當多的TSDB系統，常見的可參考這篇wiki資料。目前較熱門的就以InfluxDB與Kdb+為主了。這一篇比較表也很有參考價值。

下一篇，我們將開始安裝與使用InfluxDB。

Spring Boot 試作紀錄

工作上的系統，架構常用到micro-service，建立這些服務，常常都需要自己架構出需要的服務元件。常讀到Spring Boot的介紹，對它的自動化很好奇，趁著有個小空檔來試作一下。

試作目標：

• 支援 static resources
• 支援 servlets (HTTP request handler)，收到request後，可根據client的資訊作回應
• 嵌入Tomcat或Jetty

使用環境：Eclipse 2018-09

安裝 Spring Tools
進入Eclipse後，點選 Help | Eclipse Marketplace...
以 "spring tool" 就可找到 Spring Tools 4，點選Install即可安裝

建立 project
我們利用剛剛安裝的Spring Tools提供的工具來建立Spring Boot專案。
首先在主選單點選 File | New | Other...

選擇 Spring Boot | Spring Starter Project，然後進入Next

接下來要設定專案的相關資訊了，雖然事後都還可以調整，不過一開始就先設定好，後面可以省些事

幾個比較重要的欄位：

• Name (專案名稱)，這預設會連動到下面的Artifact ID
• Type, Java Version, Language都使用預設，Packaging有Jar與War，看未來想打包成何種形式，可以在pom.xml中改變
• Group (Group ID) 用來識別此專案的名稱 (可參考這裡)，可以在pom.xml中改變
• Artifact (Artiface ID)在未來產生Jar file時會用到這名稱，可以在pom.xml中改變
• Version用來記錄版本，在未來產生Jar file時會用到，可以在pom.xml中改變
• Description用來對這個專案作一個描述，可以在pom.xml中改變
• Package則是建立程式時預設的package架構

接下來就要選擇專案需要的dependent libraries了，例如若專案需要用到PostgreSQL的JDBC driver，就可以直接勾選，Maven就會自動幫你下載了。
目前試作的專案只需要Web，所以就勾選Web即可。

點選Finish，Spring Tool就開始幫我們產生專案了。

Spring Tool幫我們產生了一個程式 GreetingApplication.java。這程式的內容很簡單，就只是啟動Spring Boot的應用

建立靜態網頁
靜態網頁與相關資源(js, css, etc.) 可以放在src/main/resources/static下。在此專案我們就放一個簡單的網頁。

page.html
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Welcome</title>
<link href="css/page.css" rel="stylesheet" type="text/css" />
</head>
<body>
<h1>Hello, welcome to static page.</h1>
</body>
</html>


page.css
h1 {
color: #ff7777;
font-style: italic;
}

建立Servlet (request handler)
接下來我們要進行動態回應的部分。我們列出需求：

• 當使用者以POST或GET連結到 http://:8080/func時，則會由此handler來處理
• 如果request parameter有name，我們就回覆 Hello, !，如果沒有name，則回覆 Hello, world!
• 列出使用者的IP

我們建立的handler如下 (RequestHandler.java)
@RestController
public class RequestHandler {

    @RequestMapping(value="/func", method={RequestMethod.GET, RequestMethod.POST})
    public String handler1(@RequestParam(value="name", required=false) String name,
            HttpServletRequest request, HttpServletResponse response) {
        String user = (name==null || name.isEmpty())? "world": name;
        String host = request.getRemoteHost();
        String result = String.format("Hello, %s! You are from %s", user, host);
        return result;
    }
}

對此程式片段作一個註記：

• @RestController：Spring採用MVC架構，註冊此程式為Controller
• @RequestMapping：註冊此方法負責特定request的處理。value的值為URL對應的path，method則標記了要處理的方法
• @RequestParam(value="name", required=false) String name
  Spring Boot會幫我們解析parameters，你可以將你需要的parameters都列出來。
  required預設為true，如果為false則表示此參數可能不存在於query string中
  解析出來的name值會放到字串name中
• 因為我們需要使用者的IP，這需要從request物件中來取得，因此我們handler1的參數列加上了HttpServletRequest request，以便在程式中抓到IP
• 雖然不會用到，我們也加上了HttpServletResponse response，若程式需要對response object作一些設定可以使用。在這個專案中是可以拿掉

執行
如果熟Eclipse的朋友就知道有很多種執行方法。這裡介紹其中一種，在project上按右鍵，Run As | Spring Boot App 就可以執行了

透過瀏覽器來看靜態網頁

以及動態內容

產生 JAR file
在project上按右鍵，Run As | Maven install就可以產生jar file了。

產生的jar file會放在專案的target目錄下。

所產生的jar file包含了專案所有需要的資源與libraries，因此只要把這個jar file放置到要執行程式的機器上，就可以執行這個服務了！
java -jar greeting-0.0.1.jar

由於這個jar file包含了必要的libraries，因此其file size大概都從15MB起跳。對大部分的運行環境應該都還能接受。

改內嵌 Jetty
Spring Boot 在 web應用上是預設內嵌Tomcat，若要改為使用Jetty，則需要修改pom.xml。現有的pom之片段是：

在這裡將Tomcat排除掉，再加入Jetty

這樣就可改用Jetty為平台了

修改port
這個系統預設是使用port 8080，若需要修改，可以直接在src/main/resources/application.properties中加上下列這行 (例如要改為port 88)
server.port = 88