[好書分享] 40歲,精采人生才開始: 從1萬人的經驗談看見真正該做的事

40歲,精采人生才開始: 從1萬人的經驗談看見真正該做的事
できる40代は、「これ」しかやらない : 一万人の体験談から見えてきた「正しい頑張り方」

作者: 大塚壽  譯者: 沈俊傑  出版社:先覺出版 
出版日期:2021/05/01 
語言:繁體中文 ISBN: 9789861343815 

買書推薦網址:

前言:

這一本是今年所讀完的第七本書。 這一本當初在書店決定要翻閱它的時候,真的只是因為他的書名。(好像買書就會洩漏自己年紀一 樣),不過其實這一本書的內容相當的實用。相信許多上班族會希望他們在三十多歲就能夠知道的事情。當初一翻到這本書,就是談到裡面關於 work-life balance 相關的章節,想不到裡面有許多相當有用的建議與體認。身為業務人的作者更了解人到了四五十歲經常有的迷惘與困惑。

蠻推薦大家去看這一本書,就算你還沒 40 啦,哈哈!

內容簡介與心得:

你還好嗎?「40歲」後悔度調查
□ 每天都很忙碌,但並不討厭忙著工作的自己。
□ 工作還是實務至上,重點是親自動手。
□ 雖然知道事情要交辦出去,但到頭來還是忍不住自己攬下來。
□ 平日經常加班,但假日時間都拿來陪伴家人。
□ 雖然不排斥升官發財,但盡量不去想這些事情。
□ 最近的年輕人不喜歡別人過度干涉,所以盡可能跟對方保持距離。
□ 大學畢業至今還沒換過公司。
□ 現在完全沒時間留給興趣,覺得退休之後再培養就好。
勾選超過5項,可能就是「愈拚命努力,愈容易感到後悔」的飲恨者!
請立即改變想法吧!

章節條列

chapter 1 〔生涯篇〕四十歲是決定「下半生怎麼活」的最後機會

40 歲經常伴隨而來的就是資深與經驗,一家公司也往往工作了十多年了。 這個時候作者提供了一個表格,可以讓讀者們去思考是否公司有相關危機的「自我現況分析表」。 裡面大約有了以下幾個項目:

  • 公司所在業界優勢
  • 公司自評:公司在業界的評比。
  • 部門所在公司比例中的評比。
  • 直屬上司的評比。
  • 自己目前擁有技能的評比。

這些評比可以幫助讀者對於目前的現況有一個概略性的了解,如果真的所在的狀況不太樂觀的話。也應該趁四十多歲的狀況,儘早作出相關的改變,一切都還來得急喔。

裡面也提到了,建議每一個人透過透過「金錢」來幫自己目前的現況評價,作為一個相對於客觀的狀況分析。 同時也希望透過現況分析,讓讀者更能夠了解,哪一些技能是應該要開始培養的,並且作者也建議應該要培養個人品牌與可以賺錢的副業(這邊指的可以賺錢,大概是要有月收入 7000 日幣)。

chapter 2 〔公司篇〕身處「暗潮洶湧的組織」需培養出高超的泳技

第二章提到的就是 40 歲了之後,對於工作也應該有了一定的想法。這邊也有一些蠻值得思考的話語:

  • 提早思考是否要升官,透過時間分配對自己的工作生活負責。
  • 培養組織相關技能,捨繼個人技能。這邊指的是充實個人人脈,努力跟人合作。
  • 與其討好上司,不如跟下屬打好交道。

其中跟下屬打好交道這個思維算是蠻有趣的。因為 40 歲大多都是小主管,透過跟下屬打好關係,才能夠讓組織的績效夠好,才能夠被上司真正的賞識。反之,如果一昧的討好上司。卻不斷的壓榨下屬,到時候下屬擺爛自己的成就還是無法被看見。

chapter 3 〔管理篇〕掌握「正確的交代方式」,自己和團隊才動得起來

這邊分享的是身為管理階層,在 40 歲的時候應該要具有的能力:

  • 掌握「交辦大原則」: 學習如何有效地交辦事項。
  • 不要經常抱怨,卻不去解決問題。
  • 要懂的如何請求比自己年長的下屬
  • 刻意安排「管理時間」:這邊許多的書籍也有提到,必須要安排 1 on 1 的時間
  • 夾心餅乾的人才是自我價值的呈現: 避免 Garbage in Garbage Out

這邊很重要的就是要認清自己在管理上的價值,也必須要讓自己更相信團隊。更信任下屬才是。

chapter 4 〔私人篇〕暫時拋開工作,完全投入「個人生活」

這一本書的作者是日本人,在日本裡面 40 歲就是標準的「燃燒生命為公司付出的年紀」。但是作者要求每一位讀者應該要提早去思考,要如何「增加個人的生活」。

  • 沒有少了你會不行的公司,只有你少了公司會沒有生活目標的人生。
  • 需要儘早培養「自己理想生活的人生」,不然退休後往往會喪失生活目標。
  • 需要更早的注重家庭生活,因為四十歲往往就是容易跟家人,跟小孩喪失聯繫的一個十年。也是很容易造成中年離婚的原因。
  • 週末時間試著要拆開成六等分,除了要有自已的時間外。一定要保留時間給家人跟朋友。
  • 一定要將自己的時間適當的分給小孩,吃一頓飯是很重要的。(現在都 WFH 每天我都跟小孩吃飯 ~笑)
  • 眼裡只有工作的人,真的是相當的可憐。並且工作外,自己有無相關的興趣?
  • 最後一個項目就是要健身,一定要透過肉體「實際的對抗老化」。

最後作者也分享了一個案例,透過自己對於生活的要求。對於音響的喜愛後來變成自己退休後的副業,生活也相當的愉快。

chapter 5 〔時間管理篇〕工作效率好的人都會「這麼做」

四十多歲的人,大多已經在自己的工作步調上工作了十多年(可能會更久)。這時候許多的人沒有去好好地審視自己的工作效率,這邊提供一些讓讀者可以好好檢查自己的方法。

  • 不要試著什麼事都掌握,只做重要的事情。(沒有人能取代的事
  • 將自己十分鐘抽出來,做一些平常不常做的工作。搞不好能發現某些能增加工作效率的方式。
  • 追求專心做事的時間(番茄時鐘?)(連續工作時間)
  • 遵守時間表,如果沒辦法做完,試著放到一半(不要做一個段落)。很多書上有這樣教,這樣一來往往能讓你心中掛念,然後之後會想出更好的做法。
  • 「重要但是不緊急的事」往往要更認真的思考,更認真的做。避免變成「重要又緊急」。

試著將以往不在意的事情去做,往往會給你更多的體現。

chapter 6 〔人脈篇〕四十歲後,「往來對象」會決定人生成敗

對於一般人來說,人脈最高峰就是在學生時期。 20 ~ 30 多的時間,因為換學校,換工作會認識很多人。但是到了四十歲之後,往往就會越來越懶得跟人聯絡,這個時候的人脈往往更佳的珍貴。

  • 透過聚會方式,多多認識不同的人。 (不喜歡喝酒,可以讀書會。
  • 另外一本書也有提過,大概十多個人的聚會,讓彼此認識的人脈。往往可以讓彼此達到最高的效益,往往生意就是這樣來。
  • 虛心向任何人請教,並且也要認識非同溫層的人。
世界上有兩個東西不會出現,一個是幽靈,一個是下次。

你永遠不知道是下次先來,還是死亡先來。到了四十歲後,往往會開始有朋友離開所造成的遺憾,千萬不要讓自己有類似的遺憾。

透過週期性聚會,可以約來業務相關的人,也可以把之前的窗口一起找來。人數大概是十個為上限,這樣一來可以讓彼此都熟識,也可以擴展彼此的人脈。許多的書籍與課程都有提到相關的事情,也都認為這個方式所形成的人脈是有用且有效的。
  • 個人好店與私房景點是相當重要的:這個是我現在比較沒有思考的,雖然說是因為作者是業務。但是我認為就算是工程背景也應該要能夠有私房好店。

chapter 7 〔學習篇〕在有限時間內,獲取最大成果的「大人學習法」

這是一本相當新的書(2020 年底出的),所以這一個章節討論的就是「疫情狀況下,需要有的新能力」。

  • 遠距辦公的溝通能力:有效的溝通與交辦事項能力,有效地掌握遠距會議。
  • 書寫能力很重要,往往會書寫的人「獨立思考的能力也很強」。
  • 集中學習可以變現的能力,要多多學習相關可以賺錢的能力。如果要有證照,應該在於證照所帶來的學習能力而非證照本身。
  • 閱讀新的書籍與幾本經典書籍可以讓知識學習起來更有效率。
  • 培養「說得出來的素養」,透過上知天文天文下知地理的常識,可以讓溝通更有趣。也可以讓自己的人脈更好,並且讓自己的價值更高。

心得:

這一本書雖然是日本作者寫的,但是放到台灣其實很適合給三十五歲以上的人來看。也希望每一個讀到這一篇的讀者,可以去看看這本書,培養自己的能力之外,也培養出許多屬於自己的人脈。

[學習心得] LINE Bot 開發者指南 詳解 - 3. 發送 API 請求時的注意事項

前言:

各位好, 我是 LINE Taiwan 資深開發技術推廣工程師 – Evan Lin。 今天這篇文章為各位詳細解釋 「 LINE Bot 開發指南」這一份投影片文件。這一份文件是來自於 Development guidelines 的投影片,考量到在台灣還沒有正式的公布與中文化。這一次跟總部共同合作準備中文版本之外,並且特定用這一系列文章加以解釋,希望可以讓更多開發者有更多的了解。 Development guidelines 文件內容很多,本份投影片也將以五篇文章的篇幅來加以解釋。本篇文章為第三篇文章,主要講解的會是關於發送 API 請求的時候需要注意的事項。

文章索引:

完整投影片鏈結: https://speakerdeck.com/line_developers_tw2/line-bot-developer-guideline-chinese

希望各位可以持續關注:

  1. 關於LINE Bot
  2. 使用Webhook URL接收請求時的注意事項
  3. 發送 API 請求時的注意事項(本篇文章)
  4. LINE Login
  5. 其他相關功能

本篇文章將專注在第一個段落,也就是 Page 20 ~ Page 30 的部分。

發送 API 請求時的注意事項

本篇注意事項中,將會帶出以下的相關項目。

  • A. Channel Access Token 的發行

  • B. Channel Access Token 自動更新
  • C. Channel Access Token 有效上限數量
  • D. 訊息發送完成後接收回應
  • E. API 請求重試
  • F. 請求的相關限制
  • G. 回應 ( reply ) 訊息與推播( push )訊息
  • H. HTTPS 內容的使用

以下開始將會逐一針對每一個頁面詳細解釋:

A. Channel Access Token 的發行

Channel Access Token 是整個 Channel 最重要的憑證,透過該憑證可以有許多權限可以修改該 LINE Bot 的設定。所以在授權上要務必小心。 這邊也提供一些小訣竅:

  • 建議不要使用沒有時效性的 Channel Access Token ,建議使用 API 來要求。
  • 使用 API 來申請 Channel Access Token 建議使用 v2.1 的方式來發出需求。

如此一來除了可以確保整個頻道(channel) 憑證的安全性,必要時也可以將有暴露考量的 token 撤銷掉。

參考文章:

B. Channel Access Token 自動更新

接續前一頁,針對 Channel Access Token 的管理上。建議使用短期有效的 Channel Access Token ,並且在期限即將到期的時候, Issue 新的 Token。 請注意 Access Token 個數有上限(下一頁解釋),所以超過個數時需要將多的撤銷 (Revoke) 掉。

C. Channel Access Token 有效上限數量

這一篇有詳細敘述關於 Channel Access Token 的個數:

  • Short-lived channel access token (短期) :
    • 申請方式: 透過 API ,參考說明文件
    • 個數: 30 個
    • 期限: 30 天
  • Long-lived channel access token (長期):
    • 申請方式: LINE Developer Console
    • 個數: 1 個
    • 期限: 直到重新申請為止。

相關文件:

D. 訊息發送完成後接收回應

這一頁投影片是敘述,如果開發者使用 Send push message 或是 Send reply message 的系統伺服器的回應狀況。通常成功的話,就不會回覆任何資訊(empty json ) ,如果有誤才會回覆詳細的錯誤資訊。

相關文件:

E. API 請求重試

有些時候發送大量的 API 呼叫的時候,因為有一些不可預期的狀況,造成 API 呼叫無法成功,或是無法收到回應的狀況。這時候為了能夠確認前一次的呼叫是否有成功,平台這邊有設計相關的重試 (Retry) 機制可以檢查。

透過 “Safely retrying” 機制。 可以讓開發者測試一下上次的訊息是否有正確的發送成功,並且也可以確保有無任何的使用者被漏發了。 相關的使用情境如下:

  • 上次不知道有無法送完成,呼叫 “Safely retrying” 可以重複發送同一則訊息。 有收過得不會收到重複訊息,沒收到的可以確保收到。
  • 上次發送發生了平台無法完成指令的意外,透過 “Safely retrying” 可以跟平台確認上次的狀況。 如果上次有完整發送完畢,也不會有重複計費的疑慮。

相關文件

F. 請求的相關限制

開發者在使用 API 的時候應該要避免大量的呼叫 API 超過設定的 Rate Limit 而造成系統判斷為惡意的呼叫。 其中 Rate Limits 可以參考以下相關訊息:

如果超過了這些次數的限制,則會獲得 420 Too Many Requests 的回應。請開發者們一定要注意。

相關文章:

G. 回應 ( reply ) 訊息與推播( push )訊息

這邊則是詳細敘述關於 Reply Message 跟 Push Message 的差別:

  • Reply Token 有時效性。更多資訊可以參考 「開發LINE聊天機器人不可不知的十件事」 裡面的相關註解。
  • LINE Messaging API的Webhook的下列事件物件會帶有Reply token:message、follow、join、postback與beacon。使用Reply token傳送訊息請注意以下二點:
    • Reply token的有效期間非常短,在收到Webhook事件後必須盡快使用。有效期間會隨著系統狀況而調整,所以我們也不便對外提供精確的數字。可以確定的是這個數字會以秒為單位,開發者是無法以Reply token回覆需要經過數分鐘以上處理時間才能獲得結果的訊息。這個目的是希望開發者能夠在最短的時間內回覆用戶的訊息,提供更好的使用者體驗。
    • Reply token僅可以使用一次,如果有需要在收到Webhook事件後分多次回覆,就必須使用Push message的方式來傳送訊息。

相關文件:

H. HTTPS 內容的使用

如果在訊息內需要加上圖片,影片,音訊等等相關資料。記得除了需要符合 HTTPS 的安全規範外,還需要符合 TLS 1.2 以上的安全規範,不然將無法正確顯示。 將不在支援 TLS 1.0 與 1.1 (參考 Updated: TLS 1.0 and TLS 1.1 support by the webhook notification source will be discontinued at the end of January 2021)

相關文件:

結論:

以上就是「LINE Bot 開發指南」第三部分的補充與分享,想要知道更多內容可以查看完整投影片,或是找到其他篇的文章來了解。

想了解更多開發者的活動? 立即加入「LINE 開發者官方社群」官方帳號,就能收到第一手 Meetup 活動,或與開發者計畫有關的最新消息的推播通知。▼

「LINE 開發者官方社群」官方帳號 ID:@line_tw_dev img

[好書分享] 岩田聰如是說:從天才程式設計師到遊戲公司社長,任天堂中興之主傳奇的一生

岩田聰如是說:從天才程式設計師到遊戲公司社長,任天堂中興之主傳奇的一生。

作者: ほぼ日刊イトイ新聞  出版社:台灣東販 
語言:繁體中文 ISBN: 9789865119263 eISBN: 9786263046443 字數: 51,266

買書推薦網址:

前言:

這一本是今年所讀完的第七本書。42 歲接下任天堂社長,領導著任天堂打造出 NDS, Wii 顛覆遊戲界的岩田聰社長,但是卻英年早逝。這本書不是要分享他成就或是相關豐功偉業,而是分享他在日常生活跟同事們的聊天的想法,也讓大家知道他是始終如一的人。

有點像是末代武士裡面的橋段:

Emperor Meiji: “Tell me how he died.” Algren: “I will tell you how he lived.”

相當推薦大家來看這本,短短的一本書但是會讓你再三回味的。

內容簡介與心得:

約莫二十年前,山內溥安排岩田聰進入任天堂本社,擔任經營企畫室長,並且在兩年後自己退休時指定岩田先生接下任天堂社長職位。當時任天堂可說是正值風雨飄搖之際,儘管財務情況一直很健全,但N64和NGC兩台家用主機接連失利,市占率甚至被夾帶雄厚資金進入市場的新挑戰者,也就是微軟推出的 Xbox 主機所追趕。
 
當年年僅四十二歲的岩田先生,接下此一重責大任後便不負所托,打出「擴大玩家人口」的大旗,先後推出掌上型主機「Nintendo DS」以及家用主機「Wii」,以和過去主機不同的異質變化,吸引玩家、曾經是玩家和不是玩家的人,成功帶領任天堂走出低潮,並且創下公司成立以來最高營收。可說是名符其實的「任天堂中興之主」。

 
本書是從《HOBO日刊ITOI新聞(ほぼ日刊イトイ新聞)》網站所刊登的岩田聰訪談中,擷取岩田先生說過的話,重新編纂而成。另有部分言論節錄自任天堂網站上的「社長提問」專欄。
 
岩田先生是一位在媒體面前談話時,幾乎從不把自己當作話題主角的人。若是為了公司和專案,基於「由我出面是最合理的判斷的話」,他會回應遞到眼前的麥克風,可是言談之中僅將自己的事擺在次要。
 
不過,就如多數人所知道的,岩田先生是一位誠實無偽、一路走來始終如一的人。
 
他曾經代表公司或開發商立場,於各種場合發表言論,將這些言論集結一看,就彷彿多個圓圈的交會處,疊合出另一種顏色般,自然而然地浮現出「岩田先生本人的話」。

章節條列

第一章 岩田先生成為社長以前。

這一章節內容來自於岩田先生的採訪內容,可以感受得到岩田先生對於遊戲製作與工作有著無比的熱情。並且也在 HAL 研究所任職時間,因為遭遇了公司的 15 億日圓債務影響,當時才 33 歲的岩田先生,也在當時培養經營公司的能力。 這邊快速歸納一些我覺得很難得的特質:

  • 儘量抽出時間跟全公司的人 1 on 1
    • 因為走馬上任,透過跟全公司的人面談了解大家的想法與公司的問題。更了解該怎麼做,這習慣也儘量延續下去。
  • 抱持著幫大家解決問題的想法來傾聽(不表達意見)
  • 經常問人:「你覺得快樂嘛?」「你覺得這個有趣嘛?」讓遊戲回歸本質。
  • 遇見各種客戶的問題,絕對不逃避。並且主動起來面對客戶,面對問題。「逃避的話,我會後悔一輩子」的想法來面對事情。

第二章 岩田先生的領導能力。

這邊有一些岩田先生的領導力的表現,相當適合想轉職管理階層的人或是轉換到專案管理階層的人來看。

  • 找到瓶頸所在:不要一頭鑽進問題,看清楚問題的面貌相當的重要。
  • 只有自己才能解決: 要挑對的的問題來面對,讓團隊的其他人替你解決其他問題。
  • 任天堂的最終極目標就是「給人驚喜的感覺」
  • 專案進行最順利的狀況是:「當發生了不在原本沒預期的事情,但是有人主動願意主動跳出來願意接手處理,解決問題。」
  • 讓團隊中的每個人,對於產品有著共同的願景。才能有共同的想法一起努力。
  • 對每個同仁都抱持著敬意,每一個同仁一定有自己最專長的所在才會被錄用。 要能夠善用不同的人。
  • 「絕對不要有如果有三個自己,那該有多好的愚蠢想法」。

關於面試,這邊也有許多很有見地的想法:

  • 不要問面試者難以回答的問題,反而要問面試者可以侃侃而談的問題。透過大量的對談,來了解對方是不是能來幫助你的人。
  • 要挑選可以放心責怪「笨那!」的後選者,那樣的人才能有膽是能面對困難的情境。並且能夠輕鬆的討論彼此缺點的人,往往在合作上更不會有綁手綁腳的害怕感。 想做就去做,想質疑就要質疑。

此外,我也覺得岩田聰先生本身也相當有傳教士的精神。他很喜歡鼓勵每一個同事,主動去發掘每一個同仁特色的一面。

「一個人聽懂一件事情,跟他能不能夠把這件事情講給其他人聽,是完全不同的兩件事」。(這句名言,我覺得超棒)

第三章 岩田先生的個性。

這一個章節列出許多岩田聰先生相當可貴的個性:

  • 是個打破砂鍋問到底,熱愛學習的人:
    • 了解道理是一件事,要能讓對方心平氣和接受又是另外一門學問。
  • 發現反饋的能力:
    • 如同遊戲一樣,給予同仁反饋與建議,讓每一個同仁不斷的進步。
  • 寫程式經驗拿來經營公司:
    • 就像發現 bug 一樣,一開始都不會認為是自己問題。需要詳細的思考對方的問題與自己的問題,再來思考是不是有一個良好的方式可以彼此有更良性的溝通。
  • 只要是合理的事,要提早下定決心(貫徹到底):
    • 這邊是指岩田聰先生出來代表任天的發表遊戲的事情,為此他努力學習英文,認真表達出公司的面向與遊戲本質。
  • 「程式設計師不可以說 No」
    • 這邊指的是,程式設計師不要一開始就自我設限,讓許多的好想法或是(比較難開發)的想法被扼殺在一半。
  • 透過「當事人不會後悔」的方式來排定事情先後順序
    • 這樣一來不僅不會浪費時間,更可以讓每一個人(事)(物)都被妥善的對待。

名品小句子:

「客人在吃餐點的時候,很多時候說太多了,可能是因為不好吃。 不是因為吃不下,這時候老闆可能單純的給予比較少的食物,並不會真正的解決問題。」

第四章 岩田先生信賴的人。

這一個章節主要分享著岩田聰先生所信賴的人們的事情。

  • 宮本茂先生經常可以透過一個想法來解決複數個問題。

  • 宮本茂經常會抓著公司內同事,請他來試玩他的遊戲,藉以獲得回饋。(也可能是宮本茂先生喜歡面對玩家純真的一面)

  • 對於電腦本質了解透徹的宮本茂先生,這邊是指宮本茂先生的底子深刻。

  • 解決遊戲的兩個做法,一個是重做,一個是小改。系井先生為了好玩會堅持把遊戲打掉重做。

  • 宮本茂先生經常會砍掉重做,但是可能是遊戲引擎跟玩法改掉,但是可以重複利用的部分還是會儘量思考如何利用。

  • 前社長山內博的教誨:「不要一直走老路,要勇敢走新的道路」。

  • 所謂的天才可能是「把其他人討厭而無法做完的事情,持之以恆地做完」

第五章 岩田先生所追求的遊戲。

這邊開始介紹岩田聰先生打造主機跟遊戲的一些想法:

  • 打造心目中的遊戲主機:希望可以打造出回到家馬上會想要打開的電玩遊戲主機。
  • 打造出遊玩架構:有一個時期,任天堂的主要目的是打開遊戲族群的人口,所以他們會將由玩遊戲的方式從手把到遙控器。透過體感的方式來吸引更多的遊戲人口。這也是Wii 的誕生原因。
  • 透過突發奇想的討論,或許不是浪費時間: 曾經有段時間岩田聰先生希望可以讓小孩子遊戲時間不要太長,但是這樣得想法明顯的跟公司的收益相違背,透過不斷的討論,誕生了遊戲中的遊玩時數系統。也可以讓家長跟小孩能夠溝通,彼此約束。
  • 沿著過期成功的路,是最恐怖的:有一個時期,任天堂不斷的創造出新的主機系統。從 NDS 到 3DS 到 Wii ,他們認為走著過去成功的路,往往才是最容易失敗的。
  • 任天堂大亂鬥是慢慢生長出來的遊戲: 一開始只是希望能做出任何人都能上手的格鬥遊戲,後來隨著許多角色的加入,並且有更多的想法加入,才能變等現在有趣的模樣。
  • 壞莉歐的誕生是為了顛覆任天堂:壞莉歐一開始誕生的想法是要做瑪莉歐本來做不到的事情:壞事,小遊戲,或是一些其他的遊戲類型。這種「旁系」的遊戲類型,反而引吸到另外一群遊戲族群呢!
  • 輕度玩家與重度玩家:大部分時候,任天堂會以吸引更多玩家加入的方式來讓輕度玩家來加入。但是也會有給重度玩家的遊戲類型。

名品小句子:

為什麼這塊小石頭要放這裡? 如果設計者講「不為什麼」,這是相當危險而且要不得的。
一開始做遊戲會想加入所有元素,但是後要完成的時候往往是在慢慢的減法中妥協與完成。約束是創造之母阿!

第六章 別人眼中的岩田先生

這邊有列出許多任天堂內部神級人物眼終的岩田聰先生,透過這個方式也呼應到前面許多形容岩田聰先生的特性。

  • 宮本茂先生眼中的岩田聰先生:
    • 不像是上司,反而像是朋友。
    • 喜歡透過命名方式來凝聚共識。比如說產品命名,或是遊戲使用共同名稱。 (Wii Sport, Wii Fit …)
  • 系井先生眼中的岩田聰先生:
    • 讓人覺得信賴,但是不敢懈怠的同事。

第七章 岩田先生這個人。

最後則是透過許多短句子,來幫岩田聰先生結尾。

「跟別人共事的時候,一定要讓人覺得下次一定要繼續跟我一起做事的想法」
名片上我是社長
腦海中我是遊戲開發者
在心中,我是一名遊戲玩家

心得:

可能是因為是日本人寫的書,連寫章節摘要的時候,都會打上許多的「先生」這樣的詞(笑)。 這一本書並不算長,算是透過採訪搜集文章的一種。還有加入許多人的側面採訪的方式來了解這個令人敬佩的人。雖然岩田聰先生相當年輕就當上社長,但是相當的謙虛與願意解決許多問題的態度,是相當令人相賞的。這不是一本很厚的書,但是我應該會經常不斷的拿回來翻著看,因為有許多簡短的文字,卻是如此的精簡而有力,讓我會不斷的思考。

[資源分享] 關於線上書籍的相關免費資源(圖書館免費線上資源)

有在看我部落個的朋友,知道我經常在閱讀書籍(因為實體書太佔空間,目前以電子書為主),並且貼在「書海漫遊」項目中。 之前才聽到同事分享資訊,原來有更多免費資源可以使用,相關使用方式如下:

免費正版電子書? 來跟圖書館借吧

其實有圖書館都有免費的電子書可以借,各位可以來相關網站去借。 而且那些圖書館又可以線上辦證,不必一定要是該縣市居民,等於只要在家辦辦帳號,就可以享有這些免費資源。這些圖書館包括了 國立臺灣圖書館 / 台北市立圖書館 / 新北市立圖書館 / 台中市立圖書館 等等。裡面其實有更種書籍,但是個人推薦可以借電子雜誌,因為台北好讀的 App 目前只支援 iPad /iPhone /Mobile 還有客製化的閱讀器,必較建議使用 iPad 來看雜誌的版面。 詳細網站可以去 台北市立圖書館 x 台北好讀

優點:

  • 如果有台北市立圖書館,可以一個月可以免費借幾本。
  • 蠻推薦雜誌,因為可以用 iPad 來看。版面比較固定。(反正其他平台也都是 PDF ,還要錢)

要去哪個圖書館找電子書?線上來找找

可以再搭配這個圖書館書籍搜尋網站使用:

台灣圖書館電子書搜尋

想買的書哪裡找的到電子書?

電子書是要用買的話,可以在這個網站一次找大部分的書城: https://taiwan-ebook-lover.github.io/

台北市立圖書館疫情加碼

愛看書的市民朋友,考完會考需要放鬆腦袋的青年才俊,活到老學到的樂齡讀者,還有喜歡繪本讀圖像書的大小朋友,現在就登入您的帳號密碼,盡情悠遊書中世界吧!

提醒您,閱讀量力而為,不要一口氣借太多讀不完,反而浪費點數喔!讓我們學會分享,用愛閱讀吧!

傳送門:

https://tpml.ebook.hyread.com.tw/index.jsp

除了Ebook Taipei,本館還有很多電子書資源,請點以下連結,都去看看吧:

https://reurl.cc/g8985N

首次操作看這邊,跟著做一點都不難:

https://www.facebook.com/154691774541075/videos/1401090570099383

圖書館也能借免費線上影片

這邊順便整理一下,要借線上免費影片,也可以在圖書館借。(圖書館真棒!!)

公共圖書館區域資源中心電影院 – 免費提供數百部電影、紀錄片等讓你線上看

參考文章

[學習心得] LINE Bot 開發者指南 詳解 - 2. 使用 Webhook URL 接收請求時的注意事項

前言:

各位好, 我是 LINE Taiwan 資深開發技術推廣工程師 – Evan Lin。 今天這篇文章為各位詳細解釋 「 LINE Bot 開發指南」這一份投影片文件。這一份文件是來自於 Development guidelines 的投影片,考量到在台灣還沒有正式的公布與中文化。這一次跟總部共同合作準備中文版本之外,並且特定用這一系列文章加以解釋,希望可以讓更多開發者有更多的了解。 Development guidelines 文件內容很多,本份投影片也將以五篇文章的篇幅來加以解釋。本篇文章為第二篇文章,主要講解的會是關於設定 LINE Bot Webhook 相關注意事項。

文章索引:

完整投影片鏈結: https://speakerdeck.com/line_developers_tw2/line-bot-developer-guideline-chinese

希望各位可以持續關注:

  1. 關於LINE Bot
  2. 使用Webhook URL接收請求時的注意事項(本篇文章)
  3. 發送 API 請求時的注意事項
  4. LINE Login
  5. 其他相關功能

本篇文章將專注在第一個段落,也就是 Page 3 ~ Page 8 的部分。

Webhook URL 接受請求時的注意事項

本篇注意事項中,其實在「開發LINE聊天機器人不可不知的十件事」。有許多著墨,這裡稍微帶到與解釋。以下個別根據不同頁面來解釋。

  • A 考量安全性的通訊環境
  • B 接受到請求的時候,回覆狀態代碼 200
  • C 防止來自於 LINE 以外未經授權的請求
  • D 對於大規模訊息處理的考量

A 考量安全性的通訊環境

這部分提醒大家需要提升 Webhook 伺服器的安全環境,這邊也提醒大家根據 2021/01 的新聞 ([Updated] TLS 1.0 and TLS 1.1 support by the webhook notification source will be discontinued at the end of January 2021),如果要能正常地接受到 LINE 平台的 Webhook 必須要讓伺服器支援到 TLS 1.3 。

更多訊息歡迎參考以下文章:

B 接受到請求的時候,回覆狀態代碼 200

在 「開發LINE聊天機器人不可不知的十件事」的文章的(第三件事:盡快回覆LINE平台正確的HTTP狀態碼). 中,也有提到 LINE平台在傳送事件訊息到開發者Webhook伺服器之後,若是等待1秒鐘沒有得到任何HTTP狀態碼的回覆,就會發生逾時(Timeout)錯誤,LINE平台會關閉該次HTTP連線並認為該次傳送結果失敗;若是一直發生傳送失敗的狀況,LINE平台可能會將該Webhook伺服器封鎖或進行其他處置,造成開發者的應用服務無法正常運作。 請開發者們要注意到相關的事項。

更多訊息歡迎參考以下文章:

C 防止來自於 LINE 以外未經授權的請求

在 「開發LINE聊天機器人不可不知的十件事」的文章中(第二件事:驗證訊息來源)也有提到,當開發者的Webhook伺服器收到以POST方式所傳送的LINE事件訊息時,必須要立即驗證該事件訊息是否真的來自LINE平台,以避免被偽造的訊息所欺騙造成資訊安全危機。標準的驗證方式是檢查所收到HTTP請求標頭(HTTP request header)中的數位簽章。如果該HTTP POST訊息是來自LINE平台,在HTTP請求標頭中一定會包括X-Line-Signature項目,該項目的內容值是即為數位簽章。

更多訊息歡迎參考以下文章:

D 對於大規模訊息處理的考量

這邊有分享一些給開發者的經驗分享,根據業務的發展狀況下,以下幾個時間將會有大量的訊息灌入開發者們的 LINE Bot ,希望開發者們可能要注意到。 (訊息集中的部分)

針對這些大量的訊息可能湧入下,建議開發者們必須要有相關的備案需求。避免因為訊息過多而造成開發者的伺服器不堪負荷。 建議如下:

  • 是否有水平擴張的機制來面對大量的需求。 (Auto-scaling)
  • 建議檢查每一次訊息來之後的回覆時間,儘量採取非同步方式。盡可能先回覆之後,在另外發訊息給使用者。如此一來可以避免卡住太多訊息。

此外,本頁投影片也告知幾個重要消息:

  • 請勿對 GW 伺服器進行壓力測試,如果開發流程需要做壓力測試請透過其他方式來進行。 參考 Development guidelines

E-1 Webhook 的 ON/OFF

這邊提到的是切換 Webhook 開關跟「自動回覆訊息」還有「加入好友的歡迎訊息」的解釋。 這邊主要提醒開發者們,如果忘記將「自動回覆訊息」關閉的話,即便你開起來 Webhook 的開關,雖然可以收到,還是會透過「自動回覆訊息」來回覆。 相關的細節在下一頁會有更多解釋:

相關資料:

E-2 Webhook 的 ON/OFF 選項設定(跟「自動回覆訊息」還有「自動歡迎訊息」的互動)

  • 使用「Webhook],使用自動回覆與加入好友歡迎訊息:

    • 訊息來了,同時會送到 Webhook 與自動回覆。
    • 但是因為自動回覆會先回覆,Webhook 不需要再回覆即可。
  • 使用「Webhook],不使用自動回覆與加入好友歡迎訊息:

    • 建議開發者使用這個方式,完全透過 Webhook 來收取訊息與發送訊息。
  • 不使用「Webhook],使用自動回覆與加入好友歡迎訊息:

    • 這樣 Webhook 將不會收到訊息,完全透過自動回覆來回覆。
  • 不使用「Webhook],不使用自動回覆與加入好友歡迎訊息:

    • 如同投影片介紹,目前不開放也不建議開發者這樣設定。

F 其他注意事項

F-1. 一個請求包含多格訊息格式

在 「開發LINE聊天機器人不可不知的十件事」的文章中(第四件事:LINE平台所傳送的事件是一個陣列) 有更多清楚解釋,歡迎大家去了解一下。 因為 Messaging API 帳號沒有大量的事件訊息傳入,每次所收到事件幾乎都只有一筆資料,所以開發者會誤以為每個事件訊息只需要處理一筆資料。事實上,LINE平台傳送給Webhook伺服器的HTTP請求本體是包括一個或多個Webhook事件物件的JSON格式物件

F-2. Webhook 新增屬性的對應方式

這邊有建議開發者們,對於屬性的判斷上儘量要當成獨立個體之外,對於可能的新增屬性建議也要有比較好的處理方式。 建議方式可以透過 switch case 的方式來判斷,僅僅對於有處理的事件(event) 來處理,其他都略過。

相關文件:

F-3. 關於請求標題中的驗證

在 「開發LINE聊天機器人不可不知的十件事」的文章中(第二件事:驗證訊息來源) 有更多清楚解釋。文章中建議驗證方式如下:

  1. 以Channel secret作為密鑰(Secret key),使用HMAC-SHA256演算法取得HTTP請求本體(HTTP request body)的文摘值(Digest value)。
  2. 將上述文摘值以Base64編碼,比對編碼後的內容與X-Line-Signature項目內容值是否相同;若是相同,表示該事件訊息是來自LINE平台,否則拒絕處理該事件訊息。

相關文件:

G 建議的請求處理步驟

在 「開發LINE聊天機器人不可不知的十件事」的文章中(第三件事:盡快回覆LINE平台正確的HTTP狀態碼) ,在此僅列出相關流程圖,更多內容歡迎各位去部落格查看。

H. GW 伺服器 -> BOT 伺服器的通訊錯誤

H-1. 關於 Error Notification

這部分可以參考以下的流程圖:

這邊是敘述說如果 LINE 平台有問題發生的時候(或是無法正確收到開發者的回覆時),將會另行發信給開發者的信箱中。相關的信件內中如文件上。

參考以下文章:

結論:

以上就是「LINE Bot 開發指南」第二部分的補充與分享,想要知道更多內容可以查看完整投影片,或是找到其他篇的文章來了解。

想了解更多開發者的活動? 立即加入「LINE 開發者官方社群」官方帳號,就能收到第一手 Meetup 活動,或與開發者計畫有關的最新消息的推播通知。▼

「LINE 開發者官方社群」官方帳號 ID:@line_tw_dev img

[TIL][Golang] 使用 GoReleaser 一次打包多個與多種執行檔

前言:

在二月份文章有提到 使用 GoReleaser 打包你用 Golang 寫的 CLI (Command Line Tool),並且搭配 Github Actions 準備 Changelogs ,透過 GoReleaser 可以跟 Github Action 整合之外,還可以幫你撰寫 Changelogs 讓版本管控上變得更加的簡單與方便。

但是隨著服務與產品的應用變廣,會有更多的客製化需求發生。那麼該如何讓你的 Github Action 能夠有更多樣的自訂設定呢?

基本需求: GoReleaser with Github Action

大家可以參考前一篇文章,也可以快速學習本篇。

把這個建立成檔案在 .github/workflows/release_build.yml 就可以了。 這個其實比較適合 main.go 直接放在 github repo 下的,可以參考 https://github.com/kkdai/go-cli-template 的專案形式。

main.go 在子目錄 (sub-folder) Main program in sub-folder

通常在開發一些套件的時候,有時候我們主要 Repository 會是相關的開發套件 (Package) 而會將 CLI 的部分放在 cmd/xxx_cli 的資料夾中。需要安裝的時候再跑 go install xxx.com/xxx/uuu/cmd/xxx_cli 來安裝。

如果這時候你的 main.go 並不在 repo 的主目錄下,而是在 cmd/test_cli 的目錄下。 這個時候你就會發生錯誤。

goreleaser error: dones not contain a main function

這時候要如何修改呢?

依照上面顯示,主要修改部分就在於 workdir: ./cmd/test_cli 放在 Steps Run GoReleaser 裡面的 with:。 這樣就可以正常的編譯出執行檔案,並且更新 changelogs 。

多個相關的執行檔案需要編譯 / 客製化編譯選項

因為原先在 .github/workflows資料夾中,有相關的指令限制,參考 github action Workflow syntax

如果有想要更多客製化編譯選項如下:

  • 多個資料夾在 /cmd/ 底下。
  • 讓 GoReleaser 的編譯選項多一些,預設會全部 Compile 。可以挑選只要 Mac + UNIX ,或是加上 x64 選項。
  • 加上一些 enviironment variable (e.g. CGO_ENABLED=0)
  • 打 LDFLAGS 給 go build (e.g. -s -w -X main.build=)
  • 透過 hooks 來跑某一個 compile shell script (e.g. post: ./script.sh )

如果有以上相關的客製化選項,可能就需要將 GoReleaser config 獨立出來成一個檔案,相關做法如下:

主要修改就是透過 args: release -f .goreleaser.yml --rm-dist 來將設定透過 .goreleaser.yml 來跑。 這樣就等於 goreleaser release -f .goreleaser.yml --rm-dist的意思。

該檔案內容可以參考文件上面的檔案。

也可以參考 PR https://github.com/kkdai/disqus-to-github-issues-go/pull/4

結論與未來

透過引用到 external config file 的方式,來讓 Github Action 的 GoReleaser 可以有更多的客製化選項,其實不僅僅可以只打包,還有更多的方式可以使用 上傳檔案到其他的 Artifactory 或是 Docker build 。 這樣也可以讓打包產品上,變得更加的簡單方便。

相關文章: