Instagram崛起的內幕與代價-以及它如何改變了文化、商業、科技、媒體，與我們每一個人 (No Filter : The Inside Story of Instagram) 原文作者： Sarah Frier 譯者： 余韋達 出版社：臉譜 出版日期：2020/11/26 語言： 買書推薦網址： 博客來: 購買網址 電子書: Readmoo 前言: 這一本是今年所讀完的第二本書。 會讀這本書主要是因為聽「星箭傳播」的Podcast 節目第八十七集（不能再多？）的節目介紹到這本書。雖然有一個多小時的 Podcast 介紹這本書，但是還是讓人欲罷不能，很想買來好好的閱讀。 這本書主要是介紹 Instagram 的崛起，到了 2012 被臉書以十億美金的收購價格收購。一開始雖然承諾會讓 Instagram 以獨立的方式來發展，但是隨著臉書的使用者逐漸地轉移到了 Instagram ，也讓臉書的人做了許多相關的干涉，最後導致創辦人 Kevin Systrom 離開了臉書。 裡面有許多詳細的描述，也讓人更了解臉書是如何併購一家公司。 參考節目： 《星箭廣播》87 集——10 億個世界：Instagram 的「無濾鏡」創業故事 Instagram wiki 內容簡介與心得: 創立於2010年的Instagram，在短短數年內崛起，為目前全球互動率第二高的社群媒體平台，僅次於臉書。每個月全球有超過十億人使用Instagram，日活躍用戶高達五億，每天上傳的照片與影片超過一億則。2019年，它的年廣告營收高達兩百億美金，表現大勝 YouTube的五十億。 究竟非典型的矽谷創業家凱文．斯特羅姆與出身巴西的工程師麥克．克里格，是如何在一片紅海中以「反直覺」的決策打造出Instagram，並帶領它在短短十八個月內從不被看好到一夕爆紅，吸引臉書（Facebook）CEO馬克．祖克柏斥資十億美金天價收購，進一步獲得今日商業上的成功？在傳奇性成功的背後，Instagram以及所有使用者，又付出了哪些代價？ 章節條列 第一章 代號：計畫 第二章 成功的混亂 第三章 一場驚喜 第四章 充滿不確定性的夏天 第五章 快速移動，打破成規 第六章 全面宰制 第七章 新名人階級 第八章 追尋Instagram的價值 第九章 Snapchat危機 第十章 自相殘殺 第十一章 另一則假新聞 第十二章 執行長 結語 收購的代價 2010 年所開始的服務 Instagram ，一開始主打的就是簡單的相片分享服務與相片濾鏡服務。靠著分享到臉書與推特的功能，開始讓更多的人來加入使用。走著跟臉書不同的路線，主打著攝影分享，讓使用者可以快速分享，以使用者為主的概念。很快速地獲得許多的人加入。 但是也被競爭對手（？）臉書看上，在 2012 併購，本書也介紹了整起併購案的整個經過（當然是透過新聞與許多其他人的採訪得知）。 雖然進入了臉書，一開始也是維持得獨立的方式來經營。一反臉書主要以廣告平台的經營方式， Instagram 透過主動與廣告主主動聯繫，並且提供許多的建議與專屬的優惠。讓許多的廣告商（甚至本來不喜歡臉書的廣告商）也會來投放 Instagram 的廣告。也透過使用者為主的經驗，並且沒讓人（明顯）感受到臉書擁有 Instagram 的狀況下。 也加入許多功能加入讓臉書可以一舉打敗許多競爭對手（Snapchat) ， 並且也在 2019 年讓使用者增長到十億，並且收入也高達臉書整體收入的四分之一。 最恐怖的是，當許多年輕人都在笑臉書使用者老派的時候而跳去使用 Instagram ，卻沒有人感受到其實他也是臉書的使用者之一。 但是世界上並沒有那麼美好， Instagram 的快速成長令一方面也讓臉書的使用者成長遲緩了。 於是臉書的高層（Growth Hacking team?) 也做了許多研究，並且開始阻礙許多來自於臉術轉換到 Instagram 的流量方式。當初「獨立發展」看起來也並沒有完全的實現，也導致創始人在 2019 年離開臉書。 本書基本上有大概百分之二十的部分都在講解著他們成功所帶來的「犧牲」與「掙扎」。還有當初答應臉書購併所帶來的「代價」。 心得: 我想所有的新創公司的人，許多人都希望在成長得時候能夠順利地被大公司所收購。但是沒有人想過，許多好的服務都是避免被坐大才被對手「防禦性收購」的方式所購買下來。 雖然臉書收購了 Instagram 之後，沒有馬上將它下架並且並為己有。 也讓 Instagram 成長到超過十億的使用戶。 但是由於許多的人就是不喜歡臉書而逃避到 Instagram 想不到還是在臉書的旗下。 也難怪許多人會說臉書收購 Instagram 可以說是近十年最值得的併購案。 本書也清楚的交代了一家公司被併購後，並不是馬上所有人都能夠雞犬升天，馬上就坐擁千萬的財產。許多的併購案往往都只有讓工程人員得以併入母公司，雖然可能獲得便宜的換股機會，但是也並非所有人能夠用漂亮的股價直接轉換成現金。並且併購發生後往往會有母公司與子公司的資源分配問題，與「功高震主」的機會。就像是本書的 Instagram 一樣，遇到許多來自於母公司的審核與干涉。這些真實世界的內幕，在這本書很難得敘述得相當清楚。很推薦新創產業的從業人員好好看一看這本書。

前言: 使用 Golang 來開發小工具最方便的方式，就是可以很快速將程式碼託管在 github.com 。 並且透過 Golang 的跨平台編譯的工具，可以快速打包出各種平台（Windows, Linux 跟 Mac 平台）的執行檔。 那麼有沒有方式可以直接在 github.com 發行新的版本後，直接就打包好所有執行檔變且幫你把 Changelog 都打好呢？ TL;DR 本篇文將要介紹： 以前如何打包跨平台的套件 (GOX) 新的打包套件 GoReleaser 如何整合到 GitHub action 發行新的版本 (Release) 的時候，就直接打包好新版本 並且可以自動幫你打好所有 Release Note （包含 Changelog ) 以前要如何打包你的 Golang CLI ? 在以前的時候，曾經有出過一個很方便可以快速打包所有平台執行檔案的小工具。 Gox 就是一個很方便的小工具： GOX 快速快平台打包工具（以前） https://github.com/mitchellh/gox $ go get github.com/mitchellh/gox ... $ gox -h ... 就這麼簡單，就可以快速編譯跨平台的工具。 其實因為 Golang 從 1.5 之後就支援跨平台編譯。 其實跨平台編譯透過 env GOOS=linux GOARCH=arm go build -v github.com/constabulary/gb/cmd/gb 透過這個方式就可以快速的打包你的工具，所以其實後來 gox 就也比較沒人在用。 需要注意地方： AMD 64 只能編譯 AMD64 如果要編輯 ARM 就需要使用到 ARM 版本的處理好才可以。 關於跨平台打包（編譯）更多的文章: 關於跨平台編譯更多的詳細敘述，可以參考這篇 Dave Cheney 的文章。 Cross compilation with Go 1.5 An introduction to cross compilation with Go GoReleaser 一個好用的打包發佈的工具 後來我也看到 https://github.com/kkdai/youtube 一起在打造的夥伴們有導入 GoReleaser 。 看了一下，發現還真的蠻好用的。 這裡簡單介紹一下， GoReleaser 有做哪些事情: 幫助你一次透過多平台打包套件 可以深度整合 Github 跟 Gitlab 讓你直接發佈整個產品提供下載 可以幫忙整理出 ChangeLog 可以幫忙整理出 ChangeLog 可以幫忙整理出 ChangeLog (懶人福星) 整合 Docker 相關功能（打包 Docker Image) GoReleaser 的安裝方式 brew install goreleaser/tap/goreleaser curl -sfL https://install.goreleaser.com/github.com/goreleaser/goreleaser.sh | sh 如何使用 GoReleaser 參考 GoReleaser QuickStar goreleaser init 來產生 .goreleaser.yml 的樣板檔案 來測試一下打包 goreleaser...

前言 大家好，我是 LINE Taiwan Developer Relations 團隊的 - Evan Lin。 經過了一年多來的 LINE Developer Relations 的努力，想要在這篇文章裡面稍微整理一下整個團隊做了哪一些的事情，也希望為了「LINE 開發社群計劃」做年度報告。 根據原先 LINE Developer Relations 所寫的介紹文章 (Introducing Developer Relations team) 裡面很清楚地定義了這個團隊的主要目標如下： External Evangelism: 鼓勵開發者使用 LINE 的平台，API與SDK 來開發出具有魅力與有趣的應用服務。 (Encouraging people to make attractive and interesting services using the APIs and the SDK by LINE) Internal Evangelism: 透過一些方式使得工程師們自我成長與磨練自己 (Doing whatever our engineers feel difficult to do themselves in making improvements at work) Technical Branding and Hiring: 讓更多人了解身為 LINER(LINE 員工的自稱) 有許多有趣與令人興奮的事情。 (Letting people know how fun and exciting it is for engineers to work at LINE) 上一篇文章，已經明確的定義了 External Evangelism，接下來將更進一步的解釋 Technical Branding and Hiring。 文章列表: [LINE DevRel] LINE Taiwan Developer Relations 2020 回顧與 2020 開發社群計畫報告 (part 1: External Evangelism) [LINE DevRel] LINE Taiwan Developer Relations 2020 回顧與 2020 開發社群計畫報告 (part 2: Internal Evangelism) [LINE DevRel] LINE Taiwan Developer Relations 2020 回顧與 2020 開發社群計畫報告 (part 3: **Technical Branding and Hiring) (本篇文章) Technical Branding and Hiring: 讓更多人了解身為 LINER(LINE 員工的自稱) 有許多有趣與令人興奮的事情。 LINE...

前言 大家好，我是 LINE Taiwan Developer Relations 團隊的 - Evan Lin。 經過了一年多來的 LINE Developer Relations 的努力，想要在這篇文章裡面稍微整理一下整個團隊做了哪一些的事情，也希望為了「LINE 開發社群計劃」做年度報告。 根據原先 LINE Developer Relations 所寫的介紹文章 (Introducing Developer Relations team) 裡面很清楚地定義了這個團隊的主要目標如下： External Evangelism: 鼓勵開發者使用 LINE 的平台，API與SDK 來開發出具有魅力與有趣的應用服務。 (Encouraging people to make attractive and interesting services using the APIs and the SDK by LINE) Internal Evangelism: 透過一些方式使得工程師們自我成長與磨練自己 (Doing whatever our engineers feel difficult to do themselves in making improvements at work) Technical Branding and Hiring: 讓更多人了解身為 LINER(LINE 員工的自稱) 有許多有趣與令人興奮的事情。 (Letting people know how fun and exciting it is for engineers to work at LINE) 上一篇文章，已經明確的定義了 External Evangelism，接下來將更進一步的解釋 Internal Evangelism 與 Technical Branding and Hiring。 文章列表: [LINE DevRel] LINE Taiwan Developer Relations 2020 回顧與 2020 開發社群計畫報告 (part 1: External Evangelism) [LINE DevRel] LINE Taiwan Developer Relations 2020 回顧與 2020 開發社群計畫報告 (part 2: Internal Evangelism) (本篇文章) [LINE DevRel] LINE Taiwan Developer Relations 2020 回顧與 2020 開發社群計畫報告 (part 3: Technical Branding and Hiring) Internal Evangelism: 透過一些方式使得工程師們自我成長與磨練自己 首先這個部分大部分都是內部的分享與一些讓 LINER（在 LINE...

前言 大家好，我是 LINE Taiwan Developer Relations 團隊的 Evan Lin。 經過了 2020 年的 LINE Developer Relations 的努力，想要在這篇文章裡面稍微整理一下整個團隊做了哪一些的事情。 根據原先 LINE Developer Relations 所寫的介紹文章 (Introducing Developer Relations team) 裡面很清楚地定義了這個團隊的主要目標如下： External Evangelism: 鼓勵開發者使用 LINE 的平台，API與SDK 來開發出具有魅力與有趣的應用服務。 (Encouraging people to make attractive and interesting services using the APIs and the SDK by LINE) Internal Evangelism: 透過一些方式使得工程師們自我成長與磨練自己 (Doing whatever our engineers feel difficult to do themselves in making improvements at work) Technical Branding and Hiring: 讓更多人了解身為 LINER(LINE 員工的自稱) 有許多有趣與令人興奮的事情。 (Letting people know how fun and exciting it is for engineers to work at LINE) 以下的文章將會分成這三個部分來依序說明，也希望能讓更多的開發者跟著我們一起回顧 2019 開發者關係與技術推廣部有哪些有趣的成果。 文章列表: [LINE DevRel] LINE Taiwan Developer Relations 2020 回顧與 2020 開發社群計畫報告 (part 1: External Evangelism) (本篇文章) [LINE DevRel] LINE Taiwan Developer Relations 2020 回顧與 2020 開發社群計畫報告 (part 2: Internal Evangelism) [LINE DevRel] LINE Taiwan Developer Relations 2020 回顧與 2020 開發社群計畫報告 (part 3: Technical Branding and Hiring) External Evangelism: 鼓勵開發者使用 LINE 的平台，API 與SDK 來開發出具有魅力與有趣的應用服務 首先先介紹的是關於平台推廣的部分，今年的平台推廣主要有兩個重要的管道。一個就是開發者官方社群 OA (@line_tw_dev) 另外一個就是 LINE 開發者小聚。...

前提 一個關於 PTT BBS 後台 Golang 後端夥伴（因爲是交朋友專案，沒有薪水）的討論，在 Golang TG 的討論上也帶出關於 PTT 後台需求的討論。 以下經過整理後，貼上相關的討論內容。 以下先整理一些關於徵夥伴文的相關脈絡，裡面許多內容都是引用原文作者。 PTT 原文在這： moptt https://moptt.tw/p/Soft_Job.M.1610976994.A.2C8 ptt.cc https://www.ptt.cc/bbs/Soft_Job/M.1610976994.A.2C8.html 為何在找夥伴的文章上要求讀過 database/sql 與 go-sql-driver/mysql 兩個套件? 主要是風格問題，我(Pichu Chen) 基本上很擔心有人直接把 C Code Porting 成 Golang 的 Code, 然後註解通通都寫請去看 C Code 的哪個 function, 那這樣就GG了XD 關於 PTT BBS 找 Golang 夥伴，現階段目的? 這階段會想要先把整體 BBS 該有的讀寫的 interface 以及後續討論和採用的文化建立起來。 而目前我(Pichu Chen) 提出的解決方案是重新設計後端介面。 我們初期將會得到一個新的基於 HTTP 的後端介面， PTT APP 中台或者是行動 APP 的開發夥伴可以透過這個介面來存取 BBS 的資料庫。 在開發中有別以往 BBS 的開發流程，新的流程我會先將需要的功能寫成文字文件並且提出討論，一段時間後開立 GitHub ISSUE 進行實作。 因此可以確保新的程式碼是有文件以及清晰易懂的測試案例的，避免重蹈覆轍。 目前我們已經完成驗證帳號、取得看板(baord)列表、取得文章列表以及取得文章內容等功能，我們還需要持續完成新增推文(push/recommend)、新增文章、編輯我的最愛等等的功能。 但是我個人有個額外的請求，因為有先前在 Soft_Job 上提到的「東京都新冠肺炎對策網站(https://stopcovid19.metro.tokyo.lg.jp/)」的經驗，我還是希望能做到是由社群的多數人共同完成這個專案，而不是如同多數在台灣的開源專案，是由固定幾個「大神」來完成的。 PTT 目前的問題 (由輕重緩急排列) 介面/商業邏輯/資料庫的程式碼混在一起，造成調整使用者體驗上以及使用者介面上調整困難。 程式碼缺乏註解，可讀性極低。 原先的程式碼完全沒有 testing code. 程式碼完全沒有 benchmark 機制，修改架構仰賴設計者的威望而非科學證據。 大部分的架構仍然使用 32 位元的時間表示方式，這會導致 2038 問題。 密碼仍採用基於 DES 的雜湊方式，換句話說，強度不足。 過度仰賴共享記憶體的設計造成伺服器分散困難。 索引檔儲存方式彈性不足，不易新增新欄位。 轉信機制死亡已久。 站內訊息 （水球）、站內信無法透過手機即時通知使用者。 Current PTT 程式碼尚不支援 IPv6. 站內文章仍然使用 Big-5 儲存，不支援 emoji 或是台羅拼音。 不支援圖片上傳、音訊或是視訊通訊。 所以讀過 SQL 套件並不是要把 PTT 資料寫進資料庫? 其實bbs文章算滿階層的，就是文章自己擁有一個unique id，然後board去ref一個個的id，這個其實ptt已經有了，就是他們自家的網址轉換系統（像是: https://www.ptt.cc/bbs/car/M.1611180581.A.E43.html）這個什麼M.161180581.A.E43這類，所以既然有現成的key跟key generator，這方面應該可以不用重新設計。另外圖片跟log…er… bbs的資料應該絕大多數都不是圖片也不是log就是。 PTT 如果資料寫進資料庫的話 然後要不要把 BBS 的後端資料庫轉成 SQL 的討論歷史有點長了，但就結論而言數年來的討論下來，其實真的整個變成全SQL 架構的真的是沒有（也許巴哈有？畢竟他們家沒開源所以不知道）不過這階段我會想要先把整體 BBS 該有的讀寫的 interface 以及後續討論和採用的文化建立起來，因為先前確實有不少討論要不要轉成 SQL 的文章，但是實際上的效能測試也是幾乎沒有，那interface建立起來之後再試試看另外一個分支是以SQL實作的分支，這樣有效能數據之後這個問題才會比較容易在討論中有結論。 如果 PTT 資料有機會放入 RMDB 的話 如果說是把原有的資料庫轉成 SQL 系列的關聯式資料庫或者是 MongoDB 的話，我覺得優點上會是這些是現代開發人員熟悉的資料庫工具，再來是效能部分有其他團隊幫忙把關，以及有現成的分散式資料庫的設計。 缺點的部分我在數年前有問過學長，比較大的部分在於 SQL Command 需要另外做 Parsing，會有額外的開銷，再來是並不是所有東西都適合無腦塞SQL ，像是圖片或是Log檔設計我可能就不會把它放在關聯式資料庫上，我猜AWS...