負卅伍．-35．0xDD．11011101

人生繼續倒數

一年又過了
標題延續 2023 年開始
決定改用負數記錄未來人生
數字變小相較於正著數
還真的看起來比較舒服 XD

2024 蟄伏的一年

2023 年底原本待的團隊大搬風
輾轉到了老同學的底下
說是新的領域其實也不完全是
但總之 codebase 是我完全沒接觸過的部分
在龐大的程式碼海中
也只能慢慢地摸索
慢慢地一部分一部分掌握起來
整體來說不好也不壞

生活中的小突破

2024 年暑假在日本完成了一千五百公里的自駕行
農曆年跟小孩們玩了桌遊波多黎各
因為 2024 年市場熱度關係
每月紀錄的資產也第一次來到沒看過的數字
雖然還不到可以拍桌離職的坎站
但表示目前的配置是可以持續的
2023 年九月開始每周兩次線上英文課
也上超過一年了
當感覺生命能量比較低的時期
就盡量安排各種小小的成功讓自己能度過這段低潮

2024 總共上了 94 次課

對自己的生活記錄更多

2023 年十二月開始記錄作伏地挺身的次數
還用了 github 作自動製圖的版本 (感謝脫少提供 python code)
2024 年也開始記錄自己看過的作品
影集 + 電影 + 動畫 + 實境節目 + 綜藝節目
總共也看了 64 檔
最喜歡的電影：腦筋急轉彎1
最喜歡的動畫：迷宮飯跟膽大黨
最喜歡的影集：極度不妥

用 GitHub 做紀錄

2024 的觀看紀錄

再次閱讀藍色時期

已經想不起來理由
但我在 2024 年又閱讀了一次藍色時期
範圍是第一話到第七十話
在能量比較低的時候看
竟然莫名有被同理的感覺
許多對於自我的懷疑
其實大部分的人都會有
只是程度上不同
我不懂繪畫也不懂藝術
所以這部作品吸引我的
反而是對於主角心境的描述

藍色時期單行本 01 封面 [圖片來源：wikipedia.org]

Orange Days - 青春洋溢的一部劇

片尾曲 Mr.Children 的 Sign

今年農曆年假期間
在 Netflix 上看了多年前熱播的 Orange Days
不過我已經想不起來當年為什麼沒追這檔戲
但 Mr.Children 的這首 Sign 那時倒是聽了很多遍
好聽到我在 Netflix 看的時候幾乎每集的結尾都不會跳過
以下記錄些觀看後的心得

以下心得有劇情，防雷警告

以下心得有劇情，防雷警告

以下心得有劇情，防雷警告

以下心得有劇情，防雷警告

畢業前夕對未來的迷惘

主角是大學四年級的五人組
第一集就以主角去面試的情節開始
可以說從頭到尾都貫穿了「未來我到底想要從事甚麼」這個問題
與其說是一部校園愛情劇
從我大學畢業已接近二十年的角度來看
對未來的焦慮
或是自我探索的懷疑反而是劇情中很重要的一部分
當然五人組的深厚友情
也是這齣劇令人很舒服的一個關鍵
Orange Days 放映的 2004 年
也正是我即將升上大四的那一年
所以能理解為什麼在當時的同學間有那麼多的迴響

另一個有趣的自我觀察則是
會對於這樣青春的煩惱感到很可愛
但馬上會有另一個聲音提醒自己
這就是大多數這個年紀的人會煩惱的事情
別因為自己已經走過了
就用一種沒甚麼大不了
或是幾年後你根本就不會在意這種煩惱的態度去面對
希望在未來面對自己的孩子
或是有緣見面的高中大學生時
別當個輕視對方煩惱
令人討厭的大人

日劇基本的王道套路

Orange Days 也是充滿了很多標準的日劇元素
過分溫柔又陽光的男主角
各種巧合堆積而成的誤會或是緣分
重要關頭一定要用跑的
我覺得 Orange Days 的節奏已經算是沒那麼慢了
因此並沒有看到一半就想放棄的心情

大編劇北川悅吏子又一部手語劇

我看的第一部大量手語的日劇就是北川悅吏子的跟我說愛我
Orange Days 也是一部女主角幾乎沒有台詞的劇
兩齣劇都有很相似的橋段

其一
豐川悅司跟柴崎幸的角色都是後天因病而失聰
也都因聽不見後說話發音不標準被取笑
導致再也不開口講話了

其二
都在想要叫住對方的時刻
不得不開口喊了常盤貴子跟妻夫木聰
在我第一次看跟我說愛我時
著實被編劇這樣的設計打動
但 Orange Days 除了我已經預料到會有這個橋段之外
喊住妻夫木聰的那個鏡頭其實並沒有安排得很緊湊
反而是結局時柴崎幸開口說話那個鏡頭
非常令人感動

其三
都有摘樹上水果重逢的橋段
在跟我說愛我裡是蘋果
而 Orange Days 當然就是橘子了
也因此我看到最後這裡時
竟然覺得太偷懶了而笑了出來
當然也可能是作者本身想致敬自己的前一部手語劇吧

配角也是很有看頭

瑛太，上野樹里等就不提了
這次認真了看了一下成宮寬貴的資料
來自單親家庭
相依為命的媽媽在她十四歲時過世
之後他為了扶養六歲的弟弟輟學開始打工
後來有機會去舞台劇演出而被經紀公司相中出道
2016 年因為被信任的友人爆料吸毒
即使後來證據都顯示此事件為子虛烏有
卻因此選擇了引退
在 A-Studio 上當時主持人念了弟弟寫給他的一封信
很真心地感謝為了自己犧牲青春的哥哥
幸好 2024 年初他似乎也開始重新接洽演藝圈的工作了
期待看到他新的作品

成宮寬貴在 A-Studio 的段落

負卅陸．-36．0xDC．11011100

人生倒數開始

不知不覺一年又過了
今年開始決定改用負數的方式記錄未來的人生
以 2022 年台灣男性平均壽命 76.63 歲
四捨五入後的 77 歲做為原點
一方面提醒自己
其實無時無刻都在邁向生而為人的終點
另一方面是
不看正負號的話
每年的數字會一直變小
相較正著數看起來比較舒服 XD

2023 似乎是不平順的一年

2023 年職涯上有機會可以挑戰不同的角色
但自己力有未逮下以失敗作結
在一段時間的回顧跟省思後
對於未來工作上的期望做了些調整
也對自己有更多的了解跟想法
當然對於新的挑戰我仍是願意嘗試
只是更清楚知道自己想要的是甚麼

另外就是年底離開了原本的產品團隊
這是個從 0 到 1 一點一滴做起來的產品
也是第一次較完整體驗 SaaS Dev/Ops 的角色
學習到了很多也拓展了視野
要離開這樣的團隊真的很可惜
但只能繼續前進尋找下一個更適合投入的產品
是不是今年農曆年應該去拜拜點個燈 XD

重新記帳一年後的心得

四十歲的生日感言中提到又開始記帳了
目的之一是想了解自己的現金流
紀錄了一年，感覺還不錯
而且當每天每月的日常都以數字真實呈現時
還是挺令人驚訝的
此外也新增了一些 spreadsheets
來更了解自己的財務狀況
今年打算延伸多增加一點點細項
還想做些小工具讓每月更新時可以更方便

新增的財務狀況總表，資料的來源都是其他張 spreadsheets

新增的每月現金流量表

新增的現金流量表總表

新增的月支出統計表，使用十二個月的移動平均數

新增月支出統計表的原始數字

每月現金流的紀錄對我影響最大的
是現在買東西前會下意識地暫停一下
思考這筆花費到底是想要還是必要
這不代表變得更節儉或是更小氣
而是內化成每次消費前多思考

比方目前的 PC 是 2014 年八月底買的
當時的系統碟是用 120 GB 的 SSD
以現在來說算是挺不夠用的
去年幫老婆把系統碟從 HDD 升級成 SSD 時
學了怎樣 clone 系統碟達成無痛轉換後
一直很想把自己 PC 的 SSD 換掉
看著看著也過了半年還是沒買下手
大概就是這種感覺

更有意識地做日常的事情

去年盡量讓自己在吃飯的時候
不同時做其他事情
例如滑手機或是看影片
也盡量要求自己有意識地專注在咀嚼跟品嘗食物上
雖然無法每次都做到
但開始喜歡這樣專注的時刻
食物咀嚼的更徹底
減少唏哩呼嚕囫圇吞棗的進食
不過我們家在外面吃飯時
本來就是很專心吃飯的類型
所以期許自己在家裡時可以更專注地吃飯

去年四月開始整理手邊的一些筆記
目的是好好地重新建立自己的知識庫
原先以 Google Docs/Spreadsheets 方式記錄的個人財務
以及用 Trello 做的技術筆記
現在都利用 Notion 內建的功能
或是把連結都整理在單一頁的方式統整起來
讓自己在使用或搜尋這些日常記事時
能夠更有效率
此外也慢慢新增一些紀錄
像是讀過的書
看過的影集電影動畫
等等其他在意的事項
也對 2023 做了簡單的年度回顧
這些都是為了讓自己更有意識地活著

希望這些記錄在未來都能成為很棒的回憶

個人財務規劃的主頁面

記錄讀書心得的頁面

2023 年度簡單回顧

四十．sì-tsa̍p．forty．XL．0x28．101000

四十歲的線掃過一整年

從 2022 年的九月開始
時間就像一道射線般
在日曆上一天一天地掃過
跟我同屆的朋友同學們
都會被這道四十歲的射線慢慢地照到
1983 年暑假出生的朋友最幸運
因為他們會看著熟識的大家一天一天地變成四十歲
直到最後掃中自己

似乎可以理解為什麼會有人辦大壽

四十年的光陰，多不容易啊
現在最夯的 MATANA 六間公司
也只有微軟跟蘋果超過四十年
能存活這麼久是很不容易的事情
看著國內國外每天逝去的生命
除了感恩各種有形無形的力量外
最該感謝的就是自己的父母了吧
這種感覺在自己也成為了父親後格外的深刻
如果有幸能再活十年, 也許真的可以考慮辦大壽
除了恭喜自己又活過了十年
最重要的大概也是告訴自己的至親們
謝謝你們, 你們看看啊, 我又活過了十年

資產負債表的緣起與演進

我在 2017 年六月的時候
讀了 MJ 林明樟老師在臉書上的兩篇文章

• 給30歲以下年輕人的10個資產配置建議
• 只會記帳存不了錢，請您這樣跟我做才有機會存到錢

大意就是個人財務狀況也可應用企業的財務報表做紀錄
於是開始建立自己的資產負債表 (balance sheet)
並每個月固定更新一次

其實我在 2008 開始工作時
就有做簡單的記帳
為什麼要記帳已經想不起來了
但慶幸的是當時使用 Google Sheet 做紀錄
所以十幾年後還是可以看到過去自己的消費情況
2011 年的檔案是最後一筆
現在也想不起來為什麼停止記帳了
大概是當時並沒有從這樣的記錄中得到些甚麼吧

然而有趣的是
2023 年我又開始記帳了
只是這次開始的原因跟目的很明確
在 2022 年上了 MJ 林明樟老師的超級數字力線上版後
單純的想知道自己目前每個月的現金流狀況
雖然從資產負債表可以觀察到總資產的變化
但無法從表中了解自己現金流的情況
又因為現在的付款方式以信用卡為大宗
所以記錄起來變得簡單很多
只要把每個月從 ATM 領的現金
以及每個月信用卡繳款的金額都記下來就好
初步也只是想了解現金流
所以就沒有分門別類地記錄每筆消費的細項
實行起來非常輕鬆
預計一年後就有足夠的資訊來檢視自己的支出

2008 年的記帳本，一個月竟然只花不到一萬五 XD

2017 第一版陽春的資產負債表

2023 年的資產負債表

資產部位的控管

在四五年前有認真地讀過一次綠角的"資產配置初步"系列文
但當時就只是讀過有個概念而已
並沒有認真地去思考自己的資產配置該調整成怎樣
只要求自己必須有六個月的緊急預備金
剩下的則是主動基金的定期定額
與公司開放認股時的投入
活存的現金部位其實蠻高的

2021 年又再次讀了一遍
這次認真地做了筆記
並參考系列文來思考自己的資產配置
訂定一些計畫來慢慢地調整
2022 年自己持有的某公司股票有明顯的成長
該檔股票某次的回吐讓我發現該項資產的佔比
對個人總資產的波動影響變得很大了
再加上我本來就沒有花很多時間在追著公司或產業的消息
幾番思考後決定將該部位再平衡到其他標的上
過往讀過聽過很多部位控管觀念
也以為自己有理解這些
然而實際體驗過一次才發現
了解觀念跟實際經歷的體感還是有很多不同

遺囑與數位遺產

其實多年前的三十三歲生日感言中
就提到我有去稍微了解過遺囑的規定
接下來每年的生日其實我都會想起這件事情
但總是查完細節後就又擱置著了
四十歲的這年終於試著提起筆寫了第一版的遺囑
倒也不是有甚麼財產分配的問題
反而是對自己的一種提醒
提醒自己每天都可能是最後一天
會傷害到至親們情感的話或事情少說少做
多跟自己愛的人講講話或是聽聽他們講話

數位遺產的事情我也有在思考
因此研究了一下 Google 閒置帳戶設定
其實網路上也有很多文章甚至書籍
在討論關於數位遺產的議題
甚至我還讀過後悔看了長輩遺留下來的網路帳號的內容
因為看到了他認為不知道會比較好的事情
總之還可以再多了解多想想
活著的至親們會希望你留給他們的是甚麼

別再去評論其他人的人生

忘了從何時開始
我刻意地讓自己不在公共討論的地方留言
網路新聞平台﹑臉書粉絲團﹑Instagram﹑twitter 等等
理由倒也蠻簡單的
我不會因為留了意見而真的得到甚麼
我也不覺得有人會因為我的意見而得到甚麼
與其在網路上對不認識的人做評論
不如把時間花在現實生活中看的到遇的到的親友同事上

青春之所以耀眼
是因為它浪費起來格外浪漫
進入了人生的下半場
(嚴格來說 39 歲的時候就算開始下半場了
因為台灣男性平均壽命約為 77.6 歲)
時間越來越珍貴
分分秒秒只能盡量放在自己最重視的事情上
人最終只能選擇做自己
做自己當下覺得最好的決定
做自己當下覺得已經最對得起自己的決定
剩下的真的都無法控制
行有餘力可以多同理別人
但人生在世，最終要面對的都是自己
也只有自己可以陪著自己面對

以上，給四十歲生日的大叔

個人數位遺產 - Google 閒置帳戶設定

現代人有太多的個人資料或足跡
是透過數位的方式留存在這個世界中
我在大學時就曾去信詢問 ptt 站方
有沒有可以保留已逝世朋友的 ptt ID 相關站規
當時得到的答案是否定
也許現在有更完善的規定
可以讓本人有機會決定哪些東西要留下給親人

目前的社群平台幾乎都可以設定帳號代理人
而我使用率最高且資料最多的 Google 也有類似的功能
以下是我實測 Google 閒置帳戶功能的紀錄

Google 閒置帳戶設定

首先進入 Google Account 管理頁面
點擊 "資訊和隱私權" 後，找到 "規劃自己數位遺產的處理方式"

資訊和隱私權 - 規劃自己數位遺產的處理方式

點進去後，就會出現閒置帳戶管理員的畫面
在此能夠啟用你的計劃
可以決定在帳號閒置多久之後
利用簡訊通知設定好的某組電話號碼
也可以透過信件通知某個 email

閒置帳戶管理員

你可以設定使用者在帳戶進入閒置後
能夠存取的資料有哪些
項目很多，我只有實驗郵件跟 Google Drive 的部分
有興趣的人可以自己測試其他服務的資料

選擇在帳戶閒置後，要分享的資料

閒置帳戶的通知以及資料的存取

當帳戶進入閒置狀態後
系統會發一封信件通知你當初設定的 email
並且在信件中有個超連結
可以讓對方下載你開放給他存取的資料

帳號閒置狀態通知

點擊超連結會開啟下載資料的畫面
系統會需要對方用你設定好的電話或是 email 做身分認證
認證完成後就會列出你設定好要分享的資料有哪些
對方就能在此下載
同一個畫面系統也會提醒下載資料的期限

下載閒置帳戶分享的資料

利用電話號碼驗證身分

輸入驗證碼完成認證

身分驗證後即出現可下載的項目

實際下載後的檔案內容

每個服務下載後個別是單一個 zip 檔
不確定若資料量更大的話
會不會分成好幾個 zip 檔
zip 沒有設定密碼，所以可以直接解開
依不同的服務會有不同的資料夾結構
在此展示郵件跟 Google Drive 的內容

閒置帳戶的郵件資料

閒置帳戶的 Google Drive 資料

Modern Love

幾個月前終於看完了這個劇集的第一季
是部輕鬆的小品
每個單元的元素都蠻不同的
最喜歡的三個單元是

• 第一集, When the Doorman Is Your Main Man
• 第七集, Hers Was a World of One
• 第八集, The Race Grows Sweeter Near Its Final Lap

想記錄自己覺得動人的台詞

第一集的女主角發現 Doorman Guzmin 很會看男人後
所以每次有新的關係，就會刻意讓 Guzmin 幫他看看
最後的男友通過了 Guzmin 的 "test"

Guzmin: You passed it.

Man: Cool. What did I do?

Guzmin: Nothing. I saw in her eyes, the moment I saw her.

Maggie: Guzmin…

Guzmin: I was never looking at the men, Maggie. I was looking at your eyes.

第八集女主角在老年再婚的丈夫的葬禮上

Margot: Old love is different. More realistic maybe. When Ken and I met, we had already been through many ups and downs in life, and we had learned how to compromise, and we had survived loss and mistakes. And somehow we felt if this relationship failed, we would survive this, too.

Margo: I’m not so sure about that anymore.

另外最後一集最後的橋段也很有巧思

THE FIRST SLAM DUNK

在 2023 小學生休業式的當天
終於帶著小孩們去看期待已久的灌籃高手電影
在此紀錄一些感想

2021 年宣布電影版開始製作

【スラムダンク】

映画になります！#slamdunkmovie pic.twitter.com/jWqvCnASxj

— 井上雄彦 Inoue Takehiko (@inouetake) January 7, 2021

2021 年一月
作者井上雄彥在他的 twitter 上宣布了電影版製作中的消息
全球所有灌籃高手粉絲大概都瘋了
畢竟這是第一部由作者井上雄彥親自擔任編劇跟導演的電影版
粉絲們都對此抱持著莫大的期待

2022 公布更多消息

お知らせです！
公開をどうぞお待ちください。

▼2022.7.7 19:00 特報解禁https://t.co/EWb6DIuNDE#SLAMDUNK #SLAMDUNKMOVIE pic.twitter.com/uSsMhoH0o4

— 映画『THE FIRST SLAM DUNK』公式 (@movie_slamdunk) July 2, 2022

終於在 2022 年七月
我們等到了更多的更新
這次官方釋出了電影標題以及更多的細節
包括了電影片段以及海報們
最重要的是上映的日期在 12 月 3 日！！！
雖然還沒等到台灣代理會在何時上映
不過我想粉絲的心情就是這部電影真的要實現了！
但 3D 的風格讓大家開始對這樣的畫風有很多的忐忑
(以下是湘北五人的海報圖)
宮城，三井，流川，櫻木，赤木

日本上映在即，影片的釋出卻讓粉絲更擔心了

隨著 12 月 3 日即將到來
越來越多的內容被釋出了 (巴哈上的介紹)
雖然仍是期待
但 3D 的畫風跟故事的編改
在在都讓喜歡灌籃高手的粉絲們有很多的擔憂

以下心得有劇情，防雷警告

以下心得有劇情，防雷警告

以下心得有劇情，防雷警告

以下心得有劇情，防雷警告

終於看到了實際的作品

在 2023 年 1 月終於帶著小孩們一起去看了這部電影
在這之前聽到了許多不同的聲音
我也特別在前一天把山王戰又複習了一次
我在 2020 年生日買了一套灌籃高手給自己
因緣際會也讓小孩們都很熟系這個故事
看完後，男孩跟我說很好看，女孩跟我說中間有段睡著了 XD
最後說說我自己的感想

首先我覺得這是部服務粉絲的電影
因為對於許多人物為什麼是現在的樣子
並沒有做太多的鋪陳
以至於我覺得沒有讀過漫畫的人進場
應該是相對不容易感受到情緒的
作者井上雄彥也有說過他為什麼想以宮城為這部電影的主角
(可以在網路上搜尋)
這點對於原本漫畫讀者來說會有點適應困難
因為山王戰很多經典場景都是圍繞在櫻木本身
而電影考量篇幅刪減了許多粉絲期待的畫面
有點可惜

3D 的風格不知是否因為大螢幕的關係
原本的擔憂沒有在觀影的時候出現
唯一奇怪的點是一開始會給人有張數不夠的感覺
但隨著進入球賽後，這個感覺就消失了
不確定是否是製作上的問題抑或只是眼睛習慣了
最後就是井上雄彥仍是以藝術的方式呈現了這次的電影
在比賽開始球員登場的部分採用了手繪的風格
而最經典的那幾十秒鐘
漫畫裡面沒有任何對白的那五十幾頁
在電影也用了很特別的風格去呈現
但好可惜，最經典最感人的那個擊掌似乎力道差了一點

整體來說我會覺得這部電影有七八十分的等級
我也會想找機會去看一次日文配音
新的主題曲跟片尾曲我覺得選得還可以
當然比不上舊歌經典啦
只是我覺得也是非戰之罪了

主題曲 LOVE ROCKETS，球賽的場景會出現

片尾曲第ゼロ感，我覺得節奏很好聽

世界が終るまでは…，經典中的經典

First Love 初戀 - 日劇

花了兩個周末的時間把這部劇看完了
上一次看日劇已經是今際之國第一季了
(話說今際之國第二季山 P 賣肉橋段太有誠意了吧)
先講我個人的結論
如果真要替這齣劇打分數
滿島光演技 100 分的話
劇本大概是 70 分，宇多田的歌可以給 90 分
為什麼宇多田光的歌這麼無敵我卻只給了 90 分呢？
(其實每次 First Love 響起就是無敵了，有這首歌的場景大概可以給 1000 分)
因為出現的次數比我想得少太多了 XD
First Love 當時作為「魔女的條件」主題曲而爆紅
其實後來也有另一齣深田恭子主演的日劇「First Love」
主題曲也是宇多田的 SAKURA Drops
只能說當時宇多田真的是有夠紅

以下心得有劇情，防雷警告

以下心得有劇情，防雷警告

以下心得有劇情，防雷警告

以下心得有劇情，防雷警告

日劇經典元素滿滿

這是一部充滿經典日劇元素的劇
一見鍾情、初戀、遠距離、失億、時空膠囊、手語、跑步等等
還有時不時會出現很類似說教的台詞
(看到打手語的地方，跟我說愛我的主題曲馬上就在腦中響起)
但也因為經典，所以步調也跟記憶中的日劇很像
在現在這個資訊爆炸，凡事講求效率的時代
整體節奏還是相對的偏慢了點
我甚至為了怕弄壞歌突然出現的地方
整部劇都維持著一倍速在觀看

滿島光以過人實力凱瑞整齣劇

滿島光演技很好
或者換句話說，這齣劇的看點就是看滿島光 XD
演貴婦，然後失婚女工，還有 35 歲計程車司機都很像
第八集的兩場哭戲
以及第七集跟兒子相關的哭戲都很厲害
當然男主角佐藤健
跟飾演男女主角青春時期的木戶大聖跟八木莉可子表現也很棒
第一集看到一半稍微踩了一點點雷
但為了可以帶著新鮮感看下去
馬上有意識地停止看介紹的文章

雖然老哏但還是讓人看得很舒服

各種橋段雖然相對老哏
但不得不說有很多地方真的編排的很用心
男女主角的設定是跟我同年出生的
所以有很多的人生經歷是很類似的
宇多田爆紅的時代，後來復出後的第二張專輯初戀
311 大地震，我竟然沒有第一時間想到他們約定 311 的劇情目的是這個
還有各種刻意在 2018 與過去時間線埋哏的細節
利用挖出時空膠囊表示女主找回了記憶等等
都讓人在看到的時候非常佩服編劇的巧思
劇情最後也把編劇認為 COVID 對世界跟人與人關係的影響表達出來
網路上很多文章跟 youtuber 都有對劇情上的小地方做說明了
有蠻多整理的不錯

即便已經猜測的到劇情走向，還是被騙眼淚的地方

首先是 First Love 一響起就無敵了
聽到這首歌，劇情怎麼樣都隨便了
不得不說真的會有這種感覺
也許這就是這首歌的強大之處吧
最後 CD player 響起 First Love 然後女主角記憶湧入的那幕
也是直接眼淚就隨著滿島光精湛的演技一起流了下來

再者就是各種親情橋段
女主角在小孩生日那天把自己蛋糕上的草莓分給小孩
因為爸爸曾經跟他說，父母就是會這麼做
小孩把草莓回切一半餵給女主角吃
滿島光噙著眼淚地說，「太好吃了」
看到這橋段完全忍不住眼淚
更別說接著就是因為經濟因素
不得不把小孩的親權交給親生父親
第七集一整個大淚崩

第五集佐藤健在妹妹的婚禮上
一邊打著如舞蹈般的手語
一邊說出對妹妹的疼惜與祝福
這一幕也令人對這樣的手足之情非常感動
同一集最後滿島光在看到聽障的妹妹時
很自然地打出了手語
這樣劇情上的小設計也令人非常激動
在在暗示所謂的肌肉記憶
也是最後女主角找回所有記憶的重點之一

一切看似不經意的小細節，其實都是想傳達命中註定的感覺

有許多人覺得劇情應該停在第八集就好
其實我在看第一集時也直覺最後應該會是個悲劇
至少不會是皆大歡喜的結局
或許編劇覺得
還是要給這對辛苦的男女主角有個好的結尾
看完第九集後真的會覺得
好啦，你男主角都這麼辛苦拼命了
值得一個這麼完美又甜滋滋的結局
我想就跟另一部電影「愛．重來」類似
兩個原本相愛的人
即使記憶消失重新再來一次
還是會有吸引彼此的個性或特質
愛．重來是男主角一直都在，只是最後選擇了放手
而女主角則又重新再次愛上男主角
(這部電影並沒有恢復記憶)
First Love 則是各種巧合發生後
把兩個原本相愛的人又重新用「運命」牽在一起

NoEstimate - Allen Holub

上週同事分享了這個 Allen Holub 的影片
花了一點時間觀看並做了些筆記
在此紀錄一些小小心得

估算永遠都是在猜，而且總是猜不對

Allen Holub 說應該不要再對 tasks 做估算
因為從過去經驗來看
永遠都在猜而且也總是猜錯 (就是說估不準啦)
而你一旦有了估算，就會很自然地出現 deadline
有了 deadline，團隊就很容易被迫加班為了趕上 deadline
因此他認為估算導致了團隊無法 agile

加入機率在估算裡面

他提到 Steve McConnell (Code Complete 作者) 在 Software Estimation 書中提到一些方法
The Clean Coder (Uncle Bob 的書) 裡面也有提到 PERT
簡單說就是你不能只估一個時程
你應該要附加上這個時程可能實現的機率是多少，例如 20%
但 Allen Holub 說其實聽的人對 20% 這個數字是沒有概念的
他用可以裝填五顆子彈的左輪手槍來說明機率
(我覺得很棒的例子 XD)
當這把左輪手槍裡面只裝著四顆子彈時
你用這把左輪手槍指著自己的頭開槍
成功 (存活) 的機率就叫做 20%
一顆一顆拿掉機率就變成 40% -> 60% -> 80%
你說時程有 80% 機率會成功實現
跟此時開槍有 80% 不會轟掉腦袋
講者說就算是 80% 他也不會覺得開心 XD
很好的體現了這樣的估算其實也不一定有幫助

建議數有幾個 stories 不要用 story points

作者提到使用 story points 有個目的是要模糊估時這件事情
然而因為 story points 是個數字
很多時候會自然地被轉換成估時
所以他建議改用 Trivial、Easy、Normal、Hard、Herculean、Don't Know
這樣的字眼來避免 story points 變成工時
但你仍會需要一個可以評估的基準來做很多商業上的決策
他建議使用 projection 的方式 (可以從 24:28 開始看)
就是利用一個 iteration 可以完成多少個 stories
與 backlog 中的 stories 的總數去做 projection
你會得到一個做完所有 stories 可能的時間點
而根據研究結果發現用 stories 總數與 story points 總數
彼此的誤差大概只有 7% ~ 8% 左右
因此他建議不要再做 story points 的估算
(當然估算 story points 的過程帶來的溝通效果還是要做
只是不再要大家估算這個 story 是多少 points)

在前公司待的團隊一開始 team lead 就說我們不要估點數
大家有個默契就是一張票盡量評估約三天左右完成
然後就這樣一直執行了兩年多 (今年過完就三年了)
超過三天還是沒做完怎麼辦
通常會看情況是否可以拆開分段做
還是真的就是要多過三天
那就繼續做到完為止

卅八‧陰陽重逢‧原點

又回到最初的起點，記憶中你青澀的臉

人生第三次農曆與國曆生日同天
【參考：人出生多少天後，農曆生日和國曆生日會在同一天？】
當天星期六
因為有事不回媽媽家吃晚餐
就打了電話通知一下
沒想到我媽竟然問「你知道今天是你生日嗎？」
（老人家只會記得要幫你過農曆生日）
頓時有種，父母果然都會把小孩的事情惦記在心上的感動
時間再久都一樣
就如同現在的自己
我的 Google Calendar 上充滿了大大小小孩子的事件
從看醫生到學校的各種活動
也許等女兒兒子十九歲的時候
我還是會記得他們剛出生那一刻的臉

2020．不平順的一年．變動的一年．值得紀錄的一年

去年實在是各方面都非常特殊的一年
在年初農曆年期間疫情開始發展
接著世界各地的狀況嚴重到超乎想像
台灣則因經歷過 SARS 使得政府部門反應迅速
得免於封城導致經濟受到衝擊
過完年後 work from home 了七周
世界各大企業忽然發現遠端工作還能維持夠高的收益
開始了一系列工作制度上的轉變
現在回頭看，一切就像夢一樣
也證明了在這個時代裡
如何快速地因應環境變化
調適自己到最適合的狀態才是生存的重點
（很不幸的台灣在 2021 年五月底時進入三級警戒，開始各種限制
目前個人希望疫苗施打率能慢慢變高，九月時可以順利開學）

萬般帶不走　唯有業隨身

這是大隻佬電影裡面講因果的台詞
我是亂用當成對工作職涯的體悟 XD
公司去年底也開始一系列改變
當然大象再怎麼會跳舞
也不是 2020 年底說大家一起 666 起來
然後 2021 年初開始全部員工就可以刷一波 666
(這比喻好像有點宅 XD)
總之呢，可能因為我才換工作一陣子吧 (即將滿三年)
對於各種轉變
我倒是沒有太多的想法
直接想到的就是
在公司內曾經的各種成就或是輝煌表現
你是永遠帶不走的
唯一能跟著你一輩子的
只有在工作上學到的技能跟經驗
以及你累積的各種人脈與 credits
拿掉了公司，你還能發揮多少價值呢？
91 哥常講一句話我很喜歡
在公司裡你只要跑贏同事就不會被熊吃掉
在外面則是要跑贏熊的
期望自己不要做只想跑贏同事就好的人

新家，持家

繼兒子出生那年，花了人生最大一筆錢買車後
2020 年又破了人生紀錄花了更大的一筆錢
就是成為房貸一族
因為房子接近三十年都沒有重新整修過
還花了一些時間，以及又飛走了更多的鈔票來整理
這件事情從最初到最終的過程
在在體現了夫妻就是一個團隊的概念
很多時候也沒人知道正確答案
所以兩個人要能一起承擔一起犯的錯誤
就像結婚紀念日時在 facebook 寫到的
"不是要你十項全能，而是團隊需要的時候你願意"
大家都會有很煩很不想處理事情的時候
只要有人可以適時的幫忙一下
相信彼此都會將心比心，互相在對方需要支援的時候伸出援手
也是在真的有了自己的家後
才更深刻理解了「扞家」這個詞

孩子走進自己的世界

今年生日 我送了自己一套灌籃高手 這一套是 2018 年出的新編版 內容沒有改變 但是每一本的章節有特別分類過 所以頁數不同...

由 Chin-Yi Cheng 發佈於 2020年11月30日 星期一

以往帶著小朋友體驗各種新事物時
有點像是我在他們的世界裡，陪著一起探索戰爭迷霧
他們的角色是主人
我就像是一個進入他們建構中世界的旅人
但有趣的是，他們在看了灌籃高手後
跟我聊著裡面的劇情時
我有一種他們踏進了我的世界的感覺
因為不是我主動推薦他們去看
我只是買了我喜歡的作品擺著
他們無意間閱讀後也喜歡上灌籃高手
最近剛好東森電影台在晚餐時間時也在播放動畫
我們全家就一起看一起笑
這是當時買這套書當作生日禮物時沒有想像過的
無心插柳竟然變成比收藏的實體書還珍貴的禮物

最後用跟三八有關的一首歌
祝自己卅八歲生日快樂

趨勢內訓 - Team Building 贏向 2021

標題是這次工作坊的主題 XD

2020 最後一周
團隊特別安排了一個整天的工作坊
帶這個體驗式學習活動的是鈺勤的魏大統老師
過去我也有參加過類似的訓練
不過這一次有蠻多活動都蠻有意思的
特別寫文章記錄一下一些感想
(其實是後來發現沒有寫下來很快就會忘記了XD)

防雷警告

我是建議不要特別去找答案
畢竟這些活動的設計
有點故意要當下讓你去體驗碰到問題時
心理或身體最直覺的一些反應
藉此觀察自己的盲點等等
以下我會先以記錄活動的基本介紹
最後再放上查到的一些資料跟個人的感想
要躲雷的就不要看到最後了

Four Square Puzzle

這是一個請大家等分圖案的小謎題
我查到的名稱叫做「四等分正方形 puzzle」(不是很確定原出處)
會要大家一起想怎麼用不同的方式等分這幾個正方形的白色區域

均等三角形

艾雪 Reptiles [圖片來源：wikipedia.org]

講師將我們分為三組
每組用小的 15 片特殊巧拼 (三種顏色各五片)
拼出他要求的「均等三角形」
最後大家再一起用大片的合拼一個均等三角形

特殊的巧拼可以在網路上買到 (蜥蜴拼圖 [小] [大])
這個圖案是荷蘭著名藝術家 M. C. Escher 的一個版畫作品 Reptiles
故宮 2014 年的時候有他的展覽 (艾雪的魔幻世界畫展)

Balancing Nails Puzzle

也是一個實體的小謎題
講師把大家分為三組
每組有一塊木頭
木頭上已經釘好了一根鐵釘
還有十根分開的鐵釘
目標是把十根鐵釘都放上那根釘子

DISC assessment

DISC 四大人格特質

前公司 VIVOTEK 的面試都會請應徵者做的一個分析
不過這次老師給的題目跟 VIVOTEK HR 的題目不大一樣
總之就是一般的人格分析

團隊領導的五大障礙

團隊領導的五大障礙 [圖片來源：博客來]

五個障礙是有先後關聯的
分別是：喪失信賴、忽視成果、害怕衝突、缺乏承諾、規避責任
書裡面有一個 checklist 來讓你知道你的團隊中該加強甚麼部分

Johari window

Johari window

心理學家 Joseph Luft 與 Harry Ingham 提出的
主要是想表達自我認知與他人認知的差異
進而鼓勵大家如何調整自我達到更好的工作氣氛與溝通效率

蘋果鳳梨遊戲

一個蠻有趣的破冰遊戲

Cycle time puzzle

Cycle Time Puzzle [圖片來源：mikecardus.com]

用十四條長短不一的木板
一開始由長到短從下往上堆疊在一起
看看團隊可以在多少時間內組合成跟圖一樣

以下雷區

感想與資料

Four Square Puzzle

參考資料：https://www.google.com/search?q=four+square+puzzle+area
不要被過去經驗限制
這遊戲在第三個項目時
會出現一個比較複雜的答案
導致你在最後一題時卡住
但是其實最後一題很簡單
曾經讀過一本書 - Think Again：避開錯誤決策的四個陷阱
裡面就提到了誤導性的經驗
過去成功經驗有時候會造成失敗的原因
所以處理問題時要常常提醒自己跳脫直覺或是經驗
這也是我喜歡團隊群體智慧的一個原因
因為別人有機會看到自己的盲點

均等三角形

這活動其實很多課程或工作坊都會有類似的
就是對於提出需求的人
你有沒有問清楚他要的到底是甚麼
其實定義上根本沒有均等三角形這種東西
但我們接到題目後
就很自然地認為是正三角形
所以導致了很多的浪費與重工

Balancing Nails Puzzle

參考資料：https://www.google.com/search?q=balancing+nails+puzzle
這裡老師想提的是面對困難的態度
一開始花了五分鐘
老師會暫停請每個小組討論要不要再繼續
大家可能會因為時間（接近休息時間了）或是其他因素
就想說放棄好了
而一個人表現出放棄的念頭時
會很明顯地影響到團隊裡其他人
另外就是一但決定放棄
接著也不會再去想方法達成了
當然我覺得停損也是蠻重要的考量點

DISC assessment

隨便 google 都可以找到很多題目，就不列了
一開始老師說有沒有聽過可以把人的個性分成四類的方法
我第一個想到的就是星座 XD
DISC 粗略把人分為了四大類
能稍微讓你了解同事們的人格特質
有助於理解大家的使用手冊
有趣的是
我在前公司測了不只一次
剛進公司的時候好像是貓頭鷹或無尾熊
隨著年資增長以及擔任管理職後
開始變成老虎或是孔雀

團隊領導的五大障礙

這本書當時在 VIVOTEK 的讀書會中有讀過
書中以一個虛構的公司帶出作者想表達的中心思想
用故事的方式讀起來比較不生硬
但是相對的有時候會讓人覺得讀了很多不相關的東西
書中作者有給出一個高效團隊評估問卷
總共有十五個問題
有興趣的可以用書名加上 team assessment 去搜尋
這個活動因為我看過書了所以沒有新的體悟
難的地方在於你要怎麼塑造環境來建立出這樣的團隊

Johari window

參考資料：
https://zh.wikipedia.org/wiki/%E5%91%A8%E5%93%88%E9%87%8C%E7%AA%97
https://en.wikipedia.org/wiki/Johari_window
這也是我之前聽過的
最先是在趨勢 TLC 內訓中看到
概念很簡單但是卻用了一種很好理解的模型來說明
重點是你應該要多說自己的想法
以及多聽其他人對你的意見
才能將所謂的開放我 (Open Self) 擴大

Cycle time puzzle

參考資料：https://www.google.com/search?q=cycle+time+puzzle
最後這個活動最有意思
當然是關於團隊合作﹑集體智慧﹑目標﹑向心力﹑持續改善等等有關
不過這類活動最難的地方
還是你要怎麼把在過程中體悟到的帶到平常的工作
非常需要自覺跟自我反省的功力

利用 GitHub Actions 發布 React app 到 GitHub Pages

最近有佛心同事開了 React 教學工作坊
赫然發現自己已經好久沒有寫 UI 相關的程式了
果然是用進廢退
不過上了幾次課之後
一些相關的感覺又慢慢找回一點點

上完課後自己又重新作了一次工作坊上的 lab
忽然想到
若是要給別人看看自己寫的 React app
能否用 GitHub Pages 當作一個 demo site
又想到可以用 GitHub Actions 來佈署 GitHub Pages
基於上述的想法
蒐集了一些資料來玩玩看

首先是將 React app 放到 GitHub Pages 上
主要是參考西打藍 Siddharam 這篇文章 - 將create-react-app佈署到GitHub Pages
不過裡面是在 local 利用 gh-pages 這個套件
作出發布用的資料夾後
把東西推到自己 repository 的 gh-pages branch 內

設定 dev 相依套件 gh-pages 以及 homepage 屬性

接著要利用 GitHub Actions 作到自動佈署 GitHub Pages
參考找到的 Christoph Michel 這篇 - How to deploy a create-react-app with github-actions
裡面提到要讓 GitHub Actions 能夠作 git push
必須設定一個 deployment key
文章內有說明步驟
或是參考 GitHub 官方文件也可以很輕鬆完成

設定 deploy keys 跟 repository secrets

不過 Christoph Michel 那篇介紹的是
當每次 git push 到 master branch 時
會自動觸發 GitHub Actions 來發布
但我想要一種情境是
我可以手動選擇要發布的 branch
例如我可能作了兩個版本
個別放在 branch A 與 branch B
我想要隨時可以手動發布 branch A 或是 branch B 到 GitHub Pages
參考 Adam McArthur 這篇 - How to Manually Trigger a GitHub Actions Workflow
學到了一個手動觸發的 event - workflow_dispatch

手動觸發事件 - workflow_dispatch

最後放上這個 repository 給有興趣的人參考
https://github.com/LaurenceCheng/react-workshop-2020-winter

參考資料：

1. create-react-app docs
2. 將create-react-app佈署到GitHub Pages - 西打藍 Siddharam
3. How to deploy a create-react-app with github-actions - Christoph Michel
4. How to Manually Trigger a GitHub Actions Workflow - Adam McArthur
5. Working with GitHub Pages - GitHub Docs
6. Managing deploy keys - GitHub Docs
7. Manual events - Events that trigger workflows - GitHub Docs

在 Windows 上用 PyCharm 開發, 在遠端 Linux 上執行

情境是這樣的

我想在 Windows 上使用 JetBrains 的 IDE - PyCharm 作開發
但是在遠端的 Linux 上執行開發好的 Python 作測試

基本上 JetBrains 的文件算是寫得蠻清楚的

首先先看一下 Linux 上的環境大概是怎樣
我以一台 AWS EC2 的機器當作遠端的 Linux
怎麼開 AWS EC2 跟怎麼連上開好的 EC2 我就不說明了
可以去看 AWS 的文件 [Launch your instance][Connect using WSL]
還有一個等等會用到的 [Connect using PuTTY]
裡面有教怎麼用 PuTTYgen 把 private key 從 .pem 轉出 .ppk 檔
後面 PyCharm 連線時會需要 .ppk 檔

首先，在遠端的 Linux 上安裝好 Python 3.7.9 以及作好 venv 的設定
我們放了一個測試的 mytest.py 在 /home/ec2-user/ec2_python3_workdir 中
當作遠端的環境

遠端的 Linux

接著啟動 PyCharm 開啟本機的對應的資料夾
我的情境是本機與遠端的資料夾
是同一個 repository 的 working copy
(不過後來發現其實遠端不必是 git 的 working copy)

啟動 PyCharm 選擇開啟本機資料夾

進入後可以發現有 Python interpreter 設定的警告訊息
接著進入 File 選單開啟設定

選擇 File -> Settings

進入設定之後，點選 Python Interpreter 項目
在右邊的區塊可以看到 Python Interpreter 的下拉選單顯示 "<No Interpreter>"
所以我們點擊選單右邊的齒輪按紐
準備新增一個 Python Interpreter

新增 Python Interpreter

新增的時候選擇 SSH Interpreter
在介面上點擊 Existing server configuration 右邊的 "..." 按鈕
建立新的 SSH configuration

建立 SSH configuration

進入到 SSH Configurations dialog 後
點擊左上角的 "+" 可以新增 SSH configuration
在右邊的連線資訊中輸入 EC2 的 FQDN 與 User name
Authentication type 選 Key pair 後
在 Private key file 中填入一開始我們轉換好的 .ppk 檔

填入遠端 Linux 連線資訊

按下 Test Connection 按鈕
確認填入的資訊是可以成功連上遠端 Linux 機器的
接著按下 OK 直到回到 SSH Interpreter 那個 dialog 後按 Next

測試連線成功

下一步是設定遠端 Linux Python 的路徑
我們因為有用 venv 的關係
所以路徑設定為 /home/ec2-user/ec2_python3_workdir/.venv/bin/python3
這裡可以直接瀏覽遠端 Linux 上的檔案系統
選好後按下 OK

選擇遠端 Linux 要使用的 Python interpreter 路徑

再來設定本機與遠端同步的資料夾
就設定到 /home/ec2-user/ec2_python3_workdir
這個設定是讓之後在本機上的修改
都會上傳到遠端 Linux 的這個路徑中
設定好後就一路 OK 到底
然後回到原本 Project 的介面

設定同步資料夾

這時候可以打開 Remote Host 的視窗
展開到我們設定同步的資料夾時
可以看到綠色的 highlight
每次修改本機檔案後儲存
可在右下角 File Transfer 視窗看到 PyCharm 在幫我們上傳

本機編輯後可自動上傳至遠端 Linux

最後就是按下執行
在左下角的 Run 視窗能看到執行結果
也可以透過右邊 Remote Host 視窗開啟遠端的檔案來看
到這一步算是完成了本機開發遠端執行的目的
後續要接著執行 unit test 並在 PyCharm 的介面上看到各項測試綠燈也是可以的

遠端執行修改後的結果

在 Windows 上用 Visual Studio 2019 開發 Linux C++ 程式

情境是這樣的

我已經存在一個 repository 寫好了 Makefile
可以在 Linux 上透過 make 編譯出執行檔
想用 Visual Studio 開發並 debug 這樣一個程式

手上有的環境跟 GitHub repository

• Visual Studio Community 2019 16.4.5 (run in Windows 10)
• Ubuntu 16.04.6 LTS (run in VirtualBox)
• Cpp Linux Example repository

其實 Microsoft 官方文件介紹得非常清楚
跟著文件做就可以很簡單的建立一套開發環境

首先在 Visual Studio 上必須先安裝 Linux development with C++ 的 workload

安裝 Linux development with C++ in vs2019

接著在你的 Linux 系統上確認有安裝需要的套件
g++, gdb, rsync, zip, make, openssh-server 等

然後啟動 Visual Studio 後進入 Tools > Options 選單
在 Cross Platform > Connection Manager 頁面按下 Add 按鈕
並輸入連線的資訊
當然可以使用 SSH Private Key 的方式做認證

設定與 Linux 的連線

輸入與 Linux 連線的資訊

接著就可以建立新的專案
選擇 Makefile Project (for Linux) template
路徑設定在我們已經有的 repository 資料夾內
因為後續路徑關係
我們把 .sln 跟 .vcxproj 兩個檔案放到跟 Makefile 同一層

建立 Makefile Project

選擇在原本 Linux 程式的 repository 資料夾下建立

把 .sln 與 .vcxproj 移動到 Makefile 同目錄

再來把所有相關的 sources 跟 Makefile 都加入專案內
接著進入 Project > Properties 選單
在 Remote Build 頁面的 Build Command Line 設定填入 make all
最後按下 Build Solution (Ctrl + Shift + B)

加入已存在的檔案

設定 Remote Build

可以看到執行建置時, 複製到遠端 Linux 並執行 make all

這時候可以在 Linux 裡面發現被複製過去的檔案
default 會在使用者的 home 路徑下的 projects 資料夾
這個路徑也能在 Project Properties 裡修改

設定複製到遠端 Linux 的路徑

檔案被複製到 Linux 上的樣子

最後設定 debugging 的資訊
跟以往在 Windows 上的設定類似
不過路徑改為遠端 Linux 上的
執行沒問題後就可以加上一些 breakpoints 來試試看吧

設定 debugging 啟動資訊

用 Visual Studio 2019 debug Linux C++ 程式的過程

我沒有使用更多深入的功能
但就目前有接觸到的基本功能來說
體驗算是與原本開發 Windows C++ 程式非常一致
很快就可以上手