岩田聰如是說：從天才程式設計師到遊戲公司社長，任天堂中興之主傳奇的一生。 作者： ほぼ日刊イトイ新聞 出版社：台灣東販 語言：繁體中文 ISBN: 9789865119263 eISBN: 9786263046443 字數： 51,266 買書推薦網址： 電子書: Readmoo 博客來: 購買網址 前言: 這一本是今年所讀完的第七本書。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 圖書館也能借免費線上影片 這邊順便整理一下，要借線上免費影片，也可以在圖書館借。（圖書館真棒！！） 公共圖書館區域資源中心電影院 – 免費提供數百部電影、紀錄片等讓你線上看 參考文章 台北市立圖書館 x 台北好讀 國立圖書館 x 台北好讀 2021更【電子書App推薦 – Hyread+台北圖書館】萬本好書在各種裝置上閱讀 台灣圖書館電子書搜尋 台灣雲端書庫 國立臺灣圖書館 台北市圖書館 新北市圖書館 台中市圖書館 公共圖書館區域資源中心電影院 – 免費提供數百部電影、紀錄片等讓你線上看

前言: 各位好， 我是 LINE Taiwan 資深開發技術推廣工程師 – Evan Lin。 今天這篇文章為各位詳細解釋 「 LINE Bot 開發指南」這一份投影片文件。這一份文件是來自於 Development guidelines 的投影片，考量到在台灣還沒有正式的公布與中文化。這一次跟總部共同合作準備中文版本之外，並且特定用這一系列文章加以解釋，希望可以讓更多開發者有更多的了解。 Development guidelines 文件內容很多，本份投影片也將以五篇文章的篇幅來加以解釋。本篇文章為第二篇文章，主要講解的會是關於設定 LINE Bot Webhook 相關注意事項。 文章索引: 完整投影片鏈結： https://speakerdeck.com/line_developers_tw2/line-bot-developer-guideline-chinese 希望各位可以持續關注： 關於LINE Bot 使用Webhook URL接收請求時的注意事項(本篇文章) 發送 API 請求時的注意事項 LINE Login LINE Login (補充） 其他相關功能 本篇文章將專注在第一個段落，也就是 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 。 平台開始支援 TLS 1.3 LINE’s APIs now support TLS 1.3 將不在支援 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 ) 第一件事：正確設定HTTPS from 在 「開發LINE聊天機器人不可不知的十件事」 也有提到相關的支援，請開發者們務必要注意。 在設定HTTPS伺服器時，有下列幾點必須注意的事項： HTTPS伺服器所使用的根憑證（Root CA）必須是在LINE平台的白名單列表中，否則LINE平台會拒絕傳送訊息。在白名單列表中大多數的憑證都需要付費申請，但是LINE平台也支援常用的免費憑證，例如Let’s Encrypt。 請勿使用已知具有安全性漏洞的協定（例如SSL v2或SSL v3）或Cipher Suite（例如SWEET32或CVE-2016-2183）。 請務必正確設定中繼憑證（Intermediate certificate），以避免無法對應到根憑證而發生錯誤。這是最常見的問題通報狀況，請在設定HTTPS伺服器時多加留意。 更多訊息歡迎參考以下文章：...

前言: 在二月份文章有提到 使用 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...

前言: 各位好， 我是 LINE Taiwan 資深開發技術推廣工程師 – Evan Lin。 今天這篇文章為各位詳細解釋 「 LINE Bot 開發指南」這一份投影片文件。這一份文件是來自於 Development guidelines 的投影片，考量到在台灣還沒有正式的公布與中文化。這一次跟總部共同合作準備中文版本之外，並且特定用這一系列文章加以解釋，希望可以讓更多開發者有更多的了解。 Development guidelines 文件內容很多，本篇文章也將以五篇文章的篇幅來加以解釋。 文章索引: 完整投影片鏈結： https://speakerdeck.com/line_developers_tw2/line-bot-developer-guideline-chinese 希望各位可以持續關注： 關於LINE Bot (本篇文章) 使用Webhook URL接收請求時的注意事項 發送 API 請求時的注意事項 LINE Login LINE Login (補充） 其他相關功能 本篇文章將專注在第一個段落，也就是 Page 3 ~ Page 8 的部分。 LINE Developers 相關資源 這邊主要提到兩個網站，分別是： LINE Developer Doc: 負責存放所有的相關產品說明文件， API 詳細說明。 LINE Developer Console: 這就是開發者稱為的控制台部分，跟官方帳號 (Official Account) 的後台不同，這邊主要是負責設定相關的開發資源。 不論是建立新的 Channel 或是新增，修改 LIFF App 都可以利用控制來完成。 LINE Bot 的機制 這一張投影片解釋了一個使用者傳訊息給一個官方帳號後，訊息會如何透貴 LINE 的平台傳遞到開發者的（也就是圖上的客戶端）的 Bot 伺服器。 這邊表達了幾件事情： 所有訊息都會透過 LINE 平台的 Talk 伺服器與 Channel Gateway 伺服器處理後傳給 「 Bot 伺服器」。訊息都是透過 Webhook 的方式傳遞，開發者只要依照官方文件開發好像關的 「Bot 伺服器」並且在登入好 webhook 的位置。就可以正確地收到訊息。 開發者處理完訊息後，可以透過 API 的方式發送給 LINE Channel Gateway 。 會在依照相關的訊息發送人透過 Talk 伺服器來發送訊息。 相關的開發者文件可以參考： Receiving messages (webhooks) Sending messages 關於 LINE Bot 與 Channel 之間的相關性 這張投影片解釋了官方帳號與 Channel 之間的相關性，接下來將為讀者詳細解釋: 首先使用者對於官方帳號（LINE Bot) 所做的所有動作，都有相關的訊息透過 Webhook 來傳給開發者的 LINE Bot 。 LINE Bot 收到訊息後，可以透過取得的 Access Token 來通過伺服器認證來發送訊息給使用者。 透過 LINE Login 的認證部分也可以將使用者鏈結到相關 LINEE Bot 帳號。（ e.g. 透過網路商城的第三方登入 LINE Login ，可以讓使用者登入網路商城後，也直接加入 LINE Bot ）。 相關部分可以參考文章： 如何透過...

前言: 前幾天的文章中 [Jekyll] 移除 Disqu 替換到 utteranc 來使用 github issue 作為文章評論 ，我有提到我將本來部落格中的 Disqus 評論有搬到 https://utteranc.es/ 的過程，但是在 Disqus 裡面還有接近兩百個留言 (共有 189 個留言，分別在 55 篇文章內) 怎麼辦？ 秉持著自己打造自己用的小工具原則（ –關在家裡太無聊– ），就寫出了這個小工具來使用，希望能幫助到一些人。 也希望有更多的人一起加入開發相關功能。 TL;DR 本篇文將要介紹以下一些的部分，除了介紹如何使用外。人和 如何導出 Disqus Comment 套件: Disqus to github issue Go  包括哪些功能 Disqus XML Format 解析 Github issue created in Go 結論 成果 參考文章 如何導出 Disqus Comment 到 Utteranc 到 Disqus 管理介面，去導出： http://disqus.com/admin/discussions/export/ 。 大概需要過一兩天才會收到導出的檔案（不定時）。 到 Utteranc 設定導入 修改 Github Page 設定。 可以參考文章 [Jekyll] 移除 Disqu 替換到 utteranc 來使用 github issue 作為文章評論 套件: Disqus to github issues Go https://github.com/kkdai/disqus-to-github-issues-go 安裝套件方式：``go get github.com/kkdai/disqus-to-github-issues-go` 並且提供一個 CLI 給大家先用，大家可以安裝 go install github.com/kkdai/disqus-to-github-issues-go/cmd/import_disqus_cli 相關指令： -f: Import disqus exported xml file. (get from http://disqus.com/admin/discussions/export/) -u: github user name, you want to use for post github issue. -r: github repo name, you want to use for post github issue. -t: github token, you can request your from https://github.com/settings/tokens. 使用指令範例： ./import_disqus_cli -f="EXPORTED_XML_FILE" -r="BLOG_REPO" -u="GITHUB_USER" -t="YOUR_TOKEN" 包括哪些功能 讀取從 disqus export 的...