brucehsu.>

單看書名，你可能會以為這是一本走進荒野找尋自我的傳記或是小說，但其實 Wild Courage: Go After What You Want and Get It 是一本不折不扣職場指南，它所講述的論點，恰恰是從小受臺灣教育的我來到國外後，覺得自己相對欠缺的心態與技巧，一言以蔽之便是：『主動』的能力。

附帶一提，我寫書相關的文章，與其說是書籍內容的總結，更多是整理了我自身的經驗以及有共嗚的內容，主旨還是希望能夠推薦大家去找原書來讀，找出對你有用的內容與你自己獨特的詮釋。

作者曾在 Google 任職多年，還在公司內部成立了 Own Your Career 的社團，專門幫助其它 Googler 培養職涯所需的心態與技巧，在書中他提出了九點在大眾認知中是負面意義的詞彙，並重新賦予它們正面的涵義：

怪咖 (WEIRD)：讓自己鶴立雞群的勇氣
自私 (SELFISH)：為了自己挺身而出的勇氣
無恥 (SHAMELESS): 為自己的努力與能力撐腰的底氣
走火入魔 (OBSESSED)：自己設定標準的迫力
愛管聞事 (NOSY)：更深入了解的好奇心
心機重 (MANIPULATIVE)：影響他人的勇氣
冷血 (BRUTAL)：保護自己精力與時間的決心
莽撞 (RECKLESS)：在權衡風險後向前衝的蠻橫
愛指使人 (BOSSY)：聆聽與引領他人的勇氣

當然，這些特質在一般人的眼中，會有負面涵義也不是偶然，我們肯定都能從自己的生活經驗想起一個代表每一項特質的人，以及他們造成了我們多少的困擾。此書的用意並不是要為那些造成別人困擾甚至是傷害別人的人們開脫，而是想要提醒，很多時候我們因為擔心他人的觀點、害怕自己的失敗，會用這些詞彙來限制我們自身的可能性，反而造成自己職涯的停滯不前以及對人生的不滿足。這裡並不是說我們就得學會如何用這些負面特質去剝削他人，而且重新框架這些詞的定義，去突破自己的恐懼，踏出自己的舒適圈，為自己的職涯冒險，同時帶著身邊的人一同成長。

也因為作者在每章的最後都花了不少篇幅去討論各項特質如果往負面發展會是什麼樣子(雖然我想大家都能夠提出自身經歷過的例子)，以及如何避免落出那樣的窠臼，例如『自私』並不代表你就只為了自己著想，同時也要試著去把餅作大、『無恥』不是認為自己都不會犯錯，反而是要勇於認錯並修補、『愛指使人』同樣不是說你就可以對他人頤指氣使，你永遠不該去發表對個人的批評，不該去拿別人出氣，不該搶別人應得的讚美等等。

對我自己個人來說，最有共嗚的可能會是下面幾項，我相信應該很多跟我一樣從小在臺灣長大、受教育的人們也會心有戚戚：

自私 (SELFISH)

作為一個集體主義的東亞社會，從小我們就會教導不要只想到自己、自私是個壞事，而這在一個成員彼此幫助才能生存的部落是有益的，即便到現代的工作環境中亦然。只是很多時候，我們在害怕被當作自私的擔心下，開始不把自己的需求與利益擺在第一：為了讓團隊可以更好的合作，我們花了很多時候安排了對自己升遷沒有影響的社交活動（作者在此處稱之為 NAP: Not Actually Promotable）、為了與主管的和諧不將自己對升遷與薪資的不滿說出來。簡單來說，這裡的自私並不是「什麼都得為我」，而是「我得先照顧好我自己」，就如同在遇到空中危機時，要作的第一件事情並不是幫他人戴上氧氣面罩，而是先自己戴好才有餘力去幫助他人一樣。

無恥 (SHAMELESS)

我還記得某次與一間教育新創的創辦人（同時是某個知名前政治人物的兒子）面試，他問的一個問題讓我揪結了很久：「你這一生中，作過最讓你自豪與驕傲的事是什麼？」我提到我和團隊一同創造出的幾個成果，但他仍舊不滿意，「我是說你這個人幹過什麼大事。」對於一向不覺得自己有作過什麼別人作不到的事情，並且對於與團隊一同完成一件艱鉅的任務更驕傲的我來說，我完全回答不出這樣的問題。

後來在社交媒體上提到這件事，我一個很敬重的前主管就這麼跟我說：「很多事情確實是其它人也能想得到、也能作得到，但真正去作的你就已經跟『其它人』不一樣了。」而在讀這章時，就一直想到前主管所說的這句話。

心機重 (MANIPULATIVE)

想到英國工黨的前任黨魁曾在音樂祭上說過：「政治即是眾人之事。」這句話適用於生活的各個面向，職場也不例外。這並不代表說我們便要開始去學習什麼厚黑學、什麼冷讀術云云，而是了解職場中不同位置之間的關連與角力，在不失真誠與慷慨的情況下，去與他人建立良好的工作關係。我個人其實是個蠻內向的人，對於 Networking 時常感到興趣缺缺，但作者確實提出了一個好的心態可以學習：將每次互動作為是一個單純認識新朋友的契機，這個人可能只會是跟你一同打 Helldivers 2 的網友，卻也有可能是你未來的主管、未來的投資人，在此同時仍保持慷慨，持續付出，但不要違背自己的意願與忽視自身的需求。

冷血 (BRUTAL)

從我們從小生長的環境裡，拒絕別人通常會被當作是沒禮貌的舉動，所以我們很多時候會因為這樣去答應他人的請求。在『自私』一段中作者主要提倡的是主動為自己發聲，而這在『冷血』這裡，則是希望我們嚴格維持自己的界限，對於自己有限的時間與精力進行嚴格的把關，這或許會被他人當作不近人情，但唯有如此我們才能足夠的能量去關照那些真正重要的人事物。

2019 的自己，你該讀哪五本書呢？ (2024 年版)

2024-12-28T00:00:00Z

昨天被 YouTube 推薦了《推薦5本書給5年前的自己》的影片，不禁也讓我思考起，這五年來，有哪幾本書是我讀完後，會馬上想送給當時未滿 30 的自己的呢？

我可能錯了：森林智者的最後一堂人生課 (I May be Wrong)

最沒懸念的一本，肯定是《我可能錯了》這本書。從我 2023 年中購入有聲書到現在，我聽了 5 次、紙本書讀了兩次、買了中文電子書又讀了一次、人生第一個刺青也是源自於這本書。

作者從自身的經歷出發，逐一審視自己投入靈性成長的契機、過程、以及省思。與許多探討較為抽象概念的靈性著作不同，作者將自己當下內心的想法、情緒、質疑、害怕都毫無保留地紀錄了下來，這樣的坦誠讓他的故事更有真實性、更容易讓我們這些讀者去同理並反思自己。

我將 This too, shall pass 這句話刺在了手臂上，提醒自己無論當下是好是壞，都會過去的：所以開心時享受當下，難過時知道這會有過去的一天

會想讓 2019 年的自己讀這本的理由實在是太多了，不管是提醒自己該活在當下、放下對事物的執念、接受並與自己的情緒共處等等，就算是當時的我沒有經歷過現在的我所體驗過的事，他也一定能從中拾起對當時的他有所幫助的片段吧。

做自己的生命設計師 (Designing Your Life: How to Build a Well-Lived, Joyful Life)

2019 年下半年時的我，在職場與生活上都處於一個迷航的狀態，雖然每天很期待進辦公室與朋友們見面，但同時也感覺到自己似乎是困住了，常常一週有三天晚上會下班後跟朋友們直接離開辦公室，到附近的酒吧吐苦水，就算是如此，我當時仍是抱著走一步算一步的心態。

如果我能夠早點讀到《做自己的生命設計師》一書，雖然未必可以解決所有的迷惘（即便是現在，我也不敢說我已經作到了），但至少可以讓我更清楚該如何在一片迷霧之中找到方向，如何在動彈不得時找到搬開面前大石的方法。

會想讓當時的我，把下面這些概念放在心上：

你隨時都可以重擬問題，或是我偏好的說法：重新框架情況。幾乎沒有什麼事情是決定後沒辦法改變的。
接受世上總有你沒辦法控制的重力問題。
你的人生觀與工作觀不見得需要一致，把它們寫下來吧！或許會有讓你豁然開朗的事也不一定。
記得你面試時最愛說什麼嗎？Fail fast ！

Someday is Today

作者在開始寫作、成為小學教師前，曾在麥當勞打工，在值夜班時被搶匪們壓在地上，用槍指著腦袋，毋庸置疑地，在那之後他對人生有了不同的體悟。

這或許是我最擔心 2019 年的我自己會棄若敝屣的一本書，原因無他，因為裡面許多觀念對當時的我來說，可能會太過自我中心與過度激進。為什麼一定要不浪費每一秒？為什麼不把別人的意見當一回事？為什麼不遵守規則還可能造成別人的困擾，還可以這麼沾沾自喜？

但這恰恰是我想讓五年前的我知道的！裡面最讓我印象深刻的，是兩個小故事：

第一個是作者在任教的學校，每隔一段時間都有表單要填，上面有一個欄位是 Position 職位，他一直覺得這是個很無用，單純為了形式而存在的欄位，所以從他第一年加入學校開始，他就一直填上自己當時的姿勢（同為 Position ）：坐得直挺挺的。「而你知道嗎」，作者說，「我在學校這麼多年來從來沒有人跑來跟我說你怎麼可以這樣寫，就算哪天有好了，我就是道個歉，劃掉重寫就好。」

第二個則是作者帶著家人出遊，來到了一個露營區，在廣闊的草地上所有畫線的停車格都停滿了車，作者眼看旁邊沒畫線的地方明明就還有不小的空間，於是就直接將車停到了沒畫線的空地上。他的家人都質疑他為什麼不停到其它有畫線的地點，他也是是聳聳肩：「停車格只是某些人制定出來的隨機規則，這裡空間那麼多，我停在這裡不會影響到別人有什麼不可以？如果真的有人來跟我說我不能停，我再開走就是了。」

看到這裡，你應該可以想像為什麼我會擔心之前的我會沒辦法接受這樣的內容了吧？但我確實是想讓他知道，他可以不用作到那麼極端，還是可以為了他人著想，作出符合自己價值觀的舉動，同時間卻也可以不用因此畫地自限，去苛責自己。

打造你要的人生：歐普拉與哈佛教授談「更幸福」的藝術與科學 (Build the Life You Want: The Art and Science of Getting Happier)

同樣是我聽了好幾遍的有聲書，憶起 2019 年時汲汲營營地想過得「更開心」、「更有成就」的自己，或許這是一個讓他好好停下來省思的機會，思考何謂幸福，並且從書內給的各種觀念與練習開始，有意識地去作出選擇，走出人生。

尋找復原力：人生不會照著你的規劃前進，勇敢走進內心，每次挫敗都是讓你轉變的契機

第五本我想了很久，其它幾本候選書為《讓感受自由》以及《我值得一段好關係：運用情緒覺察的力量找到關係平衡》，前者讓我開始學會去辨別情緒並且留給它們空間，後者則是從依附理論出發去提點我該如何不讓自己的過往創傷綁架。

最後還是覺得，留佩萱心理師的文字不管是在疫情當下或是疫情之後，都帶給我不少的療癒與成長，同時這本書所談的復原力，也是我希望 2019 年的我能夠好好學習的能力。

David Kessler 談悲傷、哀悼與療癒

2024-03-23T00:00:00Z

前陣子看到 Matthew Hussey 訪問曾與悲傷五階段理論提出者 Elisabeth Kübler-Ross 合作過的 David Kessler 的訪談節錄後，便馬上買了他的新書並去看了完整版的訪談。

雖然有些老生常談，但聽 David Kessler 用溫和堅定的語氣告訴聽眾們這些，仍讓我感受到自己也正走在復原的路上。

於是我聽了幾遍，作了些筆記，在此整理下來給未來的自己：

什麼是悲傷 (Grief) ？當我們談到這詞時，很自然地會想到所愛的人的逝去，就連英文字典裡也是這麼寫道。但悲傷，其實就是我們所不想要的改變，而我們生活至今，也或多或少會與我們未曾認真關照、認真哀悼過的悲傷共存著。

有時我們會開始比較誰的悲傷、誰的傷痛比較糟糕，但我們需要知道的是：你的傷悲，就是最痛的悲傷。當我們開始比較的時候，我們是與我們的理性、心智為伍，但我們真正受傷的，真正需要療癒的，不是我們的心智，而是我們的心靈。

美國水牛觀察到風暴將至時，反而會一頭跑進風暴裡，因為牠們知道，這樣可以讓牠們更快度過危機。人類卻不一樣，我們會極力避免去碰觸那些讓我們痛苦的心碎與創傷，但在那些我們所不願踏足的黑暗之處，便是我們所需要療癒的所在。

而療癒從來不是一個人能夠完成的，我們會需要其它所愛的人們的協助，讓我們體驗到什麼能是健康的關係，孤立從來沒辦法帶來療癒。

同時，療癒也不是幾個禮拜，甚至是幾年的事，當你認為自己準備好並敞開心胸時，便會迎來許多的考驗，讓你了解自己是否已經改變。這些傷痛、腦中的聲音，可能一輩子都不會消失，但你可以學著如何調低它們的音量，調高那些愛你的聲音。

在療癒的過程中，我們可能會因為遇到在這條路上走得比自己前面的人，為了無法跟上他們的腳步而為之氣結、為之失望、為之責備自己為何沒有準備好，為何又再次錯失了一個可能的靈魂伴侶，但別忘了：會離開的並不是你的靈魂伴侶，你的靈魂伴侶從來都是會留下的那位。

When life changes without our permission, we still have the permission to change.

Meta 尋奇：工程師的內部觀察 (0.5) - 聽說 Meta 服務大當機了

2024-03-07T00:00:00Z

聽說前幾天 Meta 的服務又再一次的大當機，除了導致怨聲載道外，也間接影響了其它服務的穩定性，像是最常見的 OAuth 登入，以及各家通訊軟體的流量激增。

咦，我怎麼說「又」呢？如果大家還記得的話，在 2021 年 10 月，當時同樣也有一次大當機，那次除了對外全面斷線外，內部系統同樣也無法連上，包含了事故管理系統，甚至連門禁系統也無法倖免，還記得那時正好是倫敦接近下班時間，在家工作的我就直接下班開吃爆米花看戲。

目前這次出包的原因還沒有公佈細節，如果大家對上次因為 DNS 問題而發生的大當機有興趣，可以參考 Meta 自己發佈的部落格文章，這裡我主要想把我回應臉友的留言內文稍作改寫，不談技術細節，來蹭蹭熱度。

我想大家可能會問： Meta 作為一間近乎壟斷中國市場以外社交媒體平臺的公司（ Facebook, Instagram, WhatsApp, Threads ），怎麼服務好像這麼不穩定？難道他們沒打算要招聘更多人專門來負責系統的穩定嗎？

首先我覺得第二個問題，我自己的看法是：沒有。當然不是代表說 Meta 現在沒有持續在招募，而是認為單純以穩定性為目標，是件很不 Meta 的事。從比較外部的因素來說，在祖克柏去年宣佈要將 2023 年作為 Meta 的效率元年後，不管是公司的產出或是投資人的信心，都非常地正面，相信公司在這樣的前提下，肯定會維持相對高壓的精兵策略。

所以之前的 Meta 就不是如此嗎？跟我 2020 年加入時相比，我覺得在第二次裁員之後，公司內部的氣氛確實有更為高壓，在那之前 20-21 甚至 22 我覺得並沒有特別比其它地方壓力大到哪裡去（以我在的 Oculus 和 Messenger org 來看），精兵的部份我沒有什麼特別的觀察，但確實聽過一些比較資深的同事在說公司在疫情大舉徵才時 hiring bar 降低了一些。

其實 Meta 也養了一群專門到處調查潛在性能、穩定性問題的 Production Engineers ，如果有機會跟他們聊聊的話，就會聽到很多很有趣的問題與解法，比方說資料庫層面的 bug 、 Data centre 裡 load balancer 效能衰退還會不定時掛掉的原因等等，只是畢竟在公司裡還是少數，況且就如同前面所說，穩定與否就是生存者偏差：就算你再怎麼疊層架屋抄捷徑，只要系統沒有出事，就很難從客觀數據的角度去推動說需要重視穩定性、效能之類的改進。

這也可以回到第一個問題，因為不容易有好的立論點去說服公司專注在穩定性是有助於公司商業表現與成長的，在 Meta 的 Impact-driven 文化下，就很難得到該有的認同。

如果有認真寫過 PSC （績效自評）就知道，很多時候需要思考的，便是將自己所作的事情轉化成數字，再由數字去 frame 這件事對公司的 impact 何在，這也是為什麼 Meta 在某個時間點導入了 Engineering Excellence axis ，希望讓大家能夠更加重視 code quality 、design scalibility 等更加虛無飄渺的層面。（但同樣也是有人在 game EE ，像是我就聽過有人一個一個檔案把 Java 轉成 Kotlin ，然後拿 diff/PR 數目說嘴）

以我自己待過的 Messenger 底層 infra 的 PRE (Performance, Reliability, and Efficiency) 為例，每當你提出一個新專案，就會被要求思考「哪些 metrics 看來不樂觀」、「你這個專案想移動的是哪些 metrics 」、「這些技術類 metrics 的變動對產品類 metrics 會有什麼 impact」。

像我當初想推開發者體驗改善的專案時，就一直在思考該如何 frame 這件事，例如說縮短工具啟動時間乘上每日多少使用者、降低每件事故找出原因的時間云云，然後再由這些數據去延伸出這樣的改善最終反應到哪些使用者體驗上，比方說降低使用者 crash 的機率、降低傳送訊息的延遲等等。

…… 不知道你怎麼想，反正我打完是突然覺得，果然還是快速產出新功能最好了，不用想那麼多有的沒有的間接數據來佐證自己的成果。

至於這樣公司文化還有影響到什麼層面呢？就留待下一篇來說詳細一點吧。

Meta 尋奇：工程師的內部觀察[0]->技術宅的你會好奇的事

2024-02-14T00:00:00Z

自從 2020 年 9 月，我為了 Facebook （現改名為 Meta）的工作從荷蘭搬來英國也已經超過三年，而且前陣子 2023 年十月換工作後也差不多過了三個月，這段時間不管是與 Meta 前同事們間閒聊，或是回荷蘭時與朋友們之間談論近況，總是會聊到一個主題： Meta 的文化與其它公司有什麼不一樣，越聊越覺得想把自己的一些經驗與觀察寫下來：不管是我懷念的也好，討厭的也罷。

所以，你誰？

我於 2014 年從中正大學資工所畢業後，在臺灣工作了三年左右，主要在新創工作，一開始以後端為主，但後來不可避免地開始碰到了前端、資料工程，乃至於 DevOps 等不同的面向，對於我後續職涯的發展有著不小的正面影響。

在 2017 年時，運氣不錯的我拿到了荷蘭 Booking.com 的 offer ，並於年底搬到阿姆斯特丹，在約莫一年後又加入了當時剛在荷蘭設辦公室的英國公司 DAZN ，成為該分部的前 8 名員工之一。

而在 2020 年全球因為疫情封城之際，我幸運地拿到了英國倫敦 Facebook 的工程師 offer ，並於該年 9 月搬到了英國。一開始是在 Oculus (爾後整併改名為 Reality Labs) 負責 VR 裝置上測試相關的底層架構，之後又輾轉加入過 Messenger Desktop 以及 Messenger 客戶端底層系統的團隊。

在這篇文章裡，我想先從最表面的觀察開始：以我一名小小工程師的視角來看，在 Meta 裡工作，技術層面與工作環境上，與我待過的其它公司有什麼不一樣的地方呢？

自己的系統自己寫

對於工程師來說，對於 Meta 的印象，除了很多 bug 的服務外 (?) ，可能就是其所開發並發佈的各種開源工具與框架：假如你是前端工程師，那你可能會想到 React ；假如你是後端工程師，那你可能會想到 GraphQL (呃，會有人想到 Hack 嗎？)；假如你是行動端開發者，那你可能會想到 React Native；假如你是資料工程師，那你可能會想到 Presto ；假如你是 AI 從業人員，那你可能會想到 PyTorch 或是最近很紅的 llama LLM 等等。

但真正進來 Meta 工作之後，會發現上面所列的不過只是冰山的一角罷了，因為內部系統絕大部份都是為了因應公司的需求，而完全由公司員工所開發的。不管是專案管理、 A/B 測試、效能量測、資料視覺化、版本控制、持續測試、雲端開發平臺等等，都是由公司內不同的團隊開發出不同的工具，來滿足我們自身的需求。這些內部系統的完善程度以及多樣性之高，高到有一些 Meta 前員工在離開公司之後，創業時直接把公司內部的系統當作題目來作。

而身為一個工程師，令人興奮的是，這些系統的原始碼都是你有權限看得到、有權限去修改的！（大多數時候啦，有些比較特殊的系統不一定是每個人都看得到，或者像是先前公司改名那樣只有極少數人知道的事）

事實上，在剛進公司的一段時間，大家都會需要參加所謂的 bootcamp 來熟悉公司內部的運作，而軟體工程師前幾個禮拜的工作，便是上課以及完成由各自的 bootcamp mentor 所選擇，公司內部各個不同的 team 所提供的 bootcamp tasks ，像我一開始除了一些簡單的 refactor 之外，還修過公司內部 oncall 系統的 bug 。

當你正式加入 team 之後，也還是可以利用自己的時間去改其它系統的 code ，很多時候負責該系統的 team 可能還會很歡迎你幫他們解決他們沒時間作的功能、沒空修的 bug 呢。

另一方面來說，這樣的自由有好有壞：有時你會發現本來想修的 bug 已經有人修好了，讓我印象最深的是有一次 Messenger app 發生無法使用輸入法的情況，正想跳下去自己修的時候，就有臺灣同事找到了對的 team 對的人幫忙修好了；有時你會發現自己負責的功能莫名其妙出包了，最後發現是有主管不明究理地請底下的工程師 approve 他的改變，導致全球上百萬不該看到這個 Proof of Concept 的使用者開始使用了這個功能（然後就被我默默寫進履歷裡）。

裡面的開發環境同樣也是獨樹一幟，就如同前述，有著自己的版本控制系統，同時為了實現 monorepo ，還特地用 Rust 寫了個 on-demand 的虛擬檔案系統，另外像是需要與資料庫連接的系統，為了效能同時也為了防止資料外洩，只能從 VSCode 裡隨選隨開一台 server 來作為你的開發環境，搭配上公司內部只有一個主 branch 的版本控制流程，要多工同時作不同的功能只要新開一個 VSCode 視窗即可，甚是方便（能不能作完就是另外一回事了），而在我離開前，也有幾個著重在將 mobile app 開發搬到遠端開發環境的專案在進行。加入新工作後，什麼都要自己設定，難免還是有些懷念 Meta 的開發環境。

牽一髮動 20 億人（其實不會啦）

提到前一段那個百萬使用者的故事，就不得不提到對我而言 Meta 最大的吸引力：龐大的使用者群體。我先前在臺灣的工作經驗主要都在比較前期的新創公司，會接觸到使用者的數量級，當然無法跟 Facebook 、 Messenger 、Instagram 、 WhatsApp 這些服務相比。

不過實際上，真正會碰到純技術 scaling 問題的專案與其他的專案相比，數量上簡直是滄海一粟，理由也不難想像，因為這些問題大多數都在 infra 端就被幾個精兵團隊解決掉了，多數的工作主要則是如何在這些基礎系統的地基上，建構出商業問題的解決方案。當然，就如同前一段所說，你真的感興趣的話，也是可以投入不少時間去閱讀文件、原始碼、 Workplace （基於 Facebook 的工作協作平台）上的各種貼文，去研究特定的系統怎麼運作，只是大部分時候你應該都會忙得不可開交，更遑論有空閒可以去做深入研究了。就我觀察，大多數人在公司文化的驅駛之下，通常在實作時會更著重在產出的速度上，因此也讓我見識到了不少世界奇觀（這我會留待下一篇文章專門來討論）。

撇開技術層面不談，即使是釋出新功能時也鮮少會一口氣開放給全球的使用者，幾乎所有的功能在規劃階段，都需要考慮到我們該怎麼評估功能的成效、該先開放給哪些使用者、該如何蒐集資料等等。

為了因應這樣的需求，公司內部同樣有相對應的 feature flag 系統，可以基於各種不同的條件去決定是否執行特定部份的程式碼（毫不意外地，這同樣有前員工拿來作為自己新創的題目）。在長年的開發下，這個系統已經累積了不少可以用來判斷的條件，除了可以判斷帳號是否為內部員工這類讓人又愛又恨 [1] 的條件外，幾乎你想得到的使用者資料都可以被作為判斷的條件。

「燒等幾勒臺羅：sió-tán chi̍t-ē [2]，這樣你們員工不就把大家的資料看光光了？」

在公司內部，你在釋出會用到使用者個資的新功能前，都會經過法務等部門的審查，平時工作在存取任何有使用者資料的系統時，都有權限的管控，當然不乏有人試圖用其它的方式偷看使用者的資料，但這些案例最終的下場都是當天直接被開除。

主委加碼：至於「上海總部在作針對臺灣使用者的言論審查」這種跟疫苖裡有 5G 晶片同等級的幻想文，可以就只留在 PTT 和臉書 (??) 上就好嗎？

除了面向一般外部使用者的系統，我在Ｍeta 的期間其實更多的是負責內部系統的開發，如果你問我的話，我會跟你說這要比寫任何會影響到我爸媽 (?) 的功能還要有壓力得多，畢竟你所服務的客戶，就是坐在你左右，每天工作都忙得焦頭爛額，還要忍受你上的新功能，跟你一樣挑剔的工程師們。而且即便是內部系統，在全球有數萬名員工（雖然裁了不少……）的 Meta 裡，使用者基數也是相當地可觀，比方說我之前在 RL 時負責了一個 infra 專案，掐指一數，大概也影響了近 30 個不同的 teams 、上百名工程師（好吧這數目似乎不是掐指就數得出來的），更是影響到了每天上萬次的 builds 。

然而，這些特點，對我來說，僅止是在 Meta 工作最表象的體驗，對我來說，真正讓我感覺 Meta 與其它我先前工作過的環境不同的，是它的文化，而這正是我想在下一篇細談的主題。

[1] 又愛又恨的原因在於任何功能幾乎都會先開給員工內部使用，雖然可以搶先玩到像 Meta AI 等有趣的功能，但同時也會有很多充滿 bug 的功能，所以不少同事還會特別申請一個新的臉書帳號，以免影響平常的使用體驗。
[2] 感謝 Iàp Sîng Gān 網友提供臺羅拼音

帶貓從英國回臺灣（華航直飛）- 2024

2024-01-05T00:00:00Z

在 2024 年一月的時候，從英國倫敦將家裡的一隻貓咪帶回了臺灣，這裡記錄一下整體的流程與該準備些什麼，希望能幫助到往後同樣需要將貓咪帶回臺灣的朋友。

不算工商的工商

我這次合作的獸醫院是 Kew Gardens 附近專看貓咪的 Kitten to Cat 診所，和他們一起釐清了很多回臺灣所需要的手續與表單，同時他們也為此特別去進了無佐劑的狂犬病疫苗，如果離你家不遠的話（畢竟需要至少兩次門診），可以考慮與他們合作。甚至如果你只是單純住附近的話，我也推薦可以去他們家看診，他們的獸醫或是 staffs 都很有耐心，對貓咪很友善，大推！

航班選擇與準備

這裡我選擇的是華航直飛，因為英國是狂犬病非疫區，所以回去臺灣時貓咪不用再經過 7 天的檢疫隔離
長榮有中停泰國，雖然據曾在檢疫署工作的朋友說，如果途中有經過狂犬病疫區的話，可以跟檢疫署申請專案處理，但是相對就麻煩很多，而且這樣也會增加貓咪待在路上的時間，所以我當初沒有考慮
買完機票後（或之前），記得與華航倫敦分公司聯絡，詢問該航班還有沒有寵物托運的額度並預約，記得一班是有 8 籠寵物的額度
華航方會要求你提供寵物的重量、使用運輸籠的長寬高以及寵物加籠的重量，可以參考華航寵物托運網站的規定
接著華航會要求準備並提供相關證明文件，下面會提供我當時各證明申請的流程，記得在取得證明文件後將影本寄給華航留存，搭機當天會用到！
與此同時，華航也會要要求你填寫並提供旅客託運寵物行李申告書，起飛當天會需要兩份：一份留存，一份貼在外出籠上
除了外出籠外，別忘了買飲水器，我這次買的是會自動流至水盆的飲水器，結果因為常常會需要移動所以容易濺水出來，不太推薦…
其餘該準備的東西，可以參考這個影片內提到的寵物託運細節

狂犬病疫苗

最慢得在一個月前施打完成，臺灣輸入的要求是輸入日期一個月到一年前施打
無佐劑疫苗在英國很難找（畢竟平時沒什麼特別需求要打），需要多問幾家，我大概問了五、六家診所才找到願意提供無佐劑的診所
記得跟獸醫院索取證明
同時記得詢問診所是否在英國官方認證，可以進行輸出檢疫的清單上（見英國輸出證明），可以的話，別忘了提早預約起飛前 48 小時內的檢疫門診

臺灣輸入證明

上 https://pet-epermit.aphia.gov.tw/ 申請，須於輸入日期前 20 天申請
提供診所狂犬病疫苗證明，需有注射日期、診所資料、蓋章與獸醫師簽名
等候通知，看有沒有需要補正文件
審核同意之後，除了提供的同意公文外，記得下載其他附件，裡面包含了寵物註冊表以及臺灣官方要求的狂犬病疫苗注射證明表單

英國輸出證明

線上申請輸出至臺灣： https://www.gov.uk/export-health-certificates/export-cats-and-dogs-to-taiwan-certificate-3149
如同狂犬病疫苗那段所說，記得要確認常去的獸醫院是否有在官方認證的清單上，沒有的話可以詢問他們是否有打算申請加入
接著填寫輸出者、輸入者，以及寵物的基本資料
如果臺灣輸入申請還沒申請通過，輸入同意書號可以先不用填寫
可以先留存草稿不送出申請，日後再回來填寫，但是注意建議是在 10 個工作天前送出申請，以免審核延誤（雖然我自己是申請後三天就收到同意了，但是提早一點總是好的）
在 出發前 48 小時內，會需要到申請裡選擇的獸醫診所做輸出檢疫的健康檢查，記得提早預約
記得臺灣輸入證明那段提到的官方狂犬病疫苗注射證明表單嗎？在去門診前記得列印出來，並在檢查當天讓獸醫填寫並簽名（我是先填好再給獸醫簽名）
理論上英國政府會寄紙本給你或是獸醫診所，但或許是因為中間卡了聖誕假期的緣故，所以我們兩方都沒收到，後來是獸醫診所在檢查當天從系統上列印並貼寫

出發當天：Heathrow

華航會建議你在一開櫃時（起飛前 4 小時）就報到，以免拖延到之後的行程，我這次是 17:15 準時到，大概花了一個小時才完成手續，人多的時候可能會更久，自己抓一下時間
到了現場可以找地勤人員告知自己有帶貓，他們會帶你到大型行李托運的櫃檯處進行接下來的手續
地勤會跟你確認所有的證明文件（希望你有跟前面提到的一樣，將影本寄給華航留存），我當初忘了提前將臺灣官方狂犬病疫苗注射證明表單寄給華航，所以地勤還花了點時間去影印
接著地勤人員會協助你在貓咪的外出籠上貼上各種貼紙，然後請你去櫃檯支付貓咪託運的費用
支付完成後，會需要拿著收據去櫃檯辦理報到手續，除了一般的託運流程外，還會多一條行李條是剛剛付款過，要貼在貓咪外出籠上的
貼完行李條後，地勤帶你去機場安檢區獨立檢查
貓咪會需要出籠一段時間，記得要做好準備以免貓咪緊張或亂跑喔
掃完晶片後，貓咪還不能回籠子內，因為機場人員還會需要檢查籠內物品
檢查完沒有危險物品，貓咪回籠內後就會被送入管制區，之後再見到就會是在桃園機場的時候囉
人類接下來就可以自行出關過安檢了
登機前地勤會再跟分享照片給你，確認貓咪有足夠的水

抵達當天：桃園機場

動物檢疫櫃檯在 6 號行李帶旁
表明來意，並提供所有正本文件
檢疫署人員會核對文件
- 我某份文件的晶片號碼少打了一個 0 ，感謝檢疫署人員提醒
- 寵物註冊的部分，日後到任何登記在案的獸醫院都可以修改通訊資料，問題不大
同時會請你填寫報關單，價值的部分，檢疫署人員表示大多人會選擇填寫運費，但如果你很在意（比方說品種貓？），可以再與檢疫署人員確認
檢疫署人員確認無誤後，並且掃描貓咪晶片後，便會將資訊輸入到系統內
輸入並確認完畢後，檢疫署人員會給你一張鍵輸費繳費單，要你去附近的台灣銀行換匯櫃台繳納
- 注意！費用需要以現金繳納，記得留些台幣備用
繳費完，將繳費證明拿回櫃檯，對方會留存其中一聯，另外一聯交給你留底
領完行李後回來，檢疫署會有人拿著證明與剛剛填寫的報關單正本陪你過海關
出完海關，恭喜你獲得一隻正港（？）的臺灣貓貓

新的一年，用《往年回顧》取代《新年新希望》 (from Tim Ferriss)

2023-12-18T00:00:00Z

這篇的原文曾在 2022 年初發佈於我個人臉書，轉過來充個文章數 :p

我個人很喜歡的 Podcast 主持人/暢銷書作家 Tim Ferriss 曾在 2021 年底，分享了他都如何規畫未來一年要作些什麼 [1]。

與許多人預期的不同，他自承從數年前開始就已經不再為新的一年設定新的具體目標，而這一切皆起因於在某個跨年夜，他收到了 mentor 年幼女兒罹癌逝世的消息，令他不得不思考世事無常，我們在這個世界上的時間如此的寶貴，怎能浪費在無法滋養人生的事物之上？

《往年回顧》(Past Year Review, PYR) 練習大概落在 30 至 60 分鐘之間，步驟如下：

將筆記本分為兩大欄：正面影響與負面影響
打開你去年的行事曆，開始一週一週地檢視過往的事件。（我自己的習慣是不會將多數事件建檔於行事曆上，所以改用子彈筆記作為回顧的來源）
思考這些人、活動與承諾當中，有哪些帶給你極度正面或是極度負面的感受與回憶，並將它們歸類在相對應的欄位裡。
完成分類之後，基於 80/20 法則，自問：每個欄位裡，哪些事物是最容易激發我強烈情緒、感受的前 20%？
排序完成後，便可以開始採取行動了：

正面組：請馬上將這些事物加進你明年的行事曆當中，不管是開始預約朋友的時間、預訂活動都好。單純移除負面組是不夠的，如果真正重要的事物沒有被排進行事曆當中，那些真空隨著時間的流逝就容易被不重要的雜事所填補。
負面組：將選出的前 20% 負面來源寫在你今年第一週每天都看得到的地方，提醒自己，這些是你去年生活中多數負面回憶的來源，要竭盡所能地不讓它們出現在你的生活裡。

[1] Tim Ferriss 有特別錄製一集約六分鐘的 Podcast 描述這個方法

修正文章縮圖裡的方塊字

2023-07-15T00:00:00Z

Context

就如同在上圖中看到的，在分享到社群服務的縮圖中，中文文字的部份會因為沒有相對應的字型，而變成方塊字。

Analysis

就如同在關於頁面裡所提到的，這個網站的樣板是使用 Eleventy Excellence ，裡面整合了許多不同的延伸套件，例如使用 eleventy-img 去生成優化過的靜態圖片，其中也包含了文章的社群縮圖，同時 eleventy-img 底層是使用 sharp 這個使用 libvips 與 librsvg 的 library。

在本地端的系統上，中文字都可以正常地被 render ，所以問題想必是出在 deployment 環境之中。

目前我使用的解決方案是 CloudFlare Page ，基本上就是透過 CloudFlare Worker 去編譯出靜態頁面，再佈署到 CloudFlare 自己的 CDN 上。

與其它家的 Serverless 服務，例如 AWS Lambda 一樣， Worker 的系統需要相當地輕量化，想當然爾，也就不會包含特定的字型來拖累啟動、運行速度。

Solution

根據這篇 StackOverflow 的討論 Utilizing custom font in AWS Lambda and Node.js 12.x ，我在 repo 裡加入了 Noto Sans CJK 的 ttf 字型檔，並參考了該篇的答案，在同個目錄底下新增的 fonts.conf 作為設定檔。

要注意的是，這裡必須使用絕對路徑，而與 AWS Lambda 所使用的根目錄 /var/tasks 不同， CF Page 裡是 /opt/buildhome/repo 。

在 commit 之後，也要到 CF Page 裡設定環境變數 FONTCONFIG_PATH=/opt/buildhome/repo/fonts 。

keywords: cloudflare page worker missing svg fonts fontconfig

面試完什麼時候詢問回饋最好？

2023-07-09T00:00:00Z

先前偶然間讀到一則談論 candidate 在面試的最後馬上詢問面試官 feedback 的推：

聊一件今年開始，不知道為何似乎在增加的神秘現象？

就是我發現陸續有人會在面試最後問說：「請問我今天的面試有甚麼不好的地方嗎？」、或是「請問今天的面試您會怎麼評價，會給我打幾分？」諸如此類的問題。

我是不知道這是哪裡開始教的套路，但我總覺得這樣的問題多半會幫你扣分耶....？…
— Joe (@JoeChang2022) July 6, 2023

整體而言，我是同意並且覺得面試完詢問 feedback 是 candidate 該作，而公司方也該提供的資訊。如果你人在歐盟或是歐盟公民，你甚至還可以拿出 GDPR 請公司提供關於你的所有資訊。（但說真的，應該不會有人想搞到這麼僵吧？）

但原推說的也沒有錯，直接在面試結束的當下詢問，不僅對面試官尷尬，同時也不會得到對你自己有用的資訊，為什麼這麼說呢？

Disclaimer: 我之前曾在臺灣、荷蘭等地的公司擔任過面試官，主要負責後端工程師的招募，這裡分享的皆是當年公司的招聘流程與經驗，但不代表公司立場且不保證現在的流程與思維與當時相同

面試結果是如何決定的？

我們先從面試的流程談起再反推回去為什麼馬上問 feedback 沒有效果，在我親身體驗過以及聽過的大多數面試流程中，不外乎就是以下三個階段：

面試本身
面試官填寫 feedback ，此階段只有面試官與 recruiter 能看到
1. 如果有多位面試官，有些公司會讓他們先討論（有時 recruiter 會在場）並統整 feedback
各個階段的面試官與 recruiter 聚在一起，分享自己的決定（hire/no-hire）與背後的理由，同時討論最終的結果為何。

這麼麻煩？我還以為面試完就知道結果了？

確實，如果可以簡單誰想要複雜對吧？但是這麼作不論對 candidate 、面試官乃至於公司都有不少的好處：

首先，在面試的過程中，（理想中的）面試官會評估許多不同的面向，而就我的經驗來講，就算是勤作筆記的人，在面試結束後也是需要時間來統整，那時面試官所有的，更多是對 candidate 的 「印象」 而不一定是真正的 「表現」 。
換而言之，比起 你回答了什麼 ， 你怎麼回答 可能會是剛面試完的面試官更有印象的部份，但如此主觀的評估這並不是公司在招聘時想要看到的結果（即使是在 behavioural/cultural interview），所以透過書寫來讓面試官能夠更客觀地評估剛剛 candidate 的表現就成了一件很重要的事。這也就是為什麼多數公司在安排面試時，通常會有至少兩位面試官在場的原因，因為每個人的的經驗甚至是文化背景都不盡相同，有時同樣的回答與應對，每個人得到的信號會不一樣，這時事後的討論與 align 就顯得格外地重要了。

我之前面試某家公司，得到的 feedback 是『講話很有魅力很幽默，但是技能 X 不符合這個職位』，真不知道是該高興還是難過

所以你此時直接問 feedback ，對於面試官來說，他們也沒辦法跟你說太多（畢竟從上面的流程可以得知，通常最終的決定權並不是在單獨哪個人的手上），除了上述的印象問題外，由於面試也是公司給 candidate 印象的途徑之一，所以大多數的公司都會有面試官的教育訓練，教導他們何謂隱性偏見、什麼樣的話不能說，否則可能會有公司形象乃至於法律上的問題，或是一切都該交給 recruiter 來作溝通與潤飾等等。這部份聽過最有趣的案例是，面試結束後，面試官對 candidate 說了一句 “Good luck.” ，事後成為了教育訓練裡的其中一例：因為這樣會給 candidate 一種印象是：這間公司的面試評估中，「運氣」會是個影響結果的因素。

既然提到了 recruiter ，那就來談一下我覺得專業的 recruiter 在整個流程裡應該扮演什麼樣的角色：在蒐集到所有人的 feedback 之後，在分享各自 feedback 的會議上，此時的 recruiter 理應擔任 devil’s advocate 的角色，挑戰每個人的 feedback 內容，比方說面試官在 feedback 裡寫「技術問題的回答不確實」，那好的 recruiter 就該問「是什麼技術問題？為什麼你會覺得不確實？你期待的好答案會長什麼樣子？ candidate 有沒有可能是因為某理由而沒回答你想要的答案？」，這個時候其它的面試官也可以分享他們的經驗與想法，來避免可能的隱性偏見並確保大家的意見都一致。附帶一提，根據公司的不同，有時候某些面試官的意見權重會比其它人高很多，或許一個 candidate 技術能力很強，但缺乏該位置所需相對應的領導能力或是個人特質，那 behavioural/cultural 關的面試官就可以直接推翻其它人的 hire 決定，反之他們也能要求再重新面一輪技術面試。

所以你會怎麼作呢？

面試結束之後，發信給 recruiter 說我剛剛與面試官們聊得很愉快（詳細一點還會寫內容以及學到什麼），請代我謝謝他們，期待他們討論出來的結果。在收到結果後，如果對方回了感謝函，我會回信說雖然很難過，但我相信這是討論之後的結果，再次說自己的面試經驗愉快，感謝 recruiter 與面試官的時間，如果可以的話，是否能夠分享面試時的 feedback ，讓我可以理解我還有什麼不足的地方，讓我能夠回去改善呢？最後別忘了再謝謝 recruiter ，並請他/她轉告面試官我的感謝之意。

這裡可以額外參考這篇文章：How to Write a Thank You Email After an Interview

對方不願意分享怎麼辦？

當然，你或許可以用一開始所說 GDPR 來強迫公司分享 feedback ，但這樣作真的是好的嗎？我自己認為 feedback 是讓自己了解到有什麼地方可以改進、這間公司在意的是什麼的好機會，而不是為了要與公司吵架說他們的評估與決定哪裡有錯的工具。所以對我而言，如果對方不願意分享？那我也覺得就算了，這多少也透露了這家公司對於一位 candidate 的態度。

說穿了就是：做人留一線日後好相見

結語

回到一開頭的問題，雖然說我覺得直接在面試結束的當下詢問 feedback 並不會特別地對你有所扣分（假使真的有面試官將這件事當作 no-hire 的理由，那由上述的說明我們也知道 recruiter 應當把這件事抓出來 challenge ），但換另一個角度來看，我們現在也了解在那個時機點我們並沒辦法得到什麼的資訊，對於認真想要從中學習、進步的你，最好的時機點應該是在面試之後，不管是透過電子郵件或是在下次與 recruiter 談話時詢問。

祝各位面試順利 😃

Derek Sivers 談同理心

2023-04-24T00:00:00Z

在 Tim Ferriss podcast 的訪問裡， Derek Sivers 分享了他在冰島學習潛水時，第一次 panic attack 的故事。當晚他回到住所，開始思考：所以我現在也是一個會恐慌發作的人了嗎？

在此之前，他自承他其實多少輕視那些有憂鬱症、恐慌症的人們，直到自己體驗過之後，才理解到，很多時候這些情境都是非自願、無法控制的。這樣的體悟也讓他在隔日潛水時，遇到同樣恐慌發作的德國女生時，能更有同理心地幫助對方脫離那樣的狀態。

這同時也讓我想到在《擁抱你的內在家庭》一書中，作者請來同為心理師的朋友，講述自己療癒的故事：就在她以為自己已經完全康復之後，某次在家人去迪士尼的旅行又讓她創傷發作，甚至還在飯店裡尿床，這也讓她理解，療癒是個持續的過程，有時我們可能一輩子都脫離不了那些過去的影響，在這種時刻也只能好好地照顧自己，以及接納心裡受傷的那一塊。

Everything Everywhere All at Once

2022-08-18T00:00:00Z

我今年到目前為止最喜歡的電影，沒有之一。

真的不得不佩服那劇本寫得巧妙工整，嘻笑胡鬧之餘，卻又極其美麗：片尾當主角緩緩地，一個字一個字地對著女兒說 “I will always, always…” 時，我內心一直在吶喊著：「拜託不要是 love you，拜託不要是 love you」，直到楊紫瓊說出 “… want to be here with you” 時才眼淚潰堤，比起繼續落入傳統窠臼，讓女兒與自己繼續被「愛」所禁錮，當她認知到，只有自己是發自內心，選擇待在女兒身邊，而不是因為母愛去綑綁住女兒、綑綁住自己時，才真正讓自己與所愛的人拿回人生。

在看的當下，一邊感嘆編導組合 Daniels 的想像力與執行力，一邊也不免想到，在天馬行空的底下，那如刀割般的寫實感，又有多少是來自於雙人組合中的 Daniel Kwan 個人經驗？是否是在現實中無法實現的和解，只能透過創作來虛構一個作得到的平行時間？我不得而知，只是好幾幕，都觸發著我的回憶，都讓我看得心頭隱隱作痛。

所幸地方電影院所播的是重新上映的特別版，除了片頭有導演們特別錄製的感謝影片外，片尾還附上了許多片場花絮，和整影廳的人(呃，16 人的超小廳) 一同大笑，或許更符合導演們想留給離場觀眾的心情吧。

太宰治與我

2022-05-13T00:00:00Z

自從不用通勤後，消化 Podcast 的速度就斷崖式地落下，最近開始想重新開始這樣的習慣，而我第一集聽完的，便是周慕姿老師談太宰治的這一集－好險我不是在通勤時聽的。

高中時候第一次讀太宰治，或者更精確地說是他最有名的作品之一《人間失格》，是從漫畫《絕望先生》以及輕小說《文學少女》中逆流回去的，當初懵懂的我只知道我對其描繪的主人翁（即太宰治自己）莫名地有共嗚，就如同年輕的我對於任何以自我毀滅、悲劇結局收尾的作品有偏執的愛好一般，但你真要問我原因？當時的我肯定是無從說起，只能說肯定是中二病作祟（現在好像也是）。

大學時期，情況意外地翻轉，我反而開始討厭起如《人間失格》般這類的充斥著絕望、自我放棄與自我厭惡，或許可被稱為是虛無主義的作品。當時的喜好也正巧轉變為偏好展露人性光輝的作品。

有趣的是，在聽完 Podcast 中從太宰治的一生如何去影響他的作品之後，我竟或多或少更加了理解自己一些。

回頭去看，我漸漸可以體會到為何高中時期的我會對《人間失格》有所共嗚，因為太宰治在其中發自內心地用筆墨潑灑出了暗藏在他心中的那股揮之不去的羞愧感，不僅是因為自己沒有成為那一個想成為的自己，不僅是這樣的自己不停地在傷害自己、傷害身邊的人，更是因為不知道自己是否有作自己而仍舊值得被愛的允許。

然後，即使是這樣的太宰治，仍是有著對於人啊有些許的期待，仍是能寫出有著猶如太陽一般耀眼的人性光輝的《跑吧！美樂斯》。

「膽小鬼連幸福都會害怕，碰到棉花都會受傷」太宰治在寫下這句話時，到底是什麼樣的心情，我不得而知，但與其說是因為膽小，我更願意相信，那是因為有著太過細膩的靈魂，所以才會連輕柔的棉花都能在之中掀起漣漪，所以才能同時感受到《人間失格》中那滿溢而出的差愧感以及對世間人類的失望，卻也能如《跑吧！美樂斯》中一樣，堅定地相信人性裡有著無止盡的善吧。

點點軌跡

2022-04-23T00:00:00Z

回家整理去 Brighton 的照片時，發現這張我原本只是想拍海灘，卻意外有海鷗飛進圖中的照片，當下感到無比驚喜。

驚喜之餘，不知為何有點感嘆：從現在回首過去，讓人驚訝於有多少時刻，人生畫布上會天外飛來當下不知所以然，但在數年之後卻能清楚看出軌跡的一筆，就如同這隻意外入鏡卻成就一張驚喜的海鷗。

這大概是因為前陣子看到 PTT 淘汰 telnet 時回去看了一下，正好看到大學時期與留德板友的書信往來，詢問到德國唸書的細節。

當時的我，剛要從中正資工畢業，碩士班只有申請上中正資工所，還是備取 62 名，於是開始思考是不是該認真考慮先去當兵，再來準備申請國外的學校，但是看了看美國各名校的申請門檻以及碩班的學費，以家裡經濟和自身能力考量，實在覺得自己無法勝任，剛好看到 PTT 留學板上有留德板友分享，才意識到歐洲也是個可能性。

快轉到兩年後，拿到中正資工碩班畢業證書後，沒有抽到替代役的我決定選擇服三年的研發替代役，途中又經過一番波折，最後到了 Z 社。在 Z 社短暫的時光，經歷了新創的起起伏伏，並讓我看到了如此不同的人聚在一起所能迸發的能量有多驚人外，又是如何塑造出讓每一個人都能保有自我的文化。

三年過去，我在從鹿特丹往阿姆斯特丹的火車上，思考著隔日的面試，不禁慶幸著過去一年在工作上講英文的經驗讓我在過去幾日的荷蘭行中還算是過得順利，但也同時在思考，我是真的想在國外生活嗎？我是真的對旅遊有所興趣嗎？在此同時，窗外的平原開始出現一支支的風力發電機組飛梭而過，提醒了我科技對人類生活所能有的正面影響，一切便慢慢地明朗了起來：我的確不是熱愛旅遊的人，但每次旅行看到的不一樣的光景總是能開拓我的視野，如果我能夠讓更多人更容易地有這樣的體驗，那多少也能夠讓他們的人生多一點不一樣的色彩吧？

昨晚，我和前公司的朋友們照例來到了 Discord 上，開始了從疫情爆發之初，我們就固定會在禮拜五晚上舉行的線上聚會，雖然因為近來天氣不錯加上解封，原本至少十人的聚會，昨晚只有屈指可數的四個人參與，但我們還是邊玩著遊戲，邊說著一些不著邊際的幹話。講著講著，我們便開始分享起工作上的一些挫折與不滿，再聊到自己喜歡的公司文化，此時在 IKEA 工作的 EM 朋友提起他前陣子訓練課程中提到的四大公司風格分類，並問我對 M 社的描述是否準確。思考了數秒後我給出了我的答案，但也回到公司文化的話題，認為公司的商業上的經營策略與公司文化其實仍有些許的不同，同時我們會討論起喜歡怎樣的文化時，蠻常就是不滿現有公司環境/文化才會開始思考起這種問題，所以這時的答案通常是現有公司的對立面，而不是真的個人的喜好。語畢，大家都若有所思地點頭稱是。

國三要考學測的前夕，我晚上讀完書之後，總是會拿起 iPod mini，插上耳機，聽起 Steve Jobs 當初在史丹佛畢業典禮上所給的演說：你永遠不知道現在發生的點點滴滴會對你往後的人生掀起怎樣的漣漪，只有當你回首過去時才能看出這一路以來的軌跡，在此之前你只能全然地信任。

當時的我聽得懵懵懂懂，就如同拍下照片時沒注意到海鷗飛過的我一般。

生產力不是起點，更不是終點

2022-01-06T00:00:00Z

新的一年剛開始，在驚訝我已經開始寫第四年子彈筆記的同時，接連看了 YouTuber Ali Abdaal 的影片 My Toxic Relationship With Productivity 以及留佩萱心理師所寫的新的一年，相信你自己需要什麼，裡頭都提到了生產力這件事，不免讓我回想起大學畢業前-剛出社會時期的自己。

有 ADHD 的我，一直相信我需要一套良好的系統來管理我雜亂無章的大腦與生活，再加上當時我剛讀完心態致勝
一書，在確切地認知到自己在絕大多數時刻都是位定型心態者後，便開始無所不用其極地想將自己「導正」到成長心態的道路上，就某些方面來說也將成長心態的成長，誤解成了個人成就的成長。於是乎，我便開始了我對完美生產力系統的追求：我著手研究並嘗試不同的生產力系統，並花錢購入不同的生產力
app
後訓練自己，將自己的生活套入生產力系統的框架之中。只要有一丁點沒效率之處，便會花上好一段時間去研究、改進；只要有一絲沒有達到所設計系統的門檻，便會開始在內心責備自己，覺得自己作得不夠好。

在 My Toxic Relationship With Productivity 中 Ali Abdaal 自承，他曾有段時間為了維持所謂的『生產力』，忽略了自己的身心狀態，過度地追求最佳化自己的時間、過度地追求結果，直到他室友點出他正在報復性的熬夜，以及持續一段時間的不滿足感後，他才開始思考為何如此。

留佩萱心理師在開頭提到的文章內，引用了室內設計師 Joanna Gaines
於雜誌上發佈的一篇對自己的省思，裡頭提到了她過往都是以「效率」作為選擇的優先，進而失去了許多原本該有的美好時光與回憶。留佩萱心理師對此的註腳完美地描述了我先前的情況：我以有效率自傲，但卻也因此讓效率作為我人生的指南，反而忘了一開始追求生產力的目的，是為了支持我活出美好的人生。

美國著名的 Podcast 主持人/暢銷書作家 Tim Ferriss ，在他與 Brené Brown 的訪談中，主動提起自己的一項掙扎：過去他是以訪問高效的成功人士，整理他們為何如此有生產力、如此成功為主，但漸漸地他發現，這些成功人士當中，不少人的人生實際上都過得不若一般人想像的那麼美好－多次離婚、小孩不跟他們談話都是常見的劇本。他想花更多的時間討論這方面的議題，同時又擔心原本因為想聽成功人士故事與生產力的聽眾會因此離去（即便他也表示願意作出這樣的犧牲）。Brené
Brown 在聽完他的陳述後，先是同意了他所說的，以她自己與多位成功 CEO
、頂尖運動員的合作經驗，如何建立自我覺察並面對自己才是最難的挑戰，但她也不諱言很多時候，她試圖協助不同組織解決這種問題的時候，遇到最多的阻力都是來自於「這不是個有效率的過程」。

隨著年紀漸長，我慢慢可以理解 Tim Ferriss 與 Brené Brown 在講的是什麼，以及為何了解自己、接受自己這個概念如此地重要，並且一點一點地與過去的自己和解，試圖再次找到我心之所向，而不是被效率、生產力這些掛在前頭的紅蘿蔔給牽著走。

我想，這也就是為什麼子彈筆記是個意外讓我能夠持之以恆寫下去的生產力系統吧？它的基本概念相當地簡單，也沒有什麼強制要求，作得到很好，作不到也沒關係，仍是有其它（可能比較遠）的道路可以走到同樣的地方。如果當你有什麼特別的需要，它也有著足夠的彈性能夠去延伸。
最最重要的是，比起要你去適應這套系統，子彈筆記更多時候是來適應你的生活，並隨著你生活的變化演進。

最後，想分享一個之前在書上讀到，與成功有約：高效能人士的七個習慣的作者 Stephen Covey
的女兒所講述的小故事：某日，父親帶著她一同到了某個城市參加研討會，並約好了晚上要去餐廳吃飯，然而在研討會的結尾，他們遇到了一位父親很久不見的好友，雖然兩人相談甚觀，但她的心情卻漸漸沉了下來：「啊，爸爸大概會跟這位叔叔出去吧？畢竟也很久不見了。」出乎她意外的是，父親突然打斷了愉快的對話，並向對方致歉：「不好意思，我和我的女兒約好了要去餐廳吃飯，見到你真的很開心，希望之後還有機會再見。」喜出望外的女兒，在父親過世數年後，仍舊記得這段回憶。

祝福大家新的一年，都能好好地體驗生活，為自己與所愛的人創造出美好的回憶。

《跟陷阱說再見：還不知道你為什麼把人生過成這樣嗎》

2018-04-29T00:00:00Z

讀完之後才發現是《高效人士的七個習慣》作者史蒂芬．柯维的兒子與人合著的，所提出的多個陷阱，也與七個習慣相去不遠，只是透過更為生活化的敘事以及一些相關研究佐證（裡頭同樣也有摘錄了影響我一生的《心態致勝》一書，原本已絕版，去年又出了新裝版，再次推薦 [1] ）。

本書所講的「陷阱」，當然不是物理性的陷阱，而是心態上的陷阱，這些陷阱就如同流沙一般難以察覺，也一樣難以逃脫。如果你不知道成因為何的話當然無法找到有效的逃離方式，更容易因為舊的思維而不斷地掉入陷阱，不斷地重蹈覆轍，當你一直用一樣的方式作事，也就無法期待這次能夠獲得不一樣的結果。

書內列了七個陷阱：

忠於自己的陷阱：這章所談的是現代的親密關係中，很常出現所謂「已婚單身者」的情況，意即兩人雖然同住一個屋簷下，但彼此過日子的方式還是跟單身的時候一樣，同時擁有兩套不相容的價值觀。但這也不是要求雙方妥協，而是一同找出共同的願景，並攜手創造出屬於兩人的回憶。當然許多人都會等待對方先踏出第一步，結果就是兩個人都沒有作出改變，所以一旦察覺到這點的人就該主動先從自己改變起，這樣對方才有可能跟隨你的腳步。
享受人生的陷阱：簡單來說就是不要亂花錢啦(咦)
效率至上的陷阱：現代人的生活常被許多的待辦事項所淹沒，常常在努力地想清空待辦清單，但是卻沒有停下來好好思考，究竟什麼事物對你來說才是最重要的？沒有勇氣對於那些不重要的事物說不，導致了沒有一件事情是重要的。這章內也提到了經營關係上，當你投入得越多就會越珍惜這段關係。
追求完美的陷阱：完美主義可以說是相當反自然的思維。想想，從小學習的時候不就都是從失敗中找出成功的方法嗎？不會有小朋友因為怕跌倒而不學走路、怕唸錯字而不學說話的吧？然而多數人長大後卻開始因為對失敗的恐懼而延後甚至逃避人生的改變，導致人生毫無進步只能原地踏步。
維持形象的陷阱：對多數人而言，隱藏過錯比承認來得容易許多，就跟前個陷阱提到的一樣，社會普遍把錯誤視為性格而非一時的行為。但你一旦選擇隱瞞，你就無法從錯誤中學習，更別提需要多餘的力氣去掩蓋了。
穩定的陷阱：有時穩定的工作反而是消耗人生可能性的兇手，當你生活越發穩定，離開一份高薪的工作就變得更加困難。職涯的成功有四大面向：財務、思想、熱情、意義，如果每三個月誠實問自己這四個面向時，有一個面向回答是否定的話，就得開始注意了。
擁有的陷阱：斷捨離。（無誤）

『除非我們任由過去的事決定未來，否則未來不會被過去所決定。』

[1] https://readmoo.com/book/210069548000101

《學會思考，你贏定了！：45個讓你站穩立場的論證法則》

2017-10-05T00:00:00Z

提出論證：在字典裡的定議是爭論，提出一組理由或證據來支持你的結論。

論證：找出哪一種觀點比較好的方法、探究手段，好的論證不是只提出結論，而會包含證據供別人自行決定

區分前提（理由）與結論

前提必須可靠

避免情緒性的字眼與暗示，不要貼上標籤

類比需有相關性，例如「如同房子一樣，萬物必有設計師，故上帝存在」，適用在房子上的類比並不能擴充到整個宇宙。

引用資訊時，除了附上完整的來源，也需檢視來源作者的背景是否公正，以及交叉比較訊息的內容

因果論證通常由提出相關性出發，在排除掉互為因果或倒因為果的情況後，還得慎防過度引申，就如同奧坎剃刀所言：較簡單的理論通常是較好的，因為其可驗證性較高。

當我們從一個議題開始時，先不要擁抱特定的立場，而是得先探索過有哪些可能的方向，決定方向後再開始建立你用來捍衛它的論證。當然每一個立場必然有其反對意見，不要直接反對，而是納入你的考量內，最好是能提出替代可能，讓對方無從完全反對。

當你為你的論點成文時，開門見山提出你的主張通常是最好的辦法，最好詳述反對意見再一一回應，如果能有人在釋出前幫忙讀過一輪給點回饋再好不過。

在台上發表時，最最重要的，除了你的論述本身，便是台下的聽眾，要給他們你完全的尊重，同時注意他們是否有跟上你的節奏，並且多用正面的論述取代負面的情感衝擊。

常見的謬誤

人身攻擊
訴諸無知
訴諸憐憫
訴諸群眾
肯定結果（倒果為因）
將結論當前提（乞題謬誤）
循環論證
複合問題：將前提包裝於問題內，例如「你是否還是跟以前一樣自私？」不管答案如何，都已經有「你以前很自私」的前提
假兩難：非 A 即 B ，但有可能是 C, D, E, F …
情緒用語
不根據前提推理
過度延伸
忽略替代可能
誘導式定義：事先對某些定義隱含情緒性的評價
投毒於井：在提及反對論述前先行貶抑
轉移注意
稻草人

《想太多也沒關係》

2017-08-06T00:00:00Z

本書為了經常因為枝微末節的刺激而讓腦袋轉個不停，或是簡單來說：想太多，的人們起了一個名字：大腦多向思考者，用來稱呼這群以右腦為思考中心的人們。

為什麼這些人會讓腦袋過度運轉呢？首先，這些人通常有著過度敏感的感官，讓他們會接收到過多的需要處理的資訊，例如聞到香水味便開始分析此人的個性與喜好，或是選用特定氣味背後的成因，是不是晚上有聚會呢？選了比較低調的古龍水，應該是和長輩吧？這人看起來還蠻緊張的，所以對象可能不是家人，是商業上的投資人？…… 從這裡也可以看出多向思考者的另一項常見特質：極度豐富的想像力，甚至不受時間的限制，屬於發散式的思考。

因為主要使用的是右半腦，所以多向思考者的情感感受力跟五官一樣相當敏銳，造成了他們有著豐富的情感，與及容易情緒化的特質，在壓力過重的情況下，便會造成他們的大腦當機，發生一些平常不會作不會說的糗事。在與他人的相處上，由於容易受到情緒影響的特質，所以多向思考者通常會樂於幫助他人，一來是感同身受，二來是避免自己的情緒長期受到對方的影響（尤其是負面的）。

多向思考者容易展現出某些特質，像是常因為五官的敏感而對外在環境感到不適、思緒多到無法處理、急著抓住腦內的想法而講話大聲甚至口吃、非常容易情緒化、過度偏執，最極端的例子便是一般俗稱的亞斯柏格，因為無法處理外在過多的資訊與壓力，才偏好處在自己的世界裡。

由於僅有約 35% 的人是右腦/多向思考者，所以身為少數的他們經常會感到不受理解，更讓事態雪上加霜的是他們豐富的感受力，使他們特別需要感受到正向的情感（被愛、被認同），然而格格不入的特質常使他們陷於痛苦與自我懷疑中，多數人會發展成為好好先生好好小姐，基於對被接納的需求而對每個人都有求必應，不敢說「不」。加上他們擅於模仿的能力，少數人會開始模仿那些不接納他們的人，偽裝得冷酷與高傲。

另外一個讓多向思考者與整體社會格格不入的原因，是他們通常有著極為一致、難以妥協的價值觀，很多時候會因此被歸類為理想主義者，在他們眼中人人都該是平等互惠的，不該有著使用威權逼迫他人或是不誠實行事的情況，這樣的剛正不珂讓他們容易在人際關係上備感挫折。

最危險的是，這樣的特質，很容易被招引到心理操控者來利用多向思考者們，就特質上兩者甚至可以說互補。

這樣說下來，多向思考者們似乎是群渴求愛與正向情感的人，但實際上的狀況正好相反：就是因為他們自己內部充滿了那些正面能量，才能夠源源不絕地給予出去，只是在社會多數人的誤解下而讓他們也對自己這點特質有所懷疑。

多數的多向思考者在得知這些事之後，經常會因為過往的負面經驗而否定所有的內容，然而只要更加地了解自己後，他們便能踏出第一步，知道如何善加運用自己的能力。不管是找尋分辨自己的情緒能量，或是使用不同技巧來整理自己發散的想法，乃至於重新建立起自己的自信心，多向思考者所要作的並不是強迫自己成為大多數人的樣子，而是要運用自己的能力，成為大多數人可以仰賴並仰望的榜樣。

《心理軔性訓練》

2017-07-30T00:00:00Z

何謂心理軔性？簡單來說，便是人在經歷挫敗或是重大打擊後，能夠恢復心理平靜，並能積極面對接下來挑戰的能力。

其實看到這裡就能瞭解，其實每個人都有這樣的能力，只是發展的程度與面向不同罷了。書裡針對心理軔性提出了七個面向的能力：

調整情緒
控制衝動
分析原因
持有同理心
保持務實的樂觀精神
設定明確的目標
相信自我效能

而這些面向的大前提全部都是在一個人是否了解自己的心理需求為何，才能有向前的目標。當你了解自己真正想要什麼之後，就能透過下列十個技巧來訓練自己的心理軔性：

愛他、改變他或是離開他：最基礎的策略，就是了解自己有選擇的能力，可以決定該如何應對生活中令自己有所反抗的事物。
檢視自我能力的影響範圍：很多時候許多問題的成因並不在個人所能作出改變的限度內，這時就得檢視自己有什麼樣的資源，能作到什麼樣的結果。
形塑新思維的能力：很多時候人們在遇到特定的情境下都會因為過往經驗而觸發特定的反應與思考模式，如果能培養改變情境與行為間連結的能力，便能夠更好地面對需要心理軔性的情況。
測知情緒的改變：就如同上面列的第一點，心理軔性裡很重要的一個面向便是在遇到打擊後調整自己情緒的能力，但如果一個人沒辦法觀察到自己情緒的變化，又如何能夠有效地調整它呢？
融化心海裡的冰山：很多時候我們的思考模式是日積月累而來的，某個行為在表面上只是底下整個運作模式的冰山一角，能夠了解底下有著什麼的原因導致我們什麼樣的反應，才能夠針對其作修正。
避開思維的陷阱：一般人容易對於一件事情有過度的解讀，書內就提到了七個常見的思維陷阱：災難化、極大／極小化、隨意猜測他人的想法、情緒性推斷、自身／外部因素、一般化／特殊化、持續性／暫時性。
覺察事物的正面性：作者提到了一個很常用的技巧，透過每天書寫書記來發掘日常事物裡的正面意涵。
提昇專注力：請活在當下。
建立與他人的連結
發揮仁愛的精神：這是以上九個不同方法背後共通的核心思維。

《人際過敏症：曾經良好的關係，為什麼突然改變？》

2017-07-23T00:00:00Z

與《依戀障礙》一書同個作者，主要講述的是為何有些人在會在特定的契機之後，與某人斷絕人際交流甚至是陷入嚴重的情緒困擾。作者以人體的過敏反應作為類比，當生活中經常受到過敏源的刺激，總有一天會爆發永久並且嚴重的過敏反應，只要再次接觸過敏源就會有同樣的反應。有些人的人際關係也是如此，一開始只是覺得與對方相處上有不合的地點，但在某個無法回頭的觸發點之後，就會完全地、不自主地抗拒對方，就算對方是自己親近的人也是一樣。

更深入來說，過敏反應其實便是身體將特定的因子視為不屬於自身的異物而加以排除，人們心理上會將特定特質或人物視為非己異物，通常有幾個條件：對自己有害、無共同的共識與價值觀、對事物沒有共同的興趣與感覺、讓人感覺會在相處過程中喪失自我。

至於為什麼有著人際過敏症的人們會容易因為上述原因的刺激下而產生過大的反應呢？作者又回到了幼時不安全的依戀型態所造成的後續連鎖反應，造成人們對於這些心理刺激的反應相對嚴重的結果。

作者針對要如何解決人際過敏的問題，也參照了身體過敏的脫敏療法：先一點一滴地由低強度的接觸開始，慢慢地降低自己對與過敏源接觸的反應，也就是說將這些接觸點分解成較小的機會，例如特定場合才與對方互動。接著防止自己擴大那些不舒服的感受，不要放大腦內負面的解讀或是幻想、不要過於一般化甚至覺得他人都在批判自己。要作到如此，需要加強自己同理對方思維的能力，以及反省自己。從積極面切入，則是讓自己有個穩定的依附關係作為安全城堡。

《恆毅力》

2017-07-02T00:00:00Z

是什麼讓一個人能在他所在的領域裡成功？根據多方科學研究的數據，真正與天份相關的比重並沒有一般常理想像的高，更甚者，很多基礎能力測驗較高的人反而不在最後脫穎而出的名單中，那些能夠堅持到底，從一而終的人們才是。

作者在此稱這種堅持的能力為恆毅力，並透過問卷評量受試者的恆毅力強弱，發現是各項能力評量中，唯一能夠預測最後一個人是否能夠於某事成功的指標，而非大多數人所相信的天份至上論。當然也不代表每個人的表現不會受到天生因素的影響，作者提出了兩條算式說明天份與努力所能影響的層面：

天份 x 努力 = 技能

技能 x 努力 = 成就

另外一個環境能夠增進人類表現的研究指出，如果拿一百年前的智商測驗來衡量今日的人類，我們的平均智商將會是 130 ，因為在過往的百年間資訊傳播科技的進步，使得人類更加擅長抽象推理，並從他人的表現中學習、進步。

至於如何培養恆毅力？作者提出了四點：興趣、練習、目的、希望。簡而言之，得先對所作的事有熱情才能更進一步地堅持下去。

書內提到的一個小故事說明了這樣的差異：

有人詢問參與教堂工程的三位泥水匠他們的工作內容分別是什麼。

第一個表示：「我在砌磚。」

第二個則說：「我在建教堂。」

第三個笑了：「我在打造上帝的殿堂。」

按照作者的分類，這就是工作、職業與志業的差異。

另外刻意練習也是進步的方式之一，現今大家都耳熟能詳的一萬小時精通技能其實就是在講這件事，只是現實中的研究並沒有一口咬定練習時數的多寡與能力的增進有正相關，而是與練習的品質與方式關係較大。就如同一個人為了馬拉松練跑，如果沒有明確的目標或思索過的訓練方式，進步的可能性微乎其微。真正有效的刻意練習比較像是：設下目標、尋求回饋、根據回饋加以練習並改進。

前面也提到，外在環境對於培養恆毅力的影響，一般人們生活中三個最大的外在環境因素便是：家庭、課外活動與所處的組織團體。作者特別感嘆課外活動其實能夠帶來的益處頗大，也因此對於中下階層的孩子來說，課外活動的缺乏讓他們更容易陷入僵化的階級中而無法自拔。

《柔軟的心最有力量》

2017-06-24T00:00:00Z

中文書名沒翻出來的副標是：

The Dalai Lama’s Vision for Our World

本書的出發點即是透過達賴喇嘛的核心思想去推及到一個更快樂更美好的世界，而一切的中心思想就在於對於人類同胞、動植物乃至於這個星球的「慈悲心」。

就如同許多的事物一般，培養慈悲心得先從自己的內心作起。透過各種訓練對自己的情緒自我覺察，不讓毀滅性的情緒掌控與支配自己的內心，將部份情緒轉向用於正面的行為上。對於其它人發自內心地關懷與尊重每個人的自由，不要輕易地劃分界線，否則將是歧視的根源，研究也顯示除了與自己特別不同的族群外，人類也特別容易因為身份認同的優越感，而輕視那些與自己僅有細微差異的族群。現在國家社會常追逐的金錢財富並無法帶來內心的平靜與快樂，特別是大家愛談的 GDP 反而是顯現不出貧富差距的元兇，也讓人看不清社會上真正遇到的問題。而社會上的弱勢族群，很多時候並不是因為其基因不如人，只是社會歧視與經濟壓力下造成的 debuff ，若是兩個來自不同背景、不同階級的小孩同時被送往國外去接受一樣的教育，兩者的表現會是一樣的。

當然這幾乎是老生常談的內容，或許有人會說陷於空泛，但任何的改變本來就非一蹴可及的，我們所作的是將種子種下，期待能夠在下個甚至下下個世代讓他們在樹蔭底下乘涼。這也就是從教育作起的重要性，根據研究，人類小孩大既從五歲開始就會從能夠感受到他人傷痛並主動關懷的共感性格轉換為注重自身感受、相對自私的性格。另一方面，若我們能夠在這時候讓孩子們進行同理心的練習，並教導他們相關的技巧，就能有效改善彼此的衝突，形成互重互助的群體。書中提出一個很好的例子：透過讓孩子們討論手上的水果是從何而來，中間會經誰之手，並對那些人們表達感謝之意，我們不旦讓孩子們學習了系統化的科學思考，也讓他們關懷其它素未謀面的人們並對其感激。對於我們這些已經成人的群體，也是可以透過練習用新的視角、新的思維去看待問題來突破自身的慣性。

這個世界是一個充滿危險的地方，不是因為惡人的作為，而是因為沒有人挺身而出，阻止惡行　－　愛因斯坦

《情緒勒索：那些在伴侶、親子、職場間，最讓人窒息的相處》

2017-06-20T00:00:00Z

由於勒索者多為親近的人，加上情緒勒索一詞聽來威脅意味濃厚，常會有被勒索者質疑其嚴重性或是勒索者是否真有負面的意圖，然而這樣的寬容自省正是為何人們會成為被勒索者的原因之一，況且很多時候勒索者自己因為長久下來的生活經驗，使得情緒勒索這件事早已變成他毫無自覺的習慣動作。

我們可以從一段充滿情緒勒索的關係中歸納出六項特徵：

要求：每個人在關係中或多或少都有所求，然而當一個人的要求毫無討論的空間，甚至無視於關係中他人的底線與感受時，就符合了情緒勒索中的第一項特徵。
抵抗：被勒索者當然在感受到情感上的不舒服時會出現抵抗的反應，但在勒索者的各種降低受害者自尊的手段下，仍容易受到瓦解。
壓力：在感受到被勒索者的抵抗後，相較於尊重對方或是討論尋求共同解決方案，勒索者反而會變本加厲，試圖增加被勒索者心理上的壓力以達成自己的目的，像是透過「我是為你好」試圖讓對方有罪惡感的壓力。
威脅：勒索者通常也熟知被勒索者重視什麼、在乎什麼，也常常會以此要脅對方以達到目的。
順從：在受到各式勒索手段之後，被勒索者通常會屈服
重蹈覆轍：隨著每一次的成功，勒索者將更加上手，下次進行情緒勒索會更為容易

雖然情緒勒索的手法百百種，但都不脫對受害者三種心理感受的傷害：

自尊：在許多情況下，勒索者與受害者之間有上對下的關係，透過他們的地位，勒索者會試著讓受害者有自己所言所行皆有錯，同時放出誘餌：「你照我的話去作，我才會肯定你。」藉此貶低受害者的存在。
罪惡感：在貶低受害者後，勒索者還會讓受害者相信，滿足勒索者的需求都是他的責任與義務，如果受害者不這麼作，就是讓他失望、傷害了他，例如「我都是為你好」、「我這麼照顧你，你卻不聽我的話」。
安全感：勒索者會要脅奪去受害者心中最重要的事物，進而使受害者感受到不安與焦慮，為了減輕這樣的感覺，受害者更有可能會順從勒索者的要求。「我死給你看」、「斷絕關係」都是常出現的例句。

勒索者之所以會成為勒索者，通常有下列這些特質：

害怕拒絕：當勒索者在某事上被拒絕時，他們常會將其視為是對於整個人格的拒絕而為此惱怒，認為是受害者得為他不好的感受負責。
不安全感：有些勒索者會因為過往的經驗，在遇到類似情況時感受到極度的不安，並認為是受害者讓他不安。
自我中心：在很多情況下，勒索者的同理心是相對低的，所以無法推己及人，會以自己的需求為最高優先。
感受重要性：其實很多勒索者內心深處會覺得自己是「被虧待的」，情緒勒索對他們來說就是一帖特效藥，讓他們可以因為受害者為他們折腰而從中感受到自己的重要性。例如華人父母從利用罪惡感讓孩子為他妥協之中，感受到自己被孝順的重要性。

然而俗話說的好，一個巴掌拍不響，會成為情緒勒索中的受害者，通常也有一些特質讓他們特別容易陷入一段不平等的關係中而無法自拔，例如不擅拒絕、容易自我懷疑、過於在意他人感受。作者在此特別針對華人社會的孝順文化作討論，在反思之下，可以發現許多人的孝順，其實偏重於「順」的概念，透過賦與權威極高的重要性，進而將個人的感受與想法埋沒，同時讓這個隨處可以看到「聽話才是好孩子」、「權威永遠不會錯，天下無不是的父母、老師與老闆」的社會成為情緒勒索的溫床。

書的最後一段就是在引導身為受害者的讀者們練習擺脫各種情緒勒索的關係，作為書中最有價值的部份，我這裡就不寫了，推薦為此困擾的人們買一本來讀讀。

《依戀障礙：為何我們總是無法好好愛人，好好愛自己？》

2017-06-12T00:00:00Z

作者認為所有人無論人際上、精神上的許多問題都源自於對於父母依戀形式上的延伸，而依戀模式可以分為三大類：

安全型：情感上最穩定的一型，不會過於害怕失去別人的愛，也對於他人投以相對應的信任，也是三型中最懂得以正面態度解讀他人行為，不會因此否定自己或懷疑他人。
逃避型：喜歡在人際關係上保持距離、不被依賴，就算是最親近的人也一樣，甚至於被要求幫忙時會大為光火。同時因為對於人際關係的逃避，導致不擅表達自己的情感，會有表情與心情不一的情況。對逃避型而言，人際關係是種麻煩的東西，他們對於任何使他們感到麻煩的事物會盡可能拖延，乃至於避免。
焦慮型：基於失去他人關注與重視的恐懼，焦慮型的人會盡其所能地討好他人，對於拒絕是完全地不能接受，很容易因為如此而動怒，反過來報復性地將負面言語、行為傾倒回給對方。在投入親密關係時，對於一段感情的認可門檻很低，所以容易追求工作或生活上有所利害關係的夥伴，一旦投入就會希望對方完全以他為重心，兩個人成為神聖不可被分割的共同體，也因為害怕被遺棄，對於伴侶的要求也相當嚴苛。

作者在書中也怦擊了傳統的心理分析治療法，認為分析強調的是對患者情感的解釋而非同理，就形式上而言，是利用了患者將依戀轉移到治療者的身上，進而開啟患者的內心世界。但對於有著依戀障礙的患者來說，由於依戀形式本身就不穩定，只會使得患者更無法對於治療產生任何正面的反應。

對於依戀障礙的治療，作者提出「安全堡壘」的概念，即是重建一個人的依戀模式到接近安全型。

一個「安全堡壘」的角色要有五種作用：

保證安全感
對於他人的同理心
在對方所有求時，能有所回應
不會隨心情起伏而有不一致行為的穩定性
對他人全心開放、無話不談

Tracing performance regression in Grape v0.19.1

2017-02-05T00:00:00Z

Recently, after updated Grape from 0.15 to 0.19.1, this unexpectedly slowed our test suite down by almost 60% overall. In an extreme case, an example is 26x slower than it was. For a guy who just made the test suite able to finish within 5 minutes, it is definitely unacceptable.

So first off, I identified the slowest example (the one I mentioned that is 26x slower) and StackProf it. By profiling that specific example, I was able to say with a little bit more confident that the regression was introduced by Grape::Util::StackableValues#[] since it accounted for 65% of CPU time.

Next, I found the very version introduced the regression is 0.17. Scanned through its commits, one particularly caught my eyes: Improve grape performance

       def [](name)
          return @froozen_values[name] if @froozen_values.key? name
 -        value = [@inherited_values[name], @new_values[name]]
 -        value.compact!
 -        value.flatten!(1)
 +
 +        value = []
 +        value.concat(@inherited_values[name]) if @inherited_values[name]
 +        value.concat(@new_values[name]) if @new_values[name]
          value
        end

It’s easy to see why the second implementation is preferred since Array#concat does automatic flattening if given object is an array.

The problem lies in the effort to prevent nil, which was handled by Array#compact! in previous versions. Here, it is done by adding conditionals to each #concat statement. Which may seems to be harmless and intuitive, these two conditionals actually cause multiple recursive calls of Grape::Util::StackableValues#[], one in conditional, and the other in the statement itself if the conditional is true. As we can see from following profiling result, the difference is enormous:

# v0.16
     TOTAL    (pct)     SAMPLES    (pct)     FRAME
       627  (33.7%)          98   (5.3%)     Grape::Util::StackableValues#[]

# v0.19.1
     TOTAL    (pct)     SAMPLES    (pct)     FRAME
     84460 (131.5%)        5726   (8.9%)     Grape::Util::StackableValues#[]

From what we’ve known, the solution should be eliminating duplicated calls of Grape::Util::StackableValues#[] in a single statement, while prevent feeding nil to Array#concat.

Here’s my commit to Grape, which is merged and expected to be included in next minor version:

       def [](name)
          return @froozen_values[name] if @froozen_values.key? name

          value = []
 -        value.concat(@inherited_values[name]) if @inherited_values[name]
 -        value.concat(@new_values[name]) if @new_values[name]
 +        value.concat(@inherited_values[name] || [])
 +        value.concat(@new_values[name] || [])
          value
        end

There was a concern on using empty array would cause extra memory consumption. In the end, we’re convinced it would only take a minor GC to recycle that array thus no memory overhead.

《瘋狂改變世界：我就是這樣創立Twitter的！》

2016-04-05T00:00:00Z

一家企業既可以成就事業、承擔社會責任，也可以使其工作內容充滿趣味。當這三個願景交相暈映，才不會讓人利慾薰心。
如果你主動去創造機會，你就已經處在有利的位置了。
「你的目標要比你的自尊心還大。」
如果你對你正在作事情並不熱愛、如果連你自己都不是自家產品的忠實粉絲，那即使你把每件事情都做得很到位，你最後還是會以失敗收場。
ARM CEO：「我們給了團隊：沒錢、沒時間、沒資源。」擁抱人生的各種限制吧。
一個成功的軟體平台首先服務使用者，其次讓上頭的開發者得到回饋，最後再來提升平台的整體價值。
「如果一個產品有一百萬以上的活躍用戶，那它是能夠賺錢的，所以別著急。」
雙贏才是唯一的好買賣。
CEO 至少有一半的時間花在溝通。

《行為的藝術：52個非受迫性行為偏誤》

2015-04-19T00:00:00Z

精彩！作者用52則精準並俱說服力（意即：有科學實驗佐證）的文章，為讀者剖析出許多人們行為上的謬誤。文字不但精確，且讓人不時頻頻點頭表示贊同。

下面列出幾則我覺得特別有感觸的：

理由的正當性－爛理由也是理由
全書的第一篇便讓我覺得挖到寶了，或許跟No.23提到的首因效應也有關吧？
威爾．羅傑斯現象－如何不費吹灰之力，就交出亮眼成績單
除了學到一個投機取巧的方法外(?)，也讓我警覺到平時判斷的一些盲點。
資訊偏差－如果你有敵人，就提供資訊給他
身為理工人，自然會覺得有越多資訊可供決策越好，但很多時候過多的資訊對於作出好的決定不但沒有影響，甚至只是浪費更多時間而已
簡單的邏輯－不要相信每一個直覺
在很多時候，我自己對於看似簡單的問題，也都會偏好直覺反應，但這輕則考試扣分，重則容易停止思考、變得迷信，實在是不可不慎。
情意的捷徑－為什麼你是感覺的傀儡
必須承認我是個很感情用事的人，容易因為情緒的波動而作出不理智的決定，所以覺得這篇最後的建議十分有用：先將想法條列出來，接著再把每一個想法前面加上「我覺得」，再來辨認何者為感覺的Heuristic所產生的。
內省錯覺－為什麼你應該成為自己的異教徒
這篇給了我不小的震撼，因為我本來就是個喜歡自己和自己對話，對某個主題／想法作討論的傢伙，但是這篇卻提到這樣的內省很多時候都只是會為了已有的信念作加強、扭曲甚至辯護而已！也因為如此，越是深信不疑的想法，越是需要抱持懷疑的態度去審視才是正解。
無法關上機會之門－為什麼你需要破斧沉舟
當談到選擇時，我大概是我認識的人當中，最優柔寡斷的一位了。主要的原因，就是這篇所談的主題：不願意放下任何一個可能的選擇或是現有的機會。破斧沉舟確實是古人智慧的結晶啊。
選擇盲從性－為什麼你總是對最好的選擇視若無睹
當在考慮是否要作某件事的時候，我想大多數人可能當會如我一樣，只以作與不作的情況來作考量吧，但很多時候其實最好的選擇並不在這兩者之間，而是存在於第三種、第四種、甚至無限多種可能之中，只是我們的注意力就只讓我們專注在這全有或全無的選項內。
放血效應－為什麼我們對愚昧無感
即使我們知道我們現在所作的、所奉行的是錯的，但在沒有「心目中更好的選擇」出現之前，我們還是會繼續維持原有的舊模式。但要是原有的舊行為是有害的呢？我們卻仍會繼續進行，造成更多的傷害。書內建議定期巡視自己所奉行的理論與想法，若是發現有誤，就請用沉沒成本的概念，馬上棄船吧！
非我發明症候群－為什麼自己做的料理總是比較好吃
人們容易偏好對自己所創的事物早已不是新聞了，真要選出最好的方法，就對於自己所創的理論或方法作雙盲測試吧！
假共識效應－為什麼你認為他人想法與你一致
當我們相信一件事情的時候，總會認為其它人也跟自己一樣－『怎麼可能有人會這麼蠢相信這種事情』－對！就是有跟你不一樣的人會跟你有不同的信念，所以別再拿自己當作是通則，而否定某些論點或相信大家都跟你一樣了！
歷史修正－為什麼你總是對的
看過許多人在否認自己曾作過某些事時，或許不用相信對方是刻意的，因為人類的記憶本來就不可靠，會改變記憶來配合現在的思想。
圈內圈外偏見－為什麼要認同足球隊
作者用了一個我很喜歡的例子：為何科幻電影裡的人類總是文化多元，而外星人（通常是壞人）都像是一個模子刻出來的？因為我們容易對現在所在的團體有認同感，而對陌生人抱持著懷疑的態度，另一個明顯的例子便是戰爭時前線的士兵對家國的認同以及對方士兵的敵意。或許是因為作者為德國人的緣故，最後一句更是殺傷力十足：「那些為他人而戰的人們不是勇敢，而是愚蠢至極。」
對模糊的無法容忍度－為什麼我們不喜歡面對未知
風險與模糊性有不同，認知到這點，才能夠清楚思考，畢竟外頭多的是模糊的情境。
對懊悔的恐懼－為什麼「最後的機會」會讓人失去理智
超容易被這種商法攻陷的我來說，這章看得頗是羞恥啊。
顯著性效果－為什麼引人注目的不一定是重要的
有多少次人們看到外勞犯罪的新聞時總會露出厭惡的表情？甚至有人會開始宣稱外勞是社會的亂源？當我們將所有的標籤去掉，更多時候本地人才是犯罪率最高的族群呢。只是人們都偏好找出不同的地方，將其當作是最重要的因素，但別傻了，那幾乎不會有任何的影響。
「那殺不死我的，將使我更強壯」的謬論－為什麼危機極少成為轉機
一言以蔽之：生存者偏差以及樂觀歸因。
顧慮太多－何時該讓大腦休息
有些時候，過多的思考反而會妨礙直覺的運作，就如同許多運動選手失敗的故事一般。學會何時思考，何時相信直覺，也是個重要的課題。
專業曲解－手拿錘子時，眼中的問題都像根釘子
對於專業人士來說（例如軟體工程師），總是會以自己的專業領域來思考，如何跳進別人的鞋子？
能力錯覺－懂得划船不如選對船
究竟那些成功的CEO們有什麼秘訣或能力可以打造一間甚至是多間成功的公司？答案是：運氣。也就是說偉人傳記是打發時間的有趣讀物，但裡面提到他成功的理由？當作網路文章看過就忘吧！
單因謬誤－石器時代式的尋找代罪羔羊
「為什麼蘋果熟了會掉下來？」真的只是因為地心引力嗎？別再相信只有一個原因了！
新聞錯覺－為什麼不該閱讀新聞
那…… 我是不是該放棄看RSS的習慣呢？orz

《快不能解決的事》

2015-01-04T00:00:00Z

博客來-快不能解決的事

讀完全書，其實會發現內容便是其所闡述核心思想的體現：一個複雜的問題是沒有一個簡單快速的解法的，本書所想作的，只是整理出數條在思考解決方式時的通則，提醒讀者於過程當中該注意些什麼、如何從他人的經驗中尋找洞見。

就誠如書名，本書提倡的是慢速解決法，以《快思慢想》的論點來說，便是第二種思考路徑，而非第一種直覺式的思考。雖說有一章節是在談一萬小時的練習後所訓練出來的直覺對分秒必爭的情況助益良多，但現代社會裡的許多問題都不是當下可見，甚至是幾十年後才看得到的抽象問題，這時直線思考所帶來的壞處遠大於其可能的優勢。

然而說是這麼說，但我總覺得，人們偏好快速解法的問題本身也是一個需要slow fix的議題，因此不免會有些雞生蛋蛋生雞的兩難。在我們之中，有多少人是真的在遇到問題時，可以真的靜下心來，忍住目前的不適或是衝動，試著從更宏觀的角度來解決問題的？當身材走樣時，有多少人能持之以恆地運動、吃營養均衡的食物？當小孩不服管教時，有多少人能夠忍住處罰治標的衝動，而試著找出問題的根源？當別人犯錯的時候，有多少人不會冷嘲熱諷，而是看到背後發生的原因及真正的問題？直到我們能打破這樣的輪迴之前，我覺得要直接apply書內的建議也不過僅是另外一種的quick fix而已。

回到內容，在讀前面幾章的時候，我一直想到之前看過 thinker 前輩對於工程師如何解決問題的洞察，也不斷地想到自己很多時候在解一個問題時，確實很容易就落入快速解決它的思維，而沒有好好考慮到這是否為我們要解決的問題？目前找到的原因是根源，亦或只是病根的side effect？會不會是更宏觀的設計上有誤？

當然也別忘了，書內放在第一條的金科玉律，便是要先承認我們自己犯了哪些錯，這在我們現今的社會內是多不容易的事啊，我們都聽過IBM早期的一則軼聞：

有位高階經理作了失敗的投資，導致公司損失三萬美金，CEO找來這位經理，他一進到辦公室就跟CEO表示自己有多麼抱歉，若是CEO要開除他，他也能夠理解。CEO笑了笑，「開除你？我才剛花了三萬元在你身上投資了一場教育訓練呢。」

可是我們從小的教育，便是警告我們不得犯錯，犯錯帶來的只有處罰和它人的恥笑與責罵，華人文化內崇尚的完人概念更是讓我們把犯錯作為弱點而極力隱藏，看看那些公眾人物的新聞，難道這樣的文化帶給我們什麼還不夠明顯嗎？

書內讓我感受頗深的另外一個部分便是團隊合作，且是來自不同領域、不同教育程度、不同社會階級的合作，而非僅止於身份、背景相近的團體。然而現實的情況卻常常不是如此，我們常常見到有些意見因為發言者的教育程度而被自命不凡的知識份子輕視；我們不時遇到不同領域的團體互相排斥溝通；就算是在同樣大環境下同樣背景的人們，也會因為理念不同、個人利益乃至於自我感覺良好導致的夜郎自大而彼此攻譙、瞧不起對方。另外一點則是理工科系出身的我們容易忽略，但卻至關重要的一點：人是有情感的動物，任何邏輯上可行的辦法，若是經不起情感的驗證也是徒勞無功。

[RubyKaigi 2014] Cores unleashed Part II: Introduction to GobiesVM (and Software Transactional Memory)

2014-09-28T00:00:00Z

Slides

Presenter’s comments:

Hello RubyKaigi. Today I’m going to talk about what I’ve been doing in the past few months. A Ruby virtual machine called GobiesVM which applies software transactional memory.
I’m 許斯凱 from Taiwan, or you can find me on twitter and github by the name brucehsu.
I just received my Master’s degree in Computer Science from National Chung Chung University. The topic today is actually my Master thesis. And one more thing, it’s Chung Cheng University, 中2大学ではありません
I currently work for GoodLife.tw as a web developer.
I actually gave a related talk at RubyConf Taiwan this April. So I’m going to quickly recap some concept I’ve already illustrated back then. You can find my talk on youtube for details.
Let’s take a look at how Ruby implementations do when it comes to concurrency and parallelism. First, there are some differences between Concurrency & Parallelism. Concurrency means a job can be divided into independent blocks and execute at any order. Parallelism is the ability to run them simultaneously. If we scan down the table, we can see MRI do provide concurrency models like Threads and Fibers, however due to the existence of GIL, it cannot use up all spare cpu cores. Since Rubinius and JRuby uses finer-grained locks to implement their internals, they both provide full parallel ability. Topaz, which is based on PyPy, has neither.
Here is an actual example to show the impact of lacking parallelism on CPU usage. This is a script that reads text files in parallel and count the words in them.
We can see the CPU usage of MRI seems good at the first glance. But when you look closely, you find the third chart is actually a complement of the first one. So we only have total 100% usage instead of 200%.
The overall usage of Rubinius is much higher by comparison.
And so is JRuby. But there is more to the parallelism problem than just CPU usage. When writing parallel programs, we the developers need to be aware of data synchronization issues. This is one of the reasons why MRI still uses GIL.
We have another script to validate thread safety for each implementations. It spawns four threads to add new elements to an array. The correct size of the array should be 10,000.
MRI with GIL provides some level of thread safety, therefore the result is correct.
Since we did not synchronize the array, the result of Rubinius would be wrong.
Things are slightly better with JRuby. For the most time it would trigger an unsynchronized error. Yet it may still print the wrong result.
Of course we have many mechanism to solve this kind of issue. The most popular may be the traditional locking mechanism. But locking is a primitive mechanism, it is error-prone and can produce unexpected bugs. That’s why various solutions have been proposed.
Among them, one of the promising alternatives is Software Transactional Memory, or STM. It borrows the concept of Transaction from Database and apply it onto memory access. Unlike HTM in the previous session, since it took a software approach, it is theoretically platform and cpu independent.
So let me introduce GobiesVM, a brand new Ruby implementation utilizing Software Transactional Memory.
leverage Go runtime GC; since tinyrb uses LEG grammar file…; the bytecode instructions are similar to YARV
The workflow of GobiesVM is not that much different than others. It parse source code into a syntax tree then compiles it to bytecode instructions. VM will execute these bytecode instruction.
The biggest difference however, is that VM will dispatch instructions to separate coroutines and let the coroutine to execute the instructions in forms of transactions.
So the first problem we encounter is how to define a range for each transaction, right? Here we pick two instructions, one is GETLOCAL and the other is SEND. They are chosen due to their nature of frequent occurrence and possibilities to change things.
After we have our transactions, we can proceed to the execution. GobiesVM uses a traditional STM algorithm named Transactional Locking 2. In TL2, the environment requires a global timestamp to distinguish object revisions. Meanwhile each transaction would sample global timestamp and maintain their own local timestamp which indicates the initialized time. They also maintains two sets, namely read set and write set, to record object manipulation log.
When the VM has done initializing the environment, it enters a stage called Speculative Execution. It means during this stage, no modification would be done to the memory. It only modifies the memory after we validate and commit the transaction. There are three possible scenarios. First is to read a variable. When we read a variable, VM would check the symbol table and returns the actual value of it from memory. At the same time, it would mark the address in the read set to indicate the variable has been read.
Next, when we write to a variable, we won’t directly modify it in the memory. We actually create a pair of memory address and value and save it to the write set.
If we need to read the variable again, the VM would find the latest version from the write set.
Of course the two-set operation seems a little bit complex. So we simplifies that in GobiesVM by combining them into a single object. It’s a hash that uses memory address for both key and value.When the key equals value, then the object has only been read.
If the value is different from the key, we can know that the object has been changed therefore we created a new object.
Before it commits the changes, VM first validates the transaction. It checks the revision of objects we read during the transaction. If the revision is larger than local timestamp, then the object is modified during transaction. So we abort and retry it again. Then we try to acquire the write lock of modified objects, again we abort and retry on failure. If both validations pass, the global timestamp would be updated by incrementing one.
Eventually, we can commit our changes to the memory by copying the new object to the original one.
But just like Linus said, talk is cheap.
So I’m going to show you GobiesVM.
So what lies ahead for GobiesVM?
I mentioned current LEG parser does not do well with the versatile Ruby syntax. In fact, Go does come with a custom version of YACC parser called goyacc. However, what it is lacking is a lexer. Unfortunately, the golex project has went into hibernation for quite some time and I have no intention to reinvent wheels. So far the most promising solution is the lexer project from sourcegraph.
Besides parser performance, we also need better support to Ruby syntax. Until now, some important features are still missing. For example: …
Also, we need a way to specify atomic operations. My plan is to have an atomic block syntax. However the new syntax alone cannot prevent developers from writing unsynchronized code. That’s why I also want to make every single statement an atomic operation.
perhaps some of you would like to use GobiesVM in production which I personally do not recommend. in order to achieve that, we need rubygems. Currently when GobiesVM crashed, it only prints out a incomprehensible list of Go stack trace. Not only it scares ordinary developers like you, it also makes my job to debug very difficult. So I hope to get rid of this issue soon.
大事なことなので二回言いました。In general, current transactions are too short thus introduces some overhead. I’d like to implement a transaction length control algorithm from Odaira-san.
Again, you can find GobiesVM on github. Looking forward to your thoughts and pull requests.

由GobiesVM的IO.readlines實作論Go讀檔及MRI效能

2014-07-19T00:00:00Z

昨晚寫完 GobiesVM 裡的IO.readlines函式後，很開心地用了有著100k個單詞的單行文字檔作測試。咦？怎麼一個字都沒有？

第一版的IO.readlines實作，就如同你在stackoverflow上會找到的一樣，是用bufio.Scanner來讀文字檔

input, err := os.Open(filename)
scanner := bufio.NewScanner(input)

for scanner.Scan() {
  line := scanner.Text()
}

上面這段code看似沒有問題，在一般的文字檔（例如程式碼本身）測試也都正常，為什麼在遇到大檔的時候就出包了呢？
當我們去看 bufio.Scanner的實作時，會發現 Scanner 在運作時，會將文字分為一個個的token，並交由SplitFunc決定如何區分token（預設是斷行），由於是buffered IO，所以會有每個token所能用的buffer的最大size（MaxScanTokenSize = 64 * 1024），以上面的檔案為例，因為100k個單字全部都集中於一行內，所以很輕易地就超過了這個限制。因此當我將每個詞分至多行後就可以正常運行。

有鑑於這樣的解決之道只是治標不治本，所以讓我們來看看第二個版本吧：

input, _ := os.Open(filename)
defer input.Close()

reader := bufio.NewReader(input)

line, err := reader.ReadString('\n')
for ; err == nil; line, err = reader.ReadString('\n') {
  // Do something
}

同樣在bufio之下有實作io.Reader的buffered Reader物件可使用，裡頭也提供了bufio.Reader.ReadLine()可用，不過在文件內提到一般建議使用bufio.Reader.ReadString('\n')，而 bufio的實作內也是後者單純些。

註：這裡雖然有印出內容，但以下的測試皆改為僅只有印出回傳陣列的大小，所以速度會有所不同。

這次測試出來的結果，相當地令人滿意，至少就如同上圖，GobiesVM的IO.readlines所用的時間都比MRI來得少。

然而事情沒有憨人想得那麼簡單，在不安穩的一覺醒來，我再度用10M行的文字檔作測試時，GobiesVM就原形畢露了。此時的MRI平均只要4秒多就能夠讀取完畢，而GobiesVM則要11秒左右。

當然最便利的藉口就是：GobiesVM沒有作最佳化！所以我就跑去編了個把最佳化（這些選項位於vm_opts.h裡，如果你想知道的話）全部關掉的MRI出來了…… XD
把最佳化全部拿掉之後的效果十分顯著，完成時間都在30秒以上。

……好吧，這樣的方法基本上只是自嗨，還是得找出一個比較實在點的方式才行。
可能的overhead在哪裡呢？一來當然就是即使Go效能出眾，但在多數時候拖著一個Runtime的它還是比輕盈的C還要來得慢些，二來buffered IO本來就是一個chunk一個chunk地讀進來時作處理，甚至會丟掉在所設定的delimiter後的內容，這樣難免會有些overhead。

所以綜合以上兩點，最偷吃步的方法就是：一口氣將檔案讀進來後再處理斷行：

content, _ := ioutil.ReadFile(filename)
str := string(content[:])

lines := strings.SplitAfter(str, "\n")
for _, line := range lines {
  // Do something
}

以下是簡易的效能測試

GobiesVM	MRI 2.0.0
7.930	4.495
8.004	4.058
7.102	4.649
7.075	5.129
7.521	4.192
7.696	3.851
7.202	4.490
7.327	3.732
7.606	4.082
7.536	4.041
Mean
7.499	4.272

雖然還是有2~3秒的差距，但其實這也差不多是多數benchmark中Go與C本身的速度差異，所以個人是覺得這樣的結果尚可接受，況且再繼續追下去所花的時間與得到的效益相比可能沒有那麼高。

喔，有些人可能會好奇將檔案全部讀入是否會讓記憶體的使用量飆高，根據不負責的觀察，在使用第二個方法和第三個方法的memory peak並沒有明顯的差異（吃記憶體同樣都吃很兇的意味，而MRI本身也差不多）。

LEG/PEG in Go實作

2014-03-10T00:00:00Z

最後的成果在這個repo裡： https://github.com/brucehsu/peg/tree/leg

來龍去脈

決定要用Go寫Ruby VM之後，第一件事情當然就是尋找Go上的parser generator。
Go裡頭就包含了自己的yacc工具，與原先的yacc語法完全相容，加上Ruby（MRI、mruby）都是使用yacc來作為生成parse的方式（詳見各repo底下的parse.y），所以一開始很直覺地就把goyacc列為solution。
但是goyacc在使用上有個要注意的地方，就是 c9s前輩所提到的：它跟原先的yacc一樣，還需要跟lexer作搭配，但golex這個project卻已經無人維護許久。

之後在唐鳳前輩的指點下，決定採用tinyrb中以LEG/PEG定義出的Ruby subset作為發展的基石，況且在 RubyGoLighty 這個以tinyrb為底並Go實作的project當中，除了提供一個stack-based的Ruby VM外，還手動將LEG/PEG轉換成了Go code，看來可以省下不少麻煩。

但等等…… 因為其年代久遠（四年多前），裡面的Go code看來一點都不像Go，而只是如C的直接貼上（不過我沒有build過或是認真看過，或許可以正常使用也說不準），要修改也有些難度，難不成只能重新再造輪子了？

經過一番搜尋，發現其實之前就已經有人重新用Go實作了PEG 並加入一些Go限定的功能，而且到去年9月時仍有commit，只是事情有一好沒兩好，這位作者只有實作PEG的部份，不含LEG。

剛好我也打算再跟Go混熟一點，幫這個project加入LEG的支援看來似乎是個不錯的練習，只是我沒想到會拖那麼久…… orz

PEG

說了這麼多，還沒有介紹PEG和LEG到底是什麼。

PEG是Parsing Expression Grammar的縮寫，是由 MIT的Bryan Ford 所提出用來定義語法的context-free grammar。作者網頁上也列了根據他的研究所寫出的不同語言的實作版本，最為人所知的當然還是 C語言版，也就是peg與leg這兩個工具的來源。

基本上的使用，如果之前有lex/yacc或Regular expression的經驗應該可以快速上手，下面稍微列一下定義：

name <- pattern，不同於yacc，是以<-作為assign operator
seq1 / seq2 / seq3，不同於yacc，是以/作為OR
. match任一字元
[characters] 括號內的任一字元， [^0-9] 開頭的^是除了特定字元外的意思
( pattern ) 將括號內的pattern歸為一組
< > 會將兩者內的字元累積起來，放至yytext變數中供人使用
? 有或無， + 至少一個或以上， * 無或一個或以上

以上是基本的語法元素，PEG也定義了如果對這些元素作條件判斷：

Predicate 為有著成功或失敗狀態的構詞單位，失敗時不會消耗掉input， & element以match為成功， ! element則以不能match為成功（著名的例子是!.作為EOF）。 & { action } 是特殊的predicate，如果action回傳為true，則繼續執行剩餘的element，為false則尋找是否有替代的rule。在C和Go版本的實作中，以上三種類型分別被稱為PeekFor, PeekNot, Predicate

LEG

因為yacc的悠久歷史，導致許多的project都是使用yacc所定義的語法，如果要想轉換到PEG上還會因為功能上的差異而花一番功夫，於是C版本便提供了與yacc相容性較高的leg作為解決方案。

LEG在定義上與PEG的不同之處在於：

name = pattern，改用了=來作為assign operator
seq1 | seq2，與yacc相同用|來作OR
rule name可以使用 -，像是rule-name，會被轉換為rule_name，也可以單獨使用-
; 可以被用來結束一個pattern (optional)
%{ text... %} 會將text部份全部copy到生成的go source code的開頭
``%%` 會結束rule宣告的section，接下來所有的text會被複製到go source code的結尾
exp ~ {action}，只有在前面失敗的時候才會呼叫 action
$$ = value，大概是最大也最重要的不同，LEG可以指定該rule回傳的semantic value，value type都一樣，預設是int，在C版本中是用YYSTYPE來指定
identifier:name，承上，因為可以指定semantic value，所以提供了自定變數名稱的方式來代表回傳的semantic value

目前我大概只剩比較次要的功能沒作（;和~ {action}），其它的都已經完成。

PEG in Go的設計分析

首先，先來看看Go版本的PEG包含了哪些東西。
基本上主要使用的source code file都在根目錄底下了

set.go: 恰如其名是集合資料結構的實作，主要用於以switch來最佳化生成的code，因為我沒有碰到最佳化的這一塊，所以無從奉告XD
bootstrap.peg.go: 由PEG本身generate出來的PEG parser，待會再細談。
peg.go: 整個PEG的核心，定義了AST的資料結構和相關的function，將AST compile成Go code也是在這裡完成的。
peg.peg: 用PEG來定義PEG，詳見C版本的man page ，值得注意的是Go版本針對部份rule作了些修改。

如果單純看bootstrap.peg.go的程式碼可能會有點摸不著頭緒，好險原作者也把當初怎麼生成bootstrap.peg.go的方式留在bootstrap/裡頭，所以我們可以透過bootstrap/main.go的內容來一窺AST的生長方式。

peg.go

AST

就如同許多compiler一樣，PEG也是先建出AST之後再將其compile成source code，樹根為Tree資料結構，除了有些額外的性質外，基本上是前面定義過的node linked list，而它的nodes一開始都會是一條條的rule（TypeRule），直至要compile前進行處理時才會有所更動。

每個TypeRule的node底下，也只會有一個屬於三種list type（TypeSequence、TypeAlternate、TypeRange）的node，完整的定義則是在這個list node裡頭。

TypeSequence就是很簡單的list，一個接著另一個。
TypeAlternate是在如果rule有所分歧的時候，即是seq1 / seq2 / seq3的情況。以前面為例子，這樣的一個TypeAlternate node底下分別會有三個TypeSequence node。
TypeRange只會有兩個child node，負責a-z的情況。

除了list types外，還有另外一類的fix types，用來代表+ * ? <> ! &的情況。當你加入一個fix types的node時，它會把前一個node加為自己的child，並取代它原本所在的位置，簡而言之就是直接長在前一個node的頭上。

Complication

在compile AST之前，PEG會先作過數種處理：

anoymous function link(n Node)及其後的first/second pass
基本上是幫忙建立t.Rules的清單，比較不一樣的是會再建新的rule來包裝TypeAction。
join([]func() {...})
內含兩個anoymous function，一個是算各條rule被用到的數目，另外一個則是檢查是否有left recursion
t._switch
最佳化，此處不談，因為我也沒看 :p
print 系列anoymous function
這些function是為了生成最後的source code所用的，有printSave, printRestore, printTemplate, printRule, printBegin, printEnd, printLabel, printJump, printRule，後面會再說明。

Complication的部份，是先利用Go提供的text/template將Tree裡的特定變數塞至檔案開頭所定義的template PEG_HEADER_TEMPLATE中再印出成為bootstrap.peg.go的開頭，剩下的部份則由compile(n Node, ko uint)負責。
這部份我就直接留到bootstrap.peg.go時再一一說明，個人覺得有例子對照比較好了解最後會生出什麼樣的東西。

bootstrap.peg.go

這裡要談的只有兩個functions：Init()和Execute()，這可以算是PEG裡面最重要、最核心的兩個functions了。

Init()顧名思義，就是PEG parsing的初始化，或許有人會納悶怎麼沒有yyparse()可用，其實是因為在Init()中就定義了一個可以被呼叫的Parse(rule ...int) error function了。
在 peg.go 中，最後的complication主要就是輸出到Init()的尾端，作為rules這個array的內容。
這個array包含什麼呢？其實就是一連串回傳bool的anoymous functions，每個function都代表著一個grammar rule，如果match成功的話就會回傳true，反之則false。
每個function都身兼lexical及syntax parsing，假設有條rule是這樣的：Rule <- 'Hello,' ID，那個該function內就會先用一一去比對目前的input開頭是不是Hello,，如果不是就會利用goto跳到return false的地方。當遇到需要比對另外一條rule ID時，就只要呼叫rules[ID]所對應到的function即可。
當一條rule比對成功後，就會將目前的位置連同Rule名稱加入到TokenTree裡頭，以便之後Execute()可以依序執行結果。

綜合來說，你看到的code大概會是下面這樣樣子：

{
  position118, tokenIndex118, depth118 := position, tokenIndex, depth // 儲存目前的位置、token數量和深度
  if buffer[position] != rune('H') {
    goto l122 // when failed
  }
  if buffer[position] != rune('e') {
    goto l122 // when failed
  }
  ...
  if buffer[position] != rune(',') {
    goto l122 // when failed
  }
  
  // 呼叫其它rule作matching
  if !rules[RuleID]() {
    goto l122 // when failed
  }
  
  add(Rule, position118)
}
return true

l122:
  position, tokenIndex, depth = position118, tokenIndex118, depth118
  return false

還記得前面提到的Parse()嗎？其實它所作的就只是呼叫第一條rule所對應到的function讓程式生成TokenTree而已。

接著我們來看Execute()的內容，會發現裡面其實並不是所有的rules都會被執行，只有RulePegText及RuleAction系列，前者是TypePush和TypeImplicitPush所產生的，用來指定截取文字的範圍（補充說明：TypeImplicitPush其實在編譯時會被加入在TypeRule當中，所以你才可以用buffer[begin:end]來取得rule的文字內容），後者則是使用者自行定義的行動。

LEG in Go的實作筆記

一開始我是從最基本的declaration和trailer作起（分別是加code到檔頭和檔尾），實作的方式很簡單，就是直接幫Tree加上新的string member，然後讓text/template來處理剩下來的問題。讓Rule名稱可以使用-也蠻基本的，只是在作self-illustrated的LEG時會需要注意一下，不然就會當成TypeRange去了。（我還為了這事搞了很久，因為bootstrap.peg.go雖然沒問題，但是編出來的leg指令再去編leg.leg出來的結果會噴錯 😕）

接下來才是最惱人的部份：如何加入semantic value？

敝人資質鶩鈍，故想了幾天、參考了C語言的版本許久才終於想到一個方法：

首先加入一個新的type　TypeVariable，讓它成為TypeName的child（畢竟Varaible name是和呼叫rule的TypeName綁在一起）

在建立完AST之後，先作過一次AST的DFS traversal，並計算到某TypeAction node時該rule已定義的varaibles，再藉其數目來得到各semantic values於stack中的位置。由於Go沒有像C macro的功能，所以不能如C版本的leg一樣用#define var_name stack[pos]這種簡單方式來作變數取代，所以我是先用regular expression取出變數名稱後，再一一取代回原字串。

只是這樣只能處理有著固定數目的變數，如果一條rule內有像TypeAlternate的分歧，靜態分析就會錯誤百出，所以實際上還是得在建TokenTree的時候，動態去操作stack才行。於是我便加入了RuleActionPush及RuleActionPop這兩個負責stack operation的類別，然後於compile時期，幫有用到variable的rule加入variableCount來統計目前執行階段有多少個variable，並於最後將所有的varialbe都pop出來；如果中間遇到TypeAlternate分歧，會另外再建一個新的variableCount{NUM}來儲存進入前的variable數目，並於離開時pop掉多出來的variable，然後把variableCount設回進入時的數值。若是rule本身有用到semantic value（如何判斷？直接看底下的actions有沒有用到$$就好了XD），最後也會將目前的semantic value給push進stack裡。

關於上面的作法，各位可以參考這幾個commits：

《真愛每一天》(About Time)

2014-02-23T00:00:00Z

終於看了被許多人稱為去年最好看電影的《真愛每一天（About Time）》。

單看預告，會讓你以為主題便是男主角如何運用時空穿越的能力來贏取美人芳心的故事。對，但也不對：與愛情相關的部份在前段就說得差不多了，基本上就是預告中的那幾段，導演所要呈現給觀眾的並不是愛情多麼地迷人、多麼地刻骨銘心。
而是要把握當下的時光，留意生活中每一處的美好，以及對於在你身邊，那些愛著你的人們，用同樣的愛作為回應。
這是一個如同英文片名所說，關於時光的故事，亦是跟中文片名一樣，告訴我們真愛便是存在我們每一天的生活當中，我們只需注意到即可發現的那些美好事物。

聽來的確老套，但這也正是為何它如此觸動人心的原因。裡頭講述的，就好像我們每一天都會遇到的事情一般，充滿笑容、歡喜、希望、後悔、失落、憤怒、悲傷。雖然男主角有穿越時空的能力，但每次決定都得到了什麼卻也失去了什麼，誠如俗話所云：有捨才有得。甚至到了最後，他已經放棄使用這個能力，然而幸福卻沒有因此而減少一分一毫。

為什麼呢？讓我來講講我最喜歡的一段吧，那是他遵循父親的建議，重新經歷過每一天，但以不同的角度看事情：當你去買午餐時，你可以眉頭深鎖地跟店員互動，你也可以用笑容讓對方的一天更美好（我愛死這段前後對比式的分鏡了）；電車上隔壁的男子耳機中傳來吵雜的音樂，你可以為其煩躁，你也可以自得其樂。

一切皆在你如何看待生活中的任何一件小事，你想過著怎樣的生活。

因為你現在正活在其中。

RubyConf Taiwan 2012 雜感

2012-12-10T00:00:00Z

開頭先講個題外話：為了傳這篇文章內的照片，在寫之前還花了時間寫 Imege 這個工具來放圖，只是不知道什麼時候會被打下來…… XD

從一開始就很期待這次的RubyConf Taiwan，主要跟大多數人一樣，都很希望能見到matz大神一面，只是為了配合matz，所以舉辦的時間點對我來說是有點晚的，不過看到這次除了matzさん外，還有一堆國外的朋友們會來，加上這次的talk很多與Ruby Implementaion相關的議題，不管怎樣都得排除萬難啊 :p

這次RubyConf Taiwan還多了第一天晚上的Official Party，當初想說認識的朋友應該都會參與，結果去到現場一問之下，發現會去的寥寥可數，害我原本還很擔心不善social的我是不是該臨陣脫逃，就結果論來說似乎是多慮了。（詳細的情況就請繼續讀下去吧:D）

Day 1

一大早到這次的會場，天母農訓中心（沃田旅店），對於之前只到過中研院的我來說有種新奇感。

場地本身設備還不錯，只是不知道是否投影機的燈炮壽命將至，感覺投出來的畫面偏暗又不夠銳利，每排的前面間隔有點近，對於體態不小的我來說要在有人的情況下出入實在有點困難。

另一方面，或許是地點與以往多數的conference不同的緣故，所以大家來得都比較晚一些，結果就是為了讓大家吃早餐就晚一點才開始第一個session…… XD

值得一提的是，今年的午餐就是直接由會場單位提供現在烹調的自助餐，而且口味還蠻多樣的，當然也比其它conference提供的便當好太多了，最重要的是，還有桌椅可供大家與其它會眾social，就算沒佔到大神旁邊的位置，要在吃飽飯後locate對方也不是什麼難事，像我就是趁這個機會和matz大神合照了一張。

接著說一下我比較有印象/興趣的session：

Matz: Keynote

長達203頁的史詩鉅作(?)，聽到matzさん對於許多議題的想法，以及對Ruby乃至於整個開發者社群未來的期許，真的是讓人覺得相當地感動啊！
最讓我印象深刻的便是matzさん提到關於Motivation的重要，以及以下這句：“Diversity is the cost of innovation.”
因為有談到Ruby 2.0和mruby的緣故，所以我也舉手問了MRI會不會移除GIL/GVL（一方面也是因為看到了這篇），結果答案就跟裡頭的回答一樣XD

Wei Lu: A Journey into Pair Programming

其實原本好像是jserv的session先，只是後來好像臨時換檔？
講者用了很活潑的口吻來介紹Pair Programming以及其中會遇到的一些問題，投影片內所用的哏也很能引起人共鳴且精準，聽完之後才發現我對Pair Programming的印象是錯的 :x
另外本場也出現了這次RubyConf Taiwan的第一個哏：因為講者是位來自新加坡的正妹，所以有位會眾就在Q&A的時候，問了講者能不能和自己Pair Programming，於是一個新的告白方式就這麼誕生了XDDDDD

jserv: 在自動控制領域應用微型 Ruby

這是我從一開始就準備要聽的重點session之一，只是沒想到jserv順應潮流，直接英文硬上，讓不少人錯愕了一下。
原本想說jserv會從OS先講起，但這裡終究不是OSDC.tw，所以是從為什麼選mruby講起，也才知道原來jserv最近又涉足新的領域了？ 😄
不過後面還是提到了如何在ARM上面最佳化mruby，講得淺顯又不失深度，不愧是大神啊。此時也發現mruby VM的bytecode好像跟CRuby不太一樣，看了一下source code發現mruby VM原來是register-based的VM，將此發現tweet上去之後，意外地得到matz的回覆，當然就很不要臉地再問下去了 :p

在jserv講完之後，對於talk中提到的裝置間通訊有點問題（因為之前在lab meeting上報了一篇embedded python的paper），就舉手問了jserv關於mruby有無FFI，結果又被redirect到matz那邊去了，雖然聽得不太清楚，不過好像是有的樣子？

godfat: Concurrent Ruby Application Servers

平日惠我良多的godfat前輩本次也有session（之所以會認識，其實也是因為去年在他講完rest-core之後拋開恥力跑去裝熟的緣故lol），這次的題目正好又跟我之前遇到的問題有所相關，聽完之後才發現其實沒有……XD
不過誠如前輩本人所說的，這樣的題目真的是很難一聽就懂，所以慧根不夠的我聽完之後還是一知半解，看來我還有待加強啊orz

Akira Matsuda: Ruby 2.0: New Features

Ruby 2.0可說是Ruby界的大事，在經過近二十年後終於要跳到新的major version，大家的興奮（或怕受傷害的心情？XD）可想而知。
之前也有看過一些關於Ruby 2.0 new feature的資料，但總覺得講得還不夠詳細，搔不到癢處。
而Matsudaさん一次就把這些遺憾給全部解決了！透過大量有深度的sample code來介紹各項新功能（包括前陣子在吵的refinement），也火力展示了Ruby metaprogramming能作到什麼程度，讓我只能暗中反省自己為何沒把Metaprogramming Ruby一書讀完。

Lightning Talk

本次Rubyconf Taiwan的Lightning Talk不同於以往，題目都十分的精實，所以聽一聽會覺得，這明明就很heavy啊XD!!!
而第一天幾乎全是來自國外的講者，除了xdite、小蟹和高見龍前輩們外。
其中最有印象的便是RubyJS的作者，直接在會場把RubyJS live open-source出來的時候了，這大概是今年Lightning Talk最像Lightning Talk的一段。XD

Official Party

如同我上面所提到，其實我本身不是個很會social的人，所以對於沒什麼認識的人參加Official Party這點相當地困擾，但是既然報都報了，只好硬著頭皮出席，沒想到結果意外地不錯。 😄

原本Party表定19:30開始，不過當我和Goodlife的Mark到時，裡面還沒什麼人，直到20點多，人潮才慢慢地湧現。
一開始對於周遭不熟的會眾，我還是不知道該怎麼開口，只好先去要了一瓶啤酒，沒多久就開始有人向先到的日本朋友們交談，我也就趁這個機會順勢而為，先試著和對方交換名片（結果他們都沒帶，變成單向拿XD），再慢慢聊一些其它的話題。

跟我同桌的是paperboy的三位工程師：Kentaro Kuribayashi、Kensuke Nagae、Shinya Tsunematsu，他們下午正好接連上台講Lightning Talk。
聊最多的，應該是Shinya Tsunematsuさん了吧，主要是因為他坐我旁邊XD。當他拿到我的名片時，似乎對Passionate一詞很感興趣，還跟其它朋友討論了一下，接著我們就聊起為何會有這麼多國外的朋友（特別是日本朋友）來RubyConf Taiwan，以及工作方面的事。
後來Mark加入後也聊到了台灣的工時及加班文化，才知道原來在日本，說一間公司很黑（ブラック）就是非常羞辱對方的講法了XD，而且他們對於工作10小時就已經很受不了的樣子。
我們也談到了日本與台灣社會的一些不同，像是兩邊年輕人對工作、未來的一些想法差異，還有兩國各自的社群活躍程度等，最後他還表示這次參加RubyConf Taiwan讓他對台灣人的印象非常地好，特別是我跟他聊過之後，看來我成功地進行了一次國民外交的動作？XD

接著高橋征義さん也出現在party現場，而且還是來到我們那一桌，所以在其它人來自我介紹完後，我也拿出名片，和他開始聊天，一開始是問他下午在Lightning Talk中提到的電子書系統的一些細節，到後來更大膽地問了他們公司所鎖定的市場在哪，以及能否合照這樣的問題。

此時發生了一件讓我很小鹿亂撞(?)的事，就是matzさん他跑過來跟高橋さん聊天！
在兩人看似聊完的空檔，我趕緊遞上名片，並開始自我介紹，然後說自己的研究題目是想作Ruby和OS相關的東西（有沒有覺得這人嘴炮點很高？lol），更藉機問了一些MRI的細節。
問完之後，又想到一個我一直想問的問題：究竟是怎麼的教育環境才能夠讓他能夠在大學時就寫出自己語言的compiler？這對於正在修研所Compiler的我來說是件很難以解釋的事，畢竟我當初大學部修完compiler直至現在都還沒有能力可以定義並實作出一套嚴謹的程式語言啊。（當然，我本身很弱這點就別提了……）
但是我得到的答案卻是他母校的課程安排其實與我們差不多，這就更讓我納悶了，轉念一想，再開口問matzさん，他覺得會不會是時代的演進所造成的呢？舉我們系為例，十年前的標準絕對比現在高很多。
於是乎我們又談起了現在電子設備的普及化和過度複雜導致深入學習的門檻變高，以及他覺得未來我們開發者該怎麼改善這樣的環境云云。
藉這個機會，我也拿之前與別人討論的議題出來，詢問matzさん看他認為初學者該學C語言好，還是Python/Ruby好，結果matzさん跟我一樣是C派的XD，他同樣認為學習programming就是要學不同的思考方式，如果用太過expressive的語言，反而沒有什麼效果。但是他也同意，要讓初學者產生興趣，還是用scripting language這種很快就會有回饋的語言比較有效。

這時，matzさん跟我說，我應該去和負責YARV的Sasada Koichiさん談談，因為他的研究領域正好就是OS和Ruby VM。
只是我過了一段時間才過去，而當我過去的時候，Sasadaさん已經準備離開了，所以沒能多聊，但是他表示已經從matzさん那裡聽到我的事，所以祝我研究順利XD。
而在他真正離開前，又問了一些關於Ruby 2.0中的YARV改進的地方以及新的Garbage Collection algorithm所帶來的效益，所以算是運氣不錯。:p

Day 2

今天不小心比較晚到，結果還是有很多時間吃早餐，同時亂入Mark與godfat前輩延續昨天session的討論，最後不知道為什麼聊到了steins;gate和Ever17。XD

下午的午茶時間也跑去跟Sasadaさん繼續聊昨天未完的話題，像是他在本日的session中提到的一些最佳化方法，以及其它Implementaion的design和目前YARV的bottleneck等，同時還有應該是來自香港的會眾過來問關於Concurrency/Parallal Computing的相關問題（聽了Sasadaさん的解釋，才了解原來兩者是不同的），也討論到了之後可能會往什麼方向作改進。
最後當然不免俗地和Sasadaさん合照一張 :p

這裡再說一下今天的session：