頻道 ʜ.-ʜ. ʜᴏʟᴇ 於 2022/02/22 創建，其實根本沒有想好要寫些什麼，反正不會是心裡話，畢竟都寫出來的東西還能叫心裡話嗎？太矯情了！
由於 Telegram 本身對於中文的搜尋能力很糟，所以張貼的內容會標記以下標籤作為分類依據：
• 「摘抄」#Excerpt — 從看到的文章、書籍或電影中摘錄節選的片段
• 「文摘」#Digest — 將看過的內容梳理後，得到的總結或思考
• 「碎嘴」#Hurhur — 比想法再更零碎一些，通常不成章只是零星中的零星片段
• 「新聞」#News — 日常、科技與開發領域的相關情報，也有可能是折扣優惠資訊
• 「知識」#TIL — 由 Today I Learned 縮寫而來，即當天學習到或是獲得的小知識
• 「想法」#Thought — 從日常生活瑣事衍生出的念頭
• 「影片」#Video — 影片片段
___
（早已經忘記當初是否因為日期特殊想要有些儀式感而創建了，如果是的話突然覺得當初的自己還是挺中二的。）
由於 Telegram 本身對於中文的搜尋能力很糟，所以張貼的內容會標記以下標籤作為分類依據：
• 「摘抄」#Excerpt — 從看到的文章、書籍或電影中摘錄節選的片段
• 「文摘」#Digest — 將看過的內容梳理後，得到的總結或思考
• 「碎嘴」#Hurhur — 比想法再更零碎一些，通常不成章只是零星中的零星片段
• 「新聞」#News — 日常、科技與開發領域的相關情報，也有可能是折扣優惠資訊
• 「知識」#TIL — 由 Today I Learned 縮寫而來，即當天學習到或是獲得的小知識
• 「想法」#Thought — 從日常生活瑣事衍生出的念頭
• 「影片」#Video — 影片片段
___
（早已經忘記當初是否因為日期特殊想要有些儀式感而創建了，如果是的話突然覺得當初的自己還是挺中二的。）
七夕這天下來臺中和朋友吃飯，返回臺中住處時叫了輛 Uber 乘坐。
開車的司機是位上了年紀的阿姨，在快要抵達目的地時，我請阿姨停靠在附近便利商店旁的轉角即可，這樣她就不用多轉一個彎進到巷子裡，畢竟要再繞出來還要多走一段路，而且那段路又小條而且在夜間又沒什麼燈光。
阿姨突然感嘆地說：「如果其他乘客都能像你一樣就好了」，原來是她之前在逢甲載客時，人潮跟車流擁擠的狀況下，乘客還要求她迴轉停靠在滿是機車的地方，即使面露難色表示為難了，對方一群人卻是回答她「其他人都可以，為什麼妳就不行？」
對呀！我也可以，為什麼其他人不行呢？覺得會替他人著想的自己有點小棒，誰能夠不喜歡被讚美呢？
#Thought
開車的司機是位上了年紀的阿姨，在快要抵達目的地時，我請阿姨停靠在附近便利商店旁的轉角即可，這樣她就不用多轉一個彎進到巷子裡，畢竟要再繞出來還要多走一段路，而且那段路又小條而且在夜間又沒什麼燈光。
阿姨突然感嘆地說：「如果其他乘客都能像你一樣就好了」，原來是她之前在逢甲載客時，人潮跟車流擁擠的狀況下，乘客還要求她迴轉停靠在滿是機車的地方，即使面露難色表示為難了，對方一群人卻是回答她「其他人都可以，為什麼妳就不行？」
對呀！我也可以，為什麼其他人不行呢？覺得會替他人著想的自己有點小棒，誰能夠不喜歡被讚美呢？
#Thought
❤1
發現 Telegram Channel 如果發送語音訊息，會顯示旋律的聲波圖形，而上傳錄製後的音訊檔案則不會有；原本以為語音訊息不能夠加註內容，但看起來是要上傳之後再自行編輯才會出現。
另外如果是上傳音訊檔案，編輯時可以替換掉原來的檔案，發送語音訊息的話不能夠替換。
#Hurhur
另外如果是上傳音訊檔案，編輯時可以替換掉原來的檔案，發送語音訊息的話不能夠替換。
#Hurhur
發現博客來網路書局有一個（每字，美句）—收藏、紀錄、分享你最愛的一句活動頁面，可以讓使用者提交那些在書中瞥見且觸動他們的句子；還不僅僅只是書籍，也有可能是 CD 專輯中的內容。
點了幾篇發現應該有些規律，可以撰寫簡單的腳本程式去抓取內容，比如網址部分是：
• 句子會被嵌入圖片中，但是可以從 "分享到 Line" 的這一個功能的連結抓取，因為句子內容會被附加到分享連結中
• 出處跟作者部分就簡單了一點，可以在
___
感覺伊哥會對這個有些興趣，剛剛點了 "最多人收藏" 看一下大家都分享些什麼，排名靠前的竟然有 Peter Su……
#Find
點了幾篇發現應該有些規律，可以撰寫簡單的腳本程式去抓取內容，比如網址部分是：
https://activity.books.com.tw/everylettermatters/sentence/single/<SENTENCE_ID>
• 句子編號 <SENTENCE_ID> 看起來是有序的• 句子會被嵌入圖片中，但是可以從 "分享到 Line" 的這一個功能的連結抓取，因為句子內容會被附加到分享連結中
• 出處跟作者部分就簡單了一點，可以在
<head></head> 裡面抓取 <meta> 標籤___
感覺伊哥會對這個有些興趣，剛剛點了 "最多人收藏" 看一下大家都分享些什麼，排名靠前的竟然有 Peter Su……
#Find
❤1
“Good vulnerability is fundamentally generous: it takes the first step at disclosure, so as to render it safe for others to unburden themselves and disclose something of hidden selves in turn. It is a gift in the form of a risk taken for someone else.”
—— The Importance of Vulnerability
透過揭露自我的脆弱，反而能夠建立更穩健的友誼與感情，可惜的是我們卻花費大量的時間和精力，奮力地隱藏自身的脆弱⋯⋯
#Excerpt
—— The Importance of Vulnerability
透過揭露自我的脆弱，反而能夠建立更穩健的友誼與感情，可惜的是我們卻花費大量的時間和精力，奮力地隱藏自身的脆弱⋯⋯
#Excerpt
週末清理信箱之際，順帶地看了 Tech and Tea 的兩篇文章 — “Ask vs guess culture” 和 “Bridging the ask vs guess culture gap at work”，簡單紀錄分享一下。
_____
• 作者是在 Metafilter 這個網路日誌平台上，知曉請求文化（Ask Culture）與猜測文化（Guess Culture）的概念，只是網路上提出的人際交往概念，並沒有嚴格的社會學定義
• 請求文化（Ask Culture）：想要什麼都可以要求，但必須意識到不一定能夠得到答案
• 猜測文化（Guess Culture）：除非很確定，否則避免表達請求，透過大量的上下文判斷請求是否合理
• 許多亞裔人士，都是受 Guess Culture 薰陶長大的，強化了社會間集體主義的關係，而將個人需求和願望留給自己
• 西方企業工作幾乎都是在 Ask Culture 下運作的，而在這些公司工作的 Guess Culture 人們可能會覺得被低估或忽視
• 現實情況是，我們需要與溝通方式迥異的人們一起生活與工作，所以需要找到填補之間差距的方式
• 最中庸的方式是「提供更多的上下文」以及「尋求幫助時分享期望」
• 主管對於 Guess Culture 的下屬，可以先從提供短期選擇而非詢問長期目標開始，練習彼此的溝通頻率，直到足夠了解才提供長期選擇
_____
• 作者是在 Metafilter 這個網路日誌平台上，知曉請求文化（Ask Culture）與猜測文化（Guess Culture）的概念，只是網路上提出的人際交往概念，並沒有嚴格的社會學定義
• 請求文化（Ask Culture）：想要什麼都可以要求，但必須意識到不一定能夠得到答案
• 猜測文化（Guess Culture）：除非很確定，否則避免表達請求，透過大量的上下文判斷請求是否合理
• 許多亞裔人士，都是受 Guess Culture 薰陶長大的，強化了社會間集體主義的關係，而將個人需求和願望留給自己
• 西方企業工作幾乎都是在 Ask Culture 下運作的，而在這些公司工作的 Guess Culture 人們可能會覺得被低估或忽視
• 現實情況是，我們需要與溝通方式迥異的人們一起生活與工作，所以需要找到填補之間差距的方式
• 最中庸的方式是「提供更多的上下文」以及「尋求幫助時分享期望」
• 主管對於 Guess Culture 的下屬，可以先從提供短期選擇而非詢問長期目標開始，練習彼此的溝通頻率，直到足夠了解才提供長期選擇
❤1
前幾年轉換跑道來寫程式的高中同學，經常會來問我一些技術上問題，最近因為想要跳槽所以正在準備面試時想要呈現的作品。
他給自己訂下了一個簡單的目標，想要在兩週內完成一個簡單的專案，卻沒想到進度比他預想的延後了許多。
之前其實就有觀察到這個現象，他經常會在平日的晚上還在焦頭爛額地去處理工作上遇到的困難，然後很抱歉地再與我約時間求助，後來閒聊了一下發現他與 PM 押定時程的方式很有問題，主要是：
• 由於轉職的緣故加上學歷不算太差，不想被人看扁想要好好表現，而給出了緊繃的時程，沒有將 research 與 debug 的時間算入
• 有些 PM 並不具備開發經驗，對於估算時程上面也沒有經驗，會想要儘可能地縮短開發時程來推進專案進度
___
後續與他分享了這幾年的一些小小個人心得，也順便寫在這裡，集思廣益一下：
[1] 對於之前實作過的功能，我的估算方式通常是 x2 倍時間
[2] 對於之前沒有ˊ實作過的功能，可以與 PM 討論是否先將「驗證可行」與「實作需求」分開，後者通常是習慣的保守時間 x4 倍
[3] 如果押出過長的時程，對方會再限縮，不用一開始就給出太短的時程，倘若對方就真的接受那麼長的時程呢？
[4] 提前完成有許多益處，比如得到信任與讚賞、有餘裕的時間讓自己做其他事或承攬下一個任務，更重要的是也能給予自己正面回饋
[5] 反之；時程押得太過緊湊，延宕不僅造成對方觀感不佳，自己也容易被逼得手忙腳亂，為了滿足期待而更多地壓迫非上班時間
賣的瓜不必保熟呀！
#Thought
他給自己訂下了一個簡單的目標，想要在兩週內完成一個簡單的專案，卻沒想到進度比他預想的延後了許多。
之前其實就有觀察到這個現象，他經常會在平日的晚上還在焦頭爛額地去處理工作上遇到的困難，然後很抱歉地再與我約時間求助，後來閒聊了一下發現他與 PM 押定時程的方式很有問題，主要是：
• 由於轉職的緣故加上學歷不算太差，不想被人看扁想要好好表現，而給出了緊繃的時程，沒有將 research 與 debug 的時間算入
• 有些 PM 並不具備開發經驗，對於估算時程上面也沒有經驗，會想要儘可能地縮短開發時程來推進專案進度
___
後續與他分享了這幾年的一些小小個人心得，也順便寫在這裡，集思廣益一下：
[1] 對於之前實作過的功能，我的估算方式通常是 x2 倍時間
[2] 對於之前沒有ˊ實作過的功能，可以與 PM 討論是否先將「驗證可行」與「實作需求」分開，後者通常是習慣的保守時間 x4 倍
[3] 如果押出過長的時程，對方會再限縮，不用一開始就給出太短的時程，倘若對方就真的接受那麼長的時程呢？
[4] 提前完成有許多益處，比如得到信任與讚賞、有餘裕的時間讓自己做其他事或承攬下一個任務，更重要的是也能給予自己正面回饋
[5] 反之；時程押得太過緊湊，延宕不僅造成對方觀感不佳，自己也容易被逼得手忙腳亂，為了滿足期待而更多地壓迫非上班時間
賣的瓜不必保熟呀！
#Thought
❤3