2023 MWC Day2 筆記心得

筆記

ChatGPT生成術

• 如果問Chat GPT 怎麼開發LineBot的話…？
  • 直接問「請教我如何寫LineBot」，給的答案很模糊，只有大致的步驟而已。
  • 如果改問「請教我用 Node.js 寫一個 Line Bot的範例」，給的步驟和語法即正確許多 https://chat.openai.com/share/f6590c00-335f-4fa7-b1cf-d1d4ac0ecf8f
  • 總結
    • 給的prompt太空泛，ChatGPT的回答會很鬆散（抽象）
    • 越特定的prompt，越需要去拆解知識點，這仰賴發問者的領域知識含量，需要自己去拆解詳細向ChatGPT發問。
• 透過ChatGPT，幫我們快速生成老師的邀請函！
  • 網頁內容「直接」全部複製，貼到ChatGPT，輸入「整理表格」的指令。以下為sample：

    • 資料來源：https://ide.ncku.edu.tw/p/426-1160-21.php?Lang=zh-tw

    • 從以上資料來源「直接全選複製」所有需要的資料

    • 下一個整理的prompt，以下為範例：

      請幫我把以下清單整理為「姓名、email」的表格
      
      名譽教授
      吳豐光
      名譽教授
      吳豐光
      fonggong@mail.ncku.edu.tw
      專任教師
      甲組：整合與策略設計
      劉說芳
      教授
      劉說芳
      ...

    • 結果：https://chat.openai.com/share/47b186d8-dcd2-44bc-b416-59a0a2dec1ca

      • 表格

        以下是整理后的「姓名、email」的表格：

  • 下一步：用表單內容下指令，請ChatGPT生成AppScript，自動生成邀請函！

    • 指令sample：https://chat.openai.com/share/2b5c38ce-5d66-4511-a371-fe4151dc9fbd

    • 在Google Sheet上執行AppScript的結果：https://script.google.com/u/0/home/projects/1U9WZY4E7hKBF1ONtmixqnizfoZCzwqOpYAASDnLH9JUQ1bEVIGPDKaiF/edit

    • 結果：直接多出了數十則邀請函草稿囉！

      

• 可以試試看把自己的資料餵給ChatGPT，資料正確度會高很多！
• Wolke流詠唱術
  • role：角色
  • context：脈絡上下文，要有的內容
  • input：輸入
  • output：輸出結果
  • interface：介面
• 內容做取捨，因為ChatGPT記不了太多！
• 可以試試看ChatGPT Assistance API
• 總結：
  • 工作項目的拆解（*其實不只是問ChatGPT的生成式AI工具，連我們一般在做工作也是如此）
  • 具體會更好，項目越少越精準越好：開發LINE Bot → IT Teacher 開發LINE Bot → Node.js 開發 Line Bot

Rust

• 課程講義目錄：https://hackmd.io/qQzXSWXiStaKni69Y6K4Aw?view

• Makefile：用來讓rust知道什麼指令對應哪個「複合指令」，就像是node.js中的package.json裡面的scripts

  MAKEFLAGS += --silent
  
  build-lib:
  	cd libs/cli && cargo build
  
  cli:
  	cd app && cargo run

• 加上make去使用，這樣等同於執行上面的cd libs/cli && cargo build

  make build-lib

• Cargo.toml 為「管理該目錄」的說明檔案，可以聲明該目錄的一些資訊

可觀測性平台

• 何謂可觀測性？ 透過應用程式的「外部輸出」來理解其內部狀態。
• 關於資訊：資訊足夠嗎？ 有好好整理嗎？
• 指標、日誌和分散式追蹤
• 流程sample
  • Alert → Dashboard → Adhoc Query → Log Aggregation → Distrubuted Tracking （*跟目前工作中，負責值班的值日生查看alert流程很像）
  • Alert的「類型」很重要，盡量讓人「一目瞭然」
• Grafana可觀測性平台
• Prometheus：
  • 監控與告警工具，CNCF第二個專案。
  • 可以用PromQL查詢
  • 系統指標：CPU, Memory…等
  • 業務指標：Request頻率, API回應速度
  • Java Sprint Boot有套件可以用
  • Mimir：開源的儲存方案，把巨量或多個的Prometheus紀錄存起來
• 注意資料的流向，是有其他東西把資料爬走，還是我們要自己撈？
• REF
  • 簡報 🔗
  • Repo：https://github.com/blueswen/observability-workshop-101

專案管理通靈術

• 若能向「早餐店阿姨」那樣，看到我來就知道我今天還是蛋餅+大冰奶，可以如此「料事如神」該有多好！
• 主題可以拆分為三項：專案、管理和通靈術。這次著墨在「通靈術」更多一點，而這也是吸引大家（包含我）的關鍵。
• 通靈術有三個要素：規劃、備案和超前佈署。
  • 通靈意味著客戶不必講出心底話，也可以一定程度上猜到該怎麼做。
  • 俗話說得好，錢無法解決「人」的問題。
  • 透過流程、團隊設計方式來改善工作的進展順利(規劃、備案等)。
• 妥善規劃
  • 寫程式應該也要學「速食業」那樣的作業流程，而不是家庭廚房那樣，什麼都自己來，學會分工與專業化。
  • 團隊趨向小型化，沒有人會在乎你是幾個人的團隊（即便一人也沒差），只在乎產品好不好用。
• 如何賺到錢？　只要能解決期望不對齊的問題，就能從中賺取財富。比方說，如果大家都抱怨附近便當店出餐都很慢，那只要開一間出餐快一點的餐廳，或許就能賺到錢。

遠距工作Bad Smell

• 同步 v.s. 非同步的工作方法：
  • 同步即為「單線程」的工作法，只能等上一個任務做完，才能接續下一個任務進行
  • ⭐ 非同步工作法則不必如同步的工作法，可以先完成一部分交差，直接去做其他事，「放著等」其他人繼續接手下去，而不必互相等來等去！
• 大Scope任務 v.s. 小Scope任務：
  • 大Scope：3~5hr才能完成並交付。
  • 小Scope：1~2hr就能完成交付，比起大Scope任務更有彈性，較不會因為同時協作的大家進度不一而互相拖累。
• 壞味道 一：會議也可以採「非同步」模式。不見得硬要每個人都「到場」，也可以隨遠距成員的「時間方便」，讓大家自由參與，減少同步依賴。
• 壞味道 二：重要資訊只集中在某些人身上。
  • 問題：等負責的人有空才能知道這些資訊，很浪費時間！
  • 解決1：建立重視文件的價值觀，養成紀錄的好習慣。比方說，會議進行時鼓勵大家參與「共筆」的編輯，並在會議完成後，將提出的需求轉換為「可追蹤」的任務。
  • 解決2：重視「共有公開」的知識庫。方便檢索為基本條件，最好是提供樣板，減輕筆記進入點的「門檻」，並將筆記預設為「公開」，減少權限帶來的檢閱問題。
• 壞味道 三：不得不打擾，才能確認工作狀態。
  • 問題：透過傳統的「管理」確認方式，才能知道對方目前的進度狀態。
  • 解決：讓遠端夥伴自行選擇方便的時間更新「任務狀態」，比方說表明「現正進行OOXX任務，請勿打擾」。甚至可以「頻繁」更新自己的工作狀態，是開心的，還是遇到問題苦惱中?
• 壞味道 四：不信任問題。
  • 問題：彼此互不信任。
  • 解決：主要關鍵在於提高透明度。
    • 跟上述幾個壞味道也挺相似的，解法也差不多，靠著流程與工作管理方式來改善，可以是「任務管理」和「知識管理」。
    • 任務管理：可以採用GTD、PDCA、Kanban等管理法，各種方法互相搭配使用。
    • 知識管理：不外乎是些共享的筆記軟體，個人建議還是用「專業」一點的為佳，像是Notion、Heptabase、Obsidian等。雖然Github自帶markdown預覽，但老實說不大好用，特別是「查找」和「編輯易用性」特別差。