git worktree 簡單介紹與使用 - Ray Yuan Liou

之前如果開發到一半要切別的分支看 Code 或改東西，我要嘛乖乖 stash，要嘛就直接開瀏覽器看線上的

這幾天才知道原來還有 worktree 這個指令，可以直接新建一個工作區，這樣就可以同一個專案同時開著兩條分支看了

有遇到同樣狀況的朋友之後也可以試試看～

git-worktree

今天看到前輩分享一篇新奇的東西：風險暴風雨(?)，轉貼上來給大家

Risk-storming - A visual and collaborative risk identification technique

這篇介紹了一種量化風險的方法：使用九宮格。縱軸跟橫軸分別會是機率（Probability）和影響程度（Impact）

Probability: How likely is it that the risk will happen?
機率：風險發生的可能性有多高？

Impact: What is the negative impact if the risk does occur?
影響：如果風險發生，會有什麼負面影響？

兩者都分成三個程度：Low, Medium 和 High。這樣就可以看見風險位於哪個位置

例如說我們可能有一個風險是某個共用服務死掉的話會連帶產品一起死掉，那我們就可以從機率和影響下去評估：他發生的機率很 Low、但影響是 High，那我們就可以把他貼在圖上（可以參考附圖，比較直覺一點 QQ）

把這些風險標示在矩陣上，團隊就能迅速對這些風險的處理優先順序有一些共識

除了量化風險的方式以外，這篇文章還建議團隊成員可以一起來識別風險。它提出了四個步驟

1. 畫一些軟體架構圖
2. 要求每個人各自識別風險，並寫便利貼
3. 大家一起把風險貼到架構圖上
4. 一起總結這些風險（注意那些只要一個人注意到的風險或是優先順序沒有共識的風險！）

這樣最後應該會得到一份團隊共識的風險列表，接著也就可以著手開始處理它們了！

看完這篇文章之後有點想自己先玩玩看，有興趣的朋友也可以閱讀之後帶回去玩(?)

今天真的是太睏了，睏到突然想起來可以分享這部影片：
最容易被忽視的習慣，比爾蓋茲都臣服的一本書｜《為什麼要睡覺？》｜文森說書

人類的睡眠階段分為前四小時的「非快速動眼時期」和後四小時的「快速動眼時期」，清醒的時候，我們的大腦會像海綿一樣吸收資訊，然後在深層睡眠整理資訊和長期記憶，並在快速動眼時期試圖串聯這些資訊。

因此我們可以在睡前和睡醒時留一點時間整理思緒和手上的問題，充分利用大腦睡眠時間的自動化背景處理特性，在睡覺的時候消化這些資訊（聽起來有點神奇）

除了睡眠的兩個時期以外，我比較驚訝的是其實有 30% 的人從基因中就是夜貓子、以及酒精其實只是讓我們察覺不到有醒過來，實際上根本就沒有好好睡覺

另外，睡前盡量減少藍光，會影響睡眠品質，讓大腦產生新想法的時段受到影響。（雖然我現在睡前還是會滑手機拖延一下）

今天的分享就先這樣，祝各位睡眠順利。準備來睏，明天見 ><

2024.4.24 收到另一篇心得，拿回來補充：

《為什麼要睡覺》讀書心得：殿堂級睡眠寶典打破 11 個迷思 - 閱讀前哨站

前陣子又踩到裡面的幾個迷思，例如使用安眠藥助眠卻還是嗜睡等等。

後來也決定像文章裡面引的：『從行為面著手進行自然睡眠』

這邊也把文中整理的、要有健康睡眠的 12 項守則貼上來：

1. 遵守規律的睡眠時間
2. 運動的好處很多，但是不能太晚運動
3. 遠離咖啡因和尼古丁
4. 避免睡前飲酒
5. 避免太晚吃大餐、喝太多飲料
6. 盡量不要服用延後或干擾睡眠的藥物
7. 不要在下午三點之後午睡
8. 睡前要進入放鬆模式
9. 睡前泡個熱水澡
10. 臥室要黑暗、稍涼、沒有電子產品
11. 適當曬太陽
12. 不要醒著仍躺在床上

我已經決定貼一份在房間牆上了

共勉之。

今天終於又鼓起了勇氣來面對堆積如山的收件閘，今天閱讀的是這一篇：
Tackling the challenges of using event-driven architecture in a billing system

在這篇文章裡，作者面對一個牽涉到錢（！）並且非常老舊的系統，使用 Event-driven 來串了一個新服務，並且分享了他們的心得

我覺得有趣的是在於他們遇到的幾個挑戰和做法：

訊息的冪等性

通常我們會希望訊息至少傳遞一次，並且最好只傳遞一次。但有時候還是會因為一些網路因素讓接收方重複收到訊息，這時候作一些處理讓訊息即使重複收到，仍然保持同樣結果就很重要。

這篇文章提出了兩個常見的做法：

Ensuring data consistency through repeated processing: this requires business components to process the same event input and produce the same result.

通過重複處理確保數據一致性：這要求業務組件處理相同的事件輸入並產生相同的結果。

Discarding processed events: after each event is recorded by the system and assigned a unique ID, duplicate events are discarded.

丟棄處理過的事件：系統在每個事件被記錄並分配一個唯一的ID後，會丟棄重複的事件。

印象中之前使用 Azure Service Bus 的時候，就是使用一組 MessageId 來辨別事件

事件處理順序

假設有些事件之間是有順序性的，雖然通常我們會按照時間發送然後接收，但同樣也可能因為網路問題導致順序亂掉。這篇文章則採取以下措施來應對：

In event schema design, we determine the order by designing a version number or ID for the previous order event for the same user’s event.

在事件模式設計中，我們通過為同一使用者的事件設計一個先前訂單事件的版本號或 ID 來確定順序

Ensure events always follow the order of consumption, discard disordered events and wait for the arrival of events that match the order.

確保事件始終按照消費的順序進行，丟棄無序的事件並等待符合順序的事件的到來

處理延遲事件

這項感覺和業務需求比較有關係。主要是 Queue 的延遲性，我們可能在 23:55 發送某個事件，然後 00:05 才被訂閱者收出來處理掉，像這篇需要計算金額的服務就會出問題

這篇的做法就是直接往後抓緩衝，例如在凌晨三點的時候去把前一天的做掉，這三個小時其實就足夠讓前一天的事件內容送達了

不過看這一段的時候有在想，如果真的有事件排隊排到超過這段可容忍的時間，應該需要發送一些警告通知來讓維運人員能夠及時察覺異常會更好？

重新發送事件

簡單來說就是如果接收者掛掉了沒有正確處理事件，發送者要可以重新把事件噴過去。他們除了在重新發送的時候使用 Lambda service 並且控制並發數量來確保性能不要炸裂以外，這邊還額外替事件做了個標記：

Because not all consumers need to consume republished events we can leverage the attribute feature of AWS SNS to add a replay attribute to republished events. Consumers can choose whether or not to subscribe to consume these events based on their needs.

因為並非所有消費者都需要消費重新發布的事件，我們可以利用 AWS SNS 的屬性功能，將重新發布的事件添加一個重播屬性。消費者可以根據自己的需求選擇是否訂閱並消費這些事件。

文章最後還列了一些他們應用 Event-Driven Architecture 的優缺點，例如可以根據時間段和事件抓出相關的資訊，但也提升了複雜度等等

有興趣的朋友可以再點進去閱讀～

昨天提到了發散思考，今天想接著轉貼一篇我覺得不錯的抒壓遊戲(?)
《自由書寫術》透過寫作大幅提升創造力的4個訣竅

自由書寫指的是使用紙筆或鍵盤，在某段時間之內不斷地書寫，直接把腦袋的東西一股腦地傾倒出來，任由自己隨意發散書寫的意思

基本的要點是，輕鬆寫，不要停地一直寫（或用電腦鍵盤打字），以思考的方式想到什麼寫什麼，設定一個20到30分鐘的時限，即使遇到阻礙或難題，馬上轉移焦點展開新的對話

在這個過程中要注意盡可能地專注在寫作上，而不要修改，否則容易讓腦子卡住當機

像這樣放手去寫的好處在於：集中思緒並且捕捉想法

作者提到自由書寫的兩大好處：寫字或敲鍵盤的動作可以有效集中思緒，它也可以給你回溯思考路徑的線索。

書寫的本身就會觸發思考還可以捕捉當下的想法，當你沒有明確頭緒時，更該持續書寫，讓文字和思考觸發你挖掘更深層的思緒。

我個人則是覺得在白紙上隨意地發散，有一種專注的抒壓感（像是心流那樣），並且也可以抓出許多自己的想法和思路

如果不知道怎麼開始，這篇文章也提供了一些作法。例如說，我們可以假裝自己在跟某個人對話，又或者是從「我覺得…」開場

有興趣的朋友也可以玩玩看這項腦力體操～

今天要轉貼的是魯迪老師的這篇：水平思考 Lateral thinking

這篇文章主要在說明水平思考與垂直思考。其中垂直思考指的是我們平常基於邏輯的演繹、歸納等等，而水平思考則是從主題開始，往四面八方發散出去的思考方式

文章裡面用看電影的方式來舉例。在垂直的思考方向下，我們想看電影的時候，可能就開始挑電影，然後挑電影院等等。而水平的話，我們可能就會想到爆米花

也因為水平思考是發散的，因此可以幫助我們從不同角度去理解和聯想，我們也就可能得到一些靈感，又或是理解某個問題的各種看法等等

例如原本某個需求已經有某種現行做法，但我們其實也可以質疑是否有更好的解決方法，這時候我們也許就有機會找到了一條新的觀點

但也要注意，發散之後必須要收斂。我們可以先利用水平思考的方式想到新的解決方案，再回到垂直思考來評估可行性和成本，這樣才能相輔相成，避免沒有結論

除了提出偶爾發散多想想(?)以外，我想轉貼這篇文章更多是因為下面補充的「六頂思考帽」

它可以幫助我們按照不同角度去發散出去，分別對應六頂不同顏色的帽子：

• 白色：從資料出發，只列出客觀的事實、數據和資料
• 紅色：從情緒和直覺出發，想想看對這個議題的感受和情緒
• 黑色：從悲觀的方向出發，想想會有什麼風險、怎麼樣行不通、要怎麼處理
• 黃色：從樂觀的方向出發，想想有什麼好處、會有什麼機會
• 綠色：從冒險精神出發，提出新的行動或想法、還有什麼可能性
• 藍色：思考解決問題需要採用的方式，整合上面各頂帽子的內容

六頂帽子可以幫助我們從客觀資料、情緒、風險、樂觀、其他角度等等面向去思考同一個問題，藉此得到更多角度的觀點

而且能夠讓我們一次只從一個角度思考（有其他人也一樣，這些角度的想法都混在一起的時候會覺得腦子亂哄哄的嗎？）

覺得針對某個問題或方案無從下手的時候，也許就可以試試看先戴上帽子想想

那麼，今天的轉貼就先到這邊。明天見 ><

補充閱讀；

• 《6頂思考帽》增進思考成效的6種魔法｜心得筆記 - 德瑞克的敏捷咖啡
• 六頂思考帽應用教學攻略：培養解決問題能力 - 翻轉教育

今天想轉貼最近認識的詞兒：
認識「稟賦效應」，就知道IKEA為什麼要設置這麼多體驗區

要認識稟賦效應是什麼，最快的方式就是認識文章內的這組實驗。參與者被分為兩組：

• 一組參與者會先拿到一個杯子，問他要多少錢才願意出售這一個杯子
• 另外一組參與者不會拿到杯子，而是問願意花多少錢買這一個杯子

而光是「有沒有拿到杯子」、有沒有覺得曾經擁有的這個差別，就可以在價格上產生 2 倍的差距

稟賦效應指的就是「厭惡剝奪」的現象，當我們擁有某項東西的時候，我們會覺得這個東西的價值更高

也因為這個現象，IKEA 等廠商開始利用體驗區、試用期等等方式，讓客人產生一種「已經擁有」的錯覺，藉此提高銷售率

看完這一篇，我在想：或許我們也會不自覺的認為自己掌握的技能、寫出來的程式碼的價值會比外面更高吧

又或者，原本應該擁有的周六假期就這樣被拿去補班了，原本放假的價值也就變得更更更更高了吧

今天要轉貼的內容應該是沒有懸念了，早上收件閘就已經被 OpenAI 的新東西塞滿

OpenAI 公布了能夠從文字直接產生影片的全新模型：Sora

展示影片可以直接從官網中看見：Sora - Creating video from text

效果有驚豔到我，尤其是光影的部份。如果想有個簡單的對比，可以看看去年 AI 所產生的爆吃義大利麵影片：

IT WAS HORRIBLE pic.twitter.com/YDAVcBE7fz

— 𝔹𝕣𝕖𝕖𝕫𝕪@𝕏 (@breezydev_) February 15, 2024

後續 Altman 有在 Twitter 上讓大家點餐，例如「兩隻黃金獵犬在山上錄 Podcast」：

https://t.co/uCuhUPv51N pic.twitter.com/nej4TIwgaP

— Sam Altman (@sama) February 15, 2024

雖然目前 Sora 還沒有開放給大家使用，而且影片還是會有些瑕疵，例如憑空變出勺子：

https://t.co/rmk9zI0oqO pic.twitter.com/WanFKOzdIw

— Sam Altman (@sama) February 15, 2024

但文字轉影片的未來應用感覺相當樂觀（相關的新創，例如 Pika 也得掰掰了） 很期待後續的相關資訊，等不及要做個馬斯克大戰關雲長了

這邊可能還是有一些比較硬核的朋友，不用擔心。這邊也轉貼推上大大翻譯的 Sora 技術報告：

• 譯文：视频生成模型：构建虚拟世界的模拟器
• 原文：video-generation-models-as-world-simulators

有興趣的朋友可以再看看～

開工第一天，看見好久不見的同事們，是不是很想…… 一起 Coding 呀？

今天要轉貼給大家的就是歡樂的你說我寫遊戲：
結對程設指南 (1)：如何結對 The Howtos of Pair Programming - fin

Pair 有蠻多好處的，例如說可以分享彼此的知識、消除單獨開發時的盲點、還有打破工程師們像風一樣的孤獨(?)

一般來說我們會讓其中一個人當駕駛，另一個人當導航；過一陣子再交換（或是寫到一半就戰起來，直接右轉練舞室）

而這篇文章還介紹了更多部份，例如結合 TDD 或番茄鐘，以及 Pair 的時候要注意的一些地雷區。

這個系列總共有五篇，後面還有說明好處、壞處、回顧等等，推薦可以按篇閱讀

更重要的是找到友善的搭檔朋朋，以及一顆願意嘗試的心

開工前一天適合複習一些舊聞，今天要轉貼的是這一篇：
How to shuffle songs? - Spotify R&D

簡單來說就是：

我們隨機撥放歌曲，但是使用者說他連續聽到同一個人的歌，感覺不夠「隨機」

雖然使用者說的話很像某種賭徒謬誤，但使用者永遠是對的

現在我們先洗個牌並且把同個作者的歌均勻打散，這樣就超隨機了～

之前只知道隨機撥放是洗牌不是隨機，但不知道原來連歌手都會幫你分布均勻。算是長知識了