同步發表於部落格

前言

最近真的很喜歡各種 IoT 的應用,買了很多 Arduino 跟各種感測器,光是手上有的 Arduino 就有 Arduino Uno、Arduino Mega2560、Arduino nano * 3。想說有空就來玩玩,看能不能做出一些有趣的應用,順便趁著這個機會複習一下高中的電子學還有各種硬體的運作。

剛好公司舉辦了社內黑客松,對於主題沒有太多限制,就用了這段期間實作了之前就很想做的應用,「空氣品質監測器」。雖說是空氣品質,不過實作出來後也只有二氧化碳濃度跟溫濕度監測,如果有感測器的話要另外加上也不是太大的問題就是了。

會有這個想法主要是因為二氧化碳的濃度真的會影響人的思考跟產能,相信大家都有關在會議室裡結果突然就覺得頭昏、思緒混亂的情形吧。有很大的可能性就是因為二氧化碳濃度過高導致。如果換氣不佳加上密閉空間,二氧化碳濃度上升速度非常快,幾分鐘內就到 2000 多 ppm 了。

除了實作本身以外,因為我實在不喜歡套件套一套然後就完成的感覺,所以我會盡量涉略多一點細節,才不會有種「啊套件套完了,但發生什麼事都不知道」的空虛感。(雖然實作還是用套件,但至少用得比較心安理得XD)

本系列文會涵蓋以下的主題:

  1. 感測器介紹篇 — DHT11 與 MH-Z14A
  2. 資料溝通篇 — UART(實作是用 UART,所以只講 UART)
  3. Arduino 踩雷篇:會講解在實作時遇到的問題,很多時候不是雷,是對 Arduino 跟硬體不熟悉
  4. WiFi 篇:為了省下 Debug 的時間,我額外購買了 ESP32 開發版,本身已經含有 WiFi 跟藍芽功能
  5. MQTT 篇:為了把資料傳給其他設備,使用了 MQTT 這個輕薄短小的通訊協定
  6. Grafana / Web 篇:資料存在資料庫當然要用炫炮的方式顯示出來啊!這裡使用了 Grafana + Promethus 以及 Svelte 來顯示資料。

架構

為了方便說明,架構上大概長得像是這樣:

Infrastructure
Infrastructure
  • Arduino Uno 傳送指令給 CO2 感測器,CO2 感測器回傳資料給 Arduino,兩者透過 UART 溝通
  • Arduino Uno 傳送 CO2 資料給 ESP32(也是用 UART)
  • 透過 DHT11 得到溫濕度資料,再傳送給 ESP32
  • ESP32 將溫濕度資料以及 CO2 資料透過 WiFi 傳給 MQTT Borker
  • 訂閱事件的應用有兩個:分析伺服器以及 App…

裡頭的分享蠻完整的,建議大家進去看看,接下來做些補充:

IDE 整合這個觀點蠻有趣的。我覺得因為 svelte 的聲量跟社群還不夠廣,所以 IDE 擴充這一塊可能還要再等一陣子,LESS 的支援也是。

svelte 的 css 是直接寫在 style tag 裡面,在 compile time 的時候就幫你做好 class 並且加入 hash,這樣子的好處在於:

  • 可以靜態分析 CSS,幫你刪掉不必要的選擇器(REPL
  • 在 compile time 可以提示沒有用到的選擇器

Svelte 在遇到 <style> 時並不是照本宣科將內容塞進去而已,而是使用了 css-tree 爬過一遍後去配對內容是否有用到,再自動加上 hash 做 scope(可以查看 REPL

這有幾個缺點,像是下面的程式碼就沒辦法正確套用:

<script>
let html = '<p class='p'>My Paragraph</p>'
</script>
<style>
.p {
font-size: 20px;
}
</style>
{@html html}

因為 html 變數是要等到 runtime 才能知道內容,所以事實上這樣的寫法沒辦法正確套用樣式。而是要寫成 :global

還有就是 CSS 優先度的問題,例如這個 Issue

編譯機制

Svelte 還有很優秀的一點在於 compile 機制本身。既然會先過一層 compile,代表任何可以靜態分析的事,compiler 都可以幫你做掉。例如:

  • 變數忘記宣告了,沒關係 compiler 告訴你
Image for post
Image for post
  • 加入了一個不支援的 attribute,沒關係 compiler 告訴你
Image for post
Image for post
  • a11y 沒有做,沒關係 compiler 告訴你
Image for post
Image for post
  • 實際上 svelte 相當重視這一塊,例如 a tag 沒加 href、img tag 沒加 alt,全部都會讓 compiler 不高興
  • 多餘的變數宣告,沒關係 compiler 幫你拿掉

我很喜歡 Svelte 對於 a11y 的理念,作者甚至花了大量的時間去實作,我也曾經貢獻過一個,因為是在 compile time 做掉的關係,完全不會影響 bundle size。靜態分析的好處可以只讓需要的 JavaScript 被引入,bundle size 就會比 Vue、React…


Image for post
Image for post

一直以來,我都覺得自己是「收穫」大於「付出」的人。你可以參考我在前幾年寫的北漂青年在台北生活的這幾年

從小到大因為家境的關係,所以時常要靠補助才能讓生活過得比較寬裕一些,我算是比較幸運的那一群,家境雖然不好,但還沒有悲慘到家徒四壁、一貧如洗。這個情況到了大學二年級左右,比較有能力可以靠自己養活自己時,狀況才開始逐漸改善。

所以近幾年也開始思考,除了工作本身之外,透過自身的能力,還可以怎樣幫助別人?

當時 huli 可以說是影響我很深,那個時期他做許多免費的程式教學和撰寫大量的初學者導向的文章,來幫助他們入門寫程式或是轉職,甚至還開始了「程式導師實驗計畫」。

額外一提,如果你很想要轉職成(前端)工程師的話,這個計畫非常值得一看,除了課程本身非常紮實之外,你幾乎可以用沒有風險的方式來報名這個計畫。

回歸主題,答案不是很明顯嗎?

對啊,我是一位工程師,會寫一些程式,那麼程式就是我最大的武器呀!只要有電腦跟網路,就可以善用程式碼來幫助身邊的人!雖然不是手把手地去教初學者,但的確也可以用這種方式來幫助別人。

也因此我逐漸找到可以嘗試的目標,就是用程式做一些可以提供實質幫助的事。雖然人微言輕,有時候不一定能引起什麼廣大迴響或關注,但至少在自己做得到的範圍貢獻,不就是一件很棒的事情了嗎?

在這之前我也想先推廣一下我以前曾經做的事:

1. 勞工大代誌(2017)

https://kjj6198.github.io/pround-of-labor/app/

Image for post
Image for post

這是我在 2017 年勞動節時做的一個小專案。勞基法已成立 33 年,台灣的勞動環境仍有很大的改善空間。 儘管如此,勞工意識逐漸抬頭,老前輩們留下的足跡不可置否。 這些豐碩的成果是靠他們的汗水、鮮血、甚至性命換來的。

當時覺得「啊,都不知道以前台灣發生過怎樣的事」,就這樣當成假日在過,覺得有點可惜,所以花了一些時間整理了政府的資料,把它做成了一個網頁。雖然製作的時間很趕,程式碼醜醜的,但我相信或多或少可以幫助到一些人理解背景,或是逐漸重視勞動環境的重要性。

2. 八百屋(2017)

八百屋也是我在 2017…


隨著使用者對隱私權的重視,各個服務也都逐漸開始調整自家的隱私權與安全,像是 Mac 改版到 Catalina 之後會很煩人地問你是否要同意 xxx 存取某某資源。

雖然安全性上的確是變得更嚴謹了,不過也因為如此有時候會出現一些慘案。像是 WACOM 手繪版沒辦法順利使用之類的。

Image for post
Image for post

而 Google 也在 2019 的 Google I/O 大會上宣佈了安全政策調整,其中對目前網頁開發影響最大的應該就是 Chrome 官方會逐漸移除第三方 Cookie 的支援。

其中從 Chrome 80+ 開始,會將 Cookie 當中的 samesite attribute 預設設定為 lax (在版本 80 之預設是 None)。接下來我們會從 samesite 的定義以及它有什麼用處,還有對 Cookie 的反思為出發點,談談我對整件事的想法。

Cookie 是什麼?

Cookie 是一個在客戶端實作的小型儲存機制(4KB),可以由 Server 端回傳的 Response Header 來控制。以往只要使用了 Cookie,整個機制的實作通常是仰賴瀏覽器端,瀏覽器會根據目前的條件以及設定的標頭來決定是否可以發送 Cookie、何時過期等等。在 Cookie 還沒有過期且符合條件的情況下,Cookie 就會自動包含在每個 request 裡頭送出。

對於無狀態的 HTTP Request 來說,Cookie 的機制讓我們可以保有一些使用者的資料,讓 Server 判斷目前的使用者狀態,或是用來做一些追蹤。

我會說 cookie 最方便同時也是最致命的機制就是這點。

在 Cookie 還沒有過期且符合條件的情況下,Cookie 就會自動包含在每個 request 裡頭送出

為什麼會這麼說呢?在一般情況下像是 <form> <iframe> <a> <link> <img> 等等,預設都會把 Cookie 送出,所以我們可以做到像是下面這些事:

  1. 透過 iframe 做第三方追蹤
  • 你登入了 google 帳號,google.com 回傳 Set-Cookie 並儲存在瀏覽器端
  • 你在 B 網站瀏覽網頁,B 網站內嵌 google iframe 做追蹤
  • iframe 將 cookie 送到 google

2. 透過 <img>


mailchimp 是我相當喜歡的電子報寄送服務,斷斷續續也用了三年了,突然想寫下來。

我在三年前寫了一份週刊,叫做日語八百屋,當時主要就是以 mailchimp 來做電子報。

要做電子報寄送服務並不簡單,像是 event tracking、資料統計、不掉信、重試、針對不同的客戶端優化等,也因此 mailchimp 這個在早期就進入市場的產品相對穩定而且有非常多的企業正在使用。

這篇報導記錄了他們的創業故事。

mailchimp 的前身是一家接案公司,專門幫各個企業解決他們的問題並且幫助他們成長,後來發現各個小企業都有對於電子報的需求,因此逐漸將心力轉移到做電子報服務上面。

這個 mailchimp 到現在也已經 10 多年了,網站甚至還可以看到 ember 的痕跡,但是仍然是個非常好用的服務。

讓我最感動的是關於他的定價方案,在 2000 以內的訂閱者 + 10000 封信一個月的額度下,完 全 免 費,沒有任何試用期。

Image for post
Image for post

這樣的額度已經足以讓一個創業公司累積到第一批使用者甚至開始盈利,直到你的額度超過了之後 mailchimp 才會開始收錢。

這就就好像在跟你說,嘿我知道你正忙著燒錢累積使用者,打造優秀的產品,等到你的公司茁壯了再付錢給我吧。

雖然進入付費階段後那個價碼有點可怕(對公司來說或許還好),但是真的可以感受到 mailchimp 是很認真把你會遇到的問題和可能需要的工具都準備好了。

以我需要的功能來說:

  • 預覽
  • 電子報編輯器
  • 查看統計資料
  • 寄送測試電子報
  • 後台管理訂閱者
  • 排程寄送

這些在 mailchimp 上都可以非常容易查看跟設定。

完整的 API 與文件

如果是工程師,你甚至可以利用 mailchimp 提供的 API 做到上述的事情,打 API 自動生成電子報模板、用 API 建立 campaign 跟寄送,這樣一來就可以跟自家的產品結合,也省下非常多功夫手動操作 UI。

mailchimp 的 REST API 文件非常的清楚明瞭,而且錯誤訊息也很容易懂,非常推薦大家試試,不知不覺就串起來了。我非常欣賞這種做產品的態度和精神,也希望自己有朝一日能夠成為這樣的角色。

最後我想要以文章中最後一段當作結尾。

“Everybody we talked to said, ‘You’re sitting on a gold mine, and if you pivot to enterprise, you could be huge,’” Mr. Chestnut said. “But something in our gut always said that didn’t feel right.”

後記

老實說最近我一直在這種產品與技術之間的學習做拉扯。一方面想要繼續精進自己的技術(不管哪方面的都一樣),又想要更多做產品的經驗。不過這兩者感覺不完全是互斥,例如做產品需要技術支持,鑽研技術可能是為了更好解決服務上遇到的問題。

哇,好迷惘。


(本篇採訪於 2019 年 4 月,當時 scars 本人尚未就職)

日語八百屋人物專訪,這次邀請到了前 17 直播的前端活動組主管,在業界已有 10 年經驗,目前在京都 LINE 擔任前端工程師的 Scars。

Scars 擔任網頁開發已有 10 年經驗,經歷過 flash 時代以及快速演變的前端,也持續精進自己的技術,經歷過大大小小的專案開發,scars 累積深厚的實力,也是讓他順利赴日求職的關鍵之一,這次就讓八百屋挖掘 scars 背後的秘密吧!

採訪大綱

  1. 為什麼會想要到日本求職呢?不是日本也可以嗎?
  2. 目前的日文能力如何,未來有興趣繼續學習嗎?
  3. 可以分享一下 LINE 面試經驗嗎?
  4. 整個過程大約花了多久?
  5. 覺得跟台灣面試的差別在哪裡呢?
  6. 在工作上有跟日本人合作的經驗嗎?
  7. 到日本求職,你最大的考量是什麼?
  8. 你對日本的軟體市場(前端)有研究及了解嗎?可否分享一下你的看法?
  9. 在求職的時候,你最希望獲得哪些資訊?或是有哪些資訊是你希望早點知道的?
  10. 你認為在台灣的軟體工程師領域的經驗是否能對海外求職派上用場?
  11. 給要去日本求職的人一些建議建議吧!
  12. 有參加過日本的飲酒會嗎?分享一下經驗吧!

Q1. 為什麼會想要到日本求職呢?不是日本也可以嗎?

我在以前就有想要到海外求職的想法,特別是日本以及美國,主要是因為這兩個國家是我喜歡的兩個國家之一。

而對於我的職涯來說,想要繼續進步的話,前進海外是必要的,因此我也一直在尋找適當的時間點前往海外,而現在這個時間點剛好是我認為時機成熟了。

什麼叫做時機點成熟呢?

經驗、環境、機會,當時剛好有 Hunter 強力和我推薦日本的京都 LINE,我也覺得蠻有興趣的,剛好日本政府這幾年也在大幅延攬科技人才,我也有一定的開發經驗、管理職經歷,所以就應徵了。

為什麼會喜歡上日本呢?

要講得那麼詳細嗎?

我從小就有接觸日本文化,小說、動畫、J-POP、J-ROCK 等日本文化,就連我的英文名字 scars 也是我出自於我相當喜歡的日本樂團。

去過幾次日本,那個環境給我的感覺和待人的態度,是我相當嚮往的。而且我在高中時有迷 KONAMI (日本相當有名的遊戲機製作公司)的音 Game,同時我也會從日劇跟電影當中了解了一些日本文化。

Q2. 目前的日文能力如何,未來有興趣繼續學習嗎?

我自己的判斷是不到 N3。我都是斷斷續續從動漫、日劇中學習日文,大概學過大家的日本語前 3 課。會想要繼續學習,LINE 京都也有提供免費的日文課補助,也希望在日本生活後可以拿到 N1。

現階段還是希望可以先加強英文。

Q3. 可以分享一下 LINE 面試經驗嗎?

可以呀(笑),只是保密協定的關係,我只能講面試的過程跟心得。

我的部分是分成三個階段,面試都是在 skype 上完成。

  1. 小作業:一小時寫完的簡單程式測驗,但對於前端的基礎實力很要求,不能只會皮毛。如果沒有相關的開發經驗或是半吊子的寫法,很容易在這階段就被刷下來。後續的面試也會著重在這份作業的討論。我認為出得很好。
  2. 第一階段面試:Manager + Engineer。一組大約一小時左右,全英文面試,有 shadow translator 做即時翻譯(對方說日文,翻譯翻成英文)。以我的經驗來說不算太難,主要討論過去經歷、專案跟管理經驗
  3. 第二階段面試:京都的 Tech Lead + Engineer Manager,管理經驗以及對 Tech 的看法,以及一些情境題,問你開發的經驗跟遇到的問題。最後由 HR 說明薪資結構跟福利等等。

Q4. 整個過程大約花了多久?

從寫作業到正式拿到 offer 大約花了兩個半月左右。

是否會覺得日本求職的過程很冗長?

其實還好耶,我本來就預期海外求職需要花更多的時間拿到 offer,短時間內我也沒有用錢的需求,而且也沒有那麼急於求職。

八百屋筆記

一般求職過程主要會有書類選考(履歷書、職務經歷書等)、面接、最終面接,整個過程長短視公司的規模而定。

Q5. 覺得跟台灣面試的差別在哪裡呢?

我覺得日本在問問題時會比台灣具體一些,由於我有管理職的經驗,對方也有問關於管理上遇到的問題,會仔細問你一些具體的步驟,例如專案上有衝突時如何調度資源,分配工程師任務等等的具體做法。

在台灣問題的開放性比較高一些,像是假如你的團隊有人不聽話你會怎麼做,之類的問題。

Q6. 在工作上有跟日本人合作的經驗嗎?

有,我在 17 直播時因為要開發活動的關係,跟日本人有密切的合作經驗。我認為他們工作非常地仔細,除了心態上的細心之外還有具體的產出。

例如:日本會有鉅細靡遺的工作文件,像是辦活動時的注意事項,主播名、工作時間、經紀人是誰。台灣則是存在於各個 PM、企劃的腦中。

我其實很嚮往這樣的工作模式,因為我也是對品質相當要求的人,如果台灣的公司跟夥伴也願意這麼做的話,我相信成果肯定會不一樣。

當然缺點也跟大家一樣,日本人工作的思維比較死板一些。例如對方要求 ABC,但我們只能做到 AB,C 的話可能要用其他方案替代,但他們就會說不行,我就是要完整的 C。

那麼你怎麼應付這種情況呢?

日本人腦筋比較死一點點,所以需要靠著整個團隊的應變,在 17 我們團隊的應變力很強,大家早已經被各種「創意奔放」的需求磨鍊出堅定的心智了。

Q7. 到日本求職,你最大的考量是什麼?

  1. 家庭:對自己、家庭、小孩來說到海外工作都算是重大的決定,但家人給我很多支持
  2. 人際關係:之前朋友和我分享,日本人有時候會在背後偷偷搞你,但我在台灣職場都還沒有遇過,而且在日本很難交到朋友。

八百屋筆記

日語八百屋也曾經分享過許多日本文化的筆記唷,有興趣的讀者不妨到歷期週刊參考。

Q8. 你對日本的軟體市場有研究及了解嗎?可否分享你的看法?

由於我是從 flash 時代就進入前端開發了,當時我覺得日本做 flash 的技術真的很強。

而在軟體開發上我就沒什麼印象了,大概就是他們的外包文化跟細化程度,讓人有種日本軟體開發不怎樣的感覺。

偷偷問,你覺得 flash 在現在無法被取代的價值有哪些?

寫 flash 太容易了,但也因為太容易的關係,所以很容易寫出效能慢的程式,讓人間接認為 flash 很慢,但我認為 flash 帶給開發者的體驗是現代前端開發也無法取代的事,當然隨著時代演進還是要接受被淘汰的結局。

Q9. 在求職的時候,你最希望獲得哪些資訊?或是有哪些資訊是你希望早點知道的?

  1. 我會希望獲得在日本的生涯發展會遇到哪些問題,例如換工作、永住權、報稅、醫療等等的資訊。
  2. 職場:在日本人的觀點中,他們會注重哪些特質或表現。

Q10. 你認為在台灣工程師的經驗是否能對海外求職派上用場?

我其實不知道他們是否會看我的經驗,不過我認為在業界 10 多年的經驗,讓我很容易回答 LINE 的問題。如果我是這幾年加入前端,沒有夠紮實的基礎的話,會比較難回答這些問題。

Q11. 給要去日本求職的人一些建議吧!

  1. 外語能力一定要夠強,如果真的要選一個就選英文吧!雖然學好日文也不錯,但目前的趨勢來說,學好英文的投資報酬率更高。所謂的外語能力不是光是證照而已,而是是否能善用這門語言來和日本人溝通。最大的門檻是英文,再來才是 JavaScript(一門熱門的程式語言) (笑)
  2. 技術背景要夠紮實,才不會被面試問題考倒。
  3. 如果有朋友也在日本的話,最好跟親朋好友諮詢一下日本目前的求職狀況

Q12. 有參加過日本的飲酒會嗎?分享一下經驗吧

當時日本當地同事邀請,因為離聚餐時間還早,我們先到場所 A 喝酒,再一起前往慶功宴。日本人工作時的氣氛跟飲酒會的日本人完全不同,落差很大,我第一次見識到檯面上跟檯面下的日本人差別,而且喝完後竟然還有不少人繼續約二次會(卡拉 OK,酒攤等等)。

本期人物專訪我們邀請到了軟體工程師 - scars,同時也透過他豐富的經驗認識了不少產業的觀察和 scars 與日本人合作的經驗,希望未來能看到更多 scars 在日本職場的分享,也請大家繼續關注日語八百屋!


Image for post
Image for post

現在已經有越來越多創作者,為了加速自己的製作流程,都會或多或少寫點程式來幫助自己優化。

這些創作者們非常清楚瓶頸在哪裡,而且因為他們想要花更多時間創作的慾望,這種動力和求知慾有時候會比工程師自我學習本身來得強烈,甚至可以比工程師更精準地找到解決方法。

看看文件、打個 API,完成一些簡單的應用跟日常工作,這些事情並不需要太大的工程能力,只要一些程式基礎就能輕鬆上手。

談談好和弦在前幾個禮拜的影片 — 上字幕吧。雖然跟音樂有點離題,但我很驚訝的是他願意把自己的想法轉化為行動的精神,甚至還把它傳到 github 給大家使用跟修改。

開源這件事情在軟體開發當中並不少見,多數的網頁應用或是軟體,或多或少都是利用別人已經做好的工具或框架上進行開發。除了別人可以把程式碼公佈出來之外,你也可以貢獻自己的力量進行修改。

這個功能很簡單,會寫程式的工程師們應該都可以在短時間做出來,但我會說更重要的是想法還有行動本身。

這個點子你想得到嗎?更不用說一看到程式碼就想重構跟 Over Engineering 的工程師們,做半天連功能都還做不出來。

而且如果仔細看一下程式碼,其實也沒有那麼難懂,頂多就是變數放在外面不是那麼好管理而已,但我覺得這些程式碼非常的直白簡潔,沒什麼複雜的抽象。

仔細看一下好和弦的頻道,你會發現他身上充滿了優秀工程師的特質,邏輯清晰、條理分明、熱愛分享、行動快速,就連在業界本身都是一件難能可貴的事了,更何況是跨領域。他用鋼琴打電話、解碼影片、用 google 翻譯寫了一首歌、寫了一個字幕產生器、五度圈,有些程式碼我猜可能連工程師們還不一定寫得出來。

其實學習一個領域,從而衍伸出來的一套學習方法,跟寫程式沒有太大的差別,所以你可以發現明明對方不是本科系,卻一樣可以在那麼短的時間內上手,掌握必要的知識,就是因為在其他領域的訓練。

我在前一份工作中親眼見證這件事。

創作者們花了大量的時間來產出作品,如果在業界生存下來,必然掌握了一套自己的法則與 know how。因為對方同時有另外一門領域的專業,所以可以更快看到解法或是問題的癥結點。

難道這就代表工程師從此喪失價值了嗎?當然不是。

這也讓我反思,身為一位工程師應該要怎樣在這種狀況下立足?

當我們跟創作者使用同一套程式語言、同個 Library,解決同樣的問題,人家雖然寫扣醜了點,但比你更有優勢找到問題和解決方案。身為一位工程師可以怎麼做?

我知道像是架構、工程化、高流量或是專業程度比較高的領域還是需要經驗跟專業累積,不過這倒也是很好的時機,可以好好思考一下在未來每個領域之間不再涇渭分明,每個人都可以同時有複數個技能與領域知識。

在這種情況下,如果要繼續往下走,我覺得可以從幾個角度切入:

  1. 紮實且深厚的計算機科學基礎
  2. 在除了程式本身以外的一個領域挖深挖廣
  3. 多接觸除了寫程式以外的事,行銷、產品、管理、溝通、自我經營。

這個現象反而可以去蕪存菁,一些沒有實力的草包工程師很快就會被比下去。

雖然創作者也開始寫程式是件好事,但是他們往往只是為了解決眼前的問題,而不一定知道原理或效能,這時候就是工程師的價值所在了,但我會說隨著電腦效能過剩,有時候這種價值也不一定可以彰顯出來。

另外就是比較困難的大型題目了,像是 GPS、大數據、機器學習、電腦視覺等等,光靠短暫的學習可能不夠,而是需要投注大量心力鑽研的知識,就是工程師們無可取代的地方。除此之外還有比較底層的知識,作業系統、萬年不變的資料結構與演算法等。

我相信除了好和弦之外,一定還有很多創作者都已經踏足程式領域,感覺會是個很有趣的現象,期待更多創作者分享他們學程式的心得。

5/17 更新

前幾天看到六指淵發佈的留言轉圖片的工具,覺得概念跟本篇文章的主旨類似,都是他們為了解決自己碰到的問題,進而採取行動改善,甚至回饋給大家使用。

這些都是難能可貴的事,也是我覺得工程師可以做到的事情,讓更多沒有經驗的人可以很輕鬆踏入這塊領域,進而改善他們的生活或工作效率。

在軟體開發中,開源的精神早已盛行許久,科技進步的現在寫程式也不是某群人專屬的技能,現在該是把這個精神傳播到更多領域的時候了。


Image for post
Image for post

前言

恩,簡單來講就是開始了一個 YouTube 頻道,就跟寫好了一個部落格很開心想要分享一下的感覺。

嘗試不同的呈現方式

在 2020 年,除了繼續深耕自己在程式這個領域之外,我也想透過另外一種方式來呈現自己有興趣的東西,本質上就跟寫部落格一樣,只是換個呈現手法而已,部落格當然還是會持續撰寫。

而拍影片這件事情對我來說更有挑戰性了,首先是對鏡頭的恐慌還有平時沒什麼在講話的習慣造成了明顯的冗言贅字、拍攝的節奏感、觀眾想要看什麼,這些都是光寫文章不會去考慮的事情(至少我是這樣啦)。

除了拍影片之外,另外學到的是剪影片,雖然不是特效型 YouTube,不過這種方式簡直是大幅提高了創作的可能性,而且也蠻好玩的。

我深信不管是文字、聲音或是影像,每一個傳播資訊的方式都有其獨特性存在,沒辦法互相取代,彼此各有優缺,影像剛好是我最近想嘗試的一個手段。

因為影片的特性,在傳播上會比純文章甚至是 Podcast 好一些,甚至可以透過 YouTube 的推薦機制跟渠道把影片推送給有興趣的人。

再來我有一些比較不好寫成文章的主題,或是寫成文章後比較難吸引到人的主題(樹莓派、Arduino、Sonic Pi 等),這些東西搭配影片跟實際操作,給人的印象比較強烈,也比較容易讓他們在看完的當下有所行動(吧)。當然等找到比較適合的呈現方式之後,或許也會開始 Podcast 也說不定。

我承認自己比較雜食,除了自己目前任職的領域之外,也會想往各個不同的領域探索,像是前面有提到的主題,然後發現越往底層走,能夠找到中文的資源也就越少,也越來越少人可以一起分享,所以我也希望透過這種方式呼朋引伴。

Be the change you want to see in the world

深耕專業之外,自我經營

比較有趣的是,因為 YouTube 本身也算是一個社群,任何經營社群需要的技巧,在 YouTube 也適用,這也是我在今年想要嘗試的事情 — Growth Hack。

YouTube 也一直是我很想嘗試的平台,雖然不知道成效如何,但工程師嘛,抱著 MVP 的精神先求有再求好也不錯。

走到一個階段,常常會發現,明明我有一個很好的 idea、寫得很完整的 side project,但為什麼都沒有人看到我。

這種感覺會很沮喪(至少對我來說),所以 YouTube 簡直就是一個活生生的練習場,會幫你計算各種數據,點閱率、觀看時長、曝光率等等,自己做的內容很容易就可以分析。

在台灣似乎還沒有發現像我這種取向的頻道(有的話歡迎丟給我知道),在前後端或許都有一些人在經營,但有些只針對部分領域,有些針對部分程式語言,有些只是丟上直播。相對沒有看到面向比較廣的 YouTube 頻道,也沒有剪片剪得那麼 YouTuber(自己講 XD)。

自己想做的內容 v.s 觀眾想看的內容

還有一個蠻有趣的話題就是,怎麼在觀眾想看的內容與自己想做的內容做取捨。我其實也在找答案,到現在也才上傳短短 6 部影片,還有很多路要走。

短期的目標是希望自己的內容被更多人看見,因為這樣子自己的東西才會有人看,也才會知道到底哪裡需要修正與改進。

另外與其抱怨大眾們都只看速食內容,我覺得可以換個角度去思考,去看看為什麼影片能夠爆紅,有哪些因素,再慢慢轉換到影片當中,我自己覺得只要表現的手法吸引人,就算是比較小眾的主題,還是能夠被注意到。

一般的工程師,如果要獲取資訊或是補足知識,通常不會透過 YouTube(除非是看 Conference),而是像是 Udacity、Coursera、Egghead 等等的線上平台,雖然我也想要做比較深入一點的內容,但如果這樣的話這個頻道就注定只能變成小眾頻道,就變得跟寫部落格差不多了。

一些體悟

我覺得如果同樣是想做 YouTube 的工程師,一定要有覺悟是,拍影片這件事情會讓你的效率大幅降低。

寫程式本來就是一件孤獨而安靜的事情,現在你要一邊寫程式一邊顧鏡頭、一邊跟觀眾互動、想腳本,比想像中累很多,而且我不知道大家有沒有這種經驗,寫程式寫太久之後突然忘記要怎麼講話。

而且最痛苦的就是剪影片了,剪下去就是 6 ~ 8 小時飛走。哎,還有好多事情要學啊 QQ。

試水溫階段感覺還有很多不足的地方,但如果對寫程式有興趣的話,記得訂閱看看~


初回の紹介

日語八百屋會在每個禮拜一時寄送 5 ~ 15 篇不等的文章,涵蓋的範圍有日本旅遊、日文學習、日本文化、動漫、日劇等等,但主要仍以日文學習為主軸。不管是日劇迷、動漫迷、語言學習者,都可以在本週刊找到適合的文章。
日語八百屋,源自日語的「八百屋」。除了「蔬菜店」的意思之外,也有「很多」的意思。學語言,多的是從微不足道的小事開始,50 音、文法、單字、敬語,最後內化成自己的事物,積跬步,成千里,最後逐漸變成自己的「八百」。

今週の話題

八百屋獻聲 — 飛機廣播練習

(連結為 mp4 檔)

之前曾經分享過關於練習聽力與口說的文章,還有之前提到的「回音法」幫助自己練習,這次試著錄一段飛機廣播的片段。最初在練習的時候最大的挫折是一連串的敬語連發,實際練習後才發現完全沒辦法順暢講出來。

實際把聲音錄下來之後,就可以知道自己哪裡需要改進了,持之以恆練習的話,相信效果一定相當顯著!

尾道一日散策

Image for post
Image for post

尾道已經成為我在日本最喜歡的街道,風景迷人,有著濃厚的下町氣息,也融合了些許現代元素。在尾道散步,徹底感受到のんびり的意境。

有咖啡廳可以休息、傳統錢湯改造的大和湯、還有搭船只要 5 分鐘的向島,染上夕陽的向島和波光粼粼瀨戶內海,怎麼拍都美到不像話。

如果想要來點不同的風景,沿著商店街走就可以到纜車處,到山頂上遠眺整個尾道與向島,還有充滿療癒文青氣息的貓之細道。

這一個散步路線足夠花上半天,如果想要再多品嚐尾道的氣息,可以租台腳踏車到向島走走,真的是會讓人拍照拍得不要不要的。

我覺得林芙美子寫下的文字,可以說是尾道的最佳註解:

「海が見えた、海が見える、5年振りに見る尾道の海は、なつかしい」

不管你是因為情傷、工作壓力、人生煩惱、厭世,想要找個地方遠離塵世喧囂,尾道絕對是個值得你造訪的小城市。

日本與武漢肺炎

Image for post
Image for post

這次武漢肺炎,日本政府的決策或許可以當作值得借鏡的反面教材。

反應的速度慢,沒辦法在初期就擬定好對策,導致日本病情不斷擴大;另外雖然在 1/28 就由內閣決議列為法定傳染病,但法規上缺拖延到 2/7 才執行,在防疫上有了一大缺口;口罩完全沒有管制的結果,導致各地都出現了口罩荒的狀況。

在日本也已經出現了類似群聚感染的現象,前幾天也出現了上班族在發病後仍然通勤上班,甚至最初醫生還拒絕檢驗肺炎的情形。(連結

層層壓榨的絕望工廠

在越南的勞工薪資偏低,所以為了改變家境,他們往往鋌而走險,選擇像是偷渡或是偽造文書的方式來到日本,努力工作只為了換取更好一點的生活條件。

不過就算是在日本,在物價昂貴的東京,靠打工賺取的微薄薪資,光是支撐自己在日本的生活就很辛苦了,更何況是匯錢給家裡。

許多弊端因此產生,留學代辦收取巨額手續費,透過偽造各種文書保證你可以拿到在留資格,但家庭也因此背上鉅額貸款;留學學校名不見經傳,以留學名義在日本做勞工,因為留學簽證有打工時數限制,所以他們往往直接靠現金交易躲避日本政府查緝,相對也少了許多保障;就算在日本被壓榨了,也因為貸款的關係不敢打道回府,這一連串的因果導致日本政府頭痛、這些勞工也是這個制度下的犧牲品。

偽造文書、偷渡這些都是犯法的事,但在如此極端的生活環境下,讓這些人做出鋌而走險的選擇;透過想要改變家境的新賺取暴利的公司,都是惡性循環中的推手。

就算是在看似光鮮亮麗的日本,也是有許多不為人知的血淚。

ランダムの話題

惡書追放運動

Image for post
Image for post

在街道散步的時候,意外看到一個有趣的標語 — 惡書追放

有種惡靈退散的感覺 XD在二戰後的嬰兒潮後,五十年代時這些嬰兒逐漸變成兒童,而當時也逐漸有各種兒童的漫畫雜誌流行,所以當時大家都愛看漫畫,也就有人把青少年犯罪、道德淪喪的原因歸咎到漫畫上面,因此有一連串的反對運動出現,叫做「惡書追放運動(あくしょついほううんどう)」。最後這個詞就被用來指「拒絕任何不良書刊」的意思。雖然說對於兒童來說,適度地保護他們閱讀的資訊是必要的,不過在社會風氣逐漸開放的年代,我們不應該把所有罪惡的源頭像獵女巫一樣,都怪罪到創作上。幸虧有日本發達的動漫文化,才得以解救廣大宅男宅女們的無奈夜晚。


這個 talk 比較多小細節,所以另外拆成一篇來寫。

Slack 的搜尋功能是使用 Armeria 開發的。

Armeria 是什麼?

Armeria 是由 LINE 開源的微服務框架,用 Java 撰寫。支援各種 protoco(thrift, gPRC, http),也有常見的微服務場景(circuit breaker、logging、retry 等),目前廣泛使用在 LINE 的各個服務當中。

Slack 搜尋架構 — 1

首先先來看看 Slack 搜尋最剛開始的架構:

  • MySQL 存資料
  • job queue 跟 worker 來 query solr 跟建立 index
Image for post
Image for post

這個架構很簡單,不過有幾個問題:

  • 隨著資料增加,搜尋效率不佳
  • 只有一台 Solr,也很容易有效能上的問題

Slack 搜尋架構 — 2

既然 slack 是以 team 在運作, 用 teamID 當作 Sharding key 似乎是個不錯的作法:

  • 但這樣也會有資料不平衡的問題,像大公司的訊息量還是大。Query 下來效能還是不佳。
Image for post
Image for post

Slack 搜尋架構 — 3

後來又改善了幾個部分:

  • 透過 ML(PHP)來做 Ranking
  • 加入 ELB 分散請求給 solr
  • 加入 Log Server
Image for post
Image for post

不過即使如此,還是有幾個問題:

  • ELB 沒辦法直接與 zookeeper 溝通,會隨機選一個 node 效果不佳
  • 服務越來越多了

這是後來演進的架構與各個服務間的通信方式:

Image for post
Image for post

從這張圖可以看到,幾個不同的協定 gRPC、Thrift over HTTP、HTTP 等等,在各個服務之間通信的成本會變高,也相對需要寫各種繁瑣的 client 連接設定。

於是 slack 希望可以改進整個架構,並且希望有幾個條件:

  • 可以支援 slack 中使用的工具如 ConsulZookeeper
  • 可以支援不同 protocol:可以看到這個架構中有許多不同的協定,migrate 也需要時間。
  • 好用,容易 scale。
  • 可以有比較好的 ML 支援。(語言上)

最後 slack 選擇了 Armeria。以下講者介紹一些 Armeria 的功能在 slack 搜尋的應用:

Logging

Image for post
Image for post
Image for post
Image for post

Blocking

Image for post
Image for post

整場看下來,覺得除了 Armeria 本身的介紹之外,更重要的是他們如何在框架之間做選擇,並且列出了條件跟希望達成的目標,來限縮他們尋找工具的範圍。

講者的介紹整個思路非常清晰,我們也可以看到 slack 的架構也並不是一步到位,而是隨著逐漸擴張的需求,選擇符合時宜的架構,才逐漸演變到現在這樣。

另外這場似乎沒有上傳簡報跟影片,所以只好用當時自己現場拍的幾張照片了。

Armeria: A Microservice Framework Well-suited Everywhere

這場講者介紹了 Armeria 這個微服務框架,以及使用起來大概是什麼樣子。雖然現在的微服務框架百花齊放,但 Armeria 值得一看的原因有幾個:

  • 各種微服務常見的場景都有:logging, retry, metric, circuit breaker, documentation, health check
  • 支援 Zookeeper 跟 Kafka
  • 支援多種協定:gRPC, Thrift, HTTP
  • 目前有 LINE 跟 Slack 兩個大公司都在使用

雖然因為 Armeria 相對新,社群似乎也還沒有那麼活躍,不過現在看起來 slack 與 LINE 都在使用,在穩定度上應該是可以信任的。

About

愷開

https://blog.kalan.dev 軟體工程師 / 在日工作中。平時喜歡用程式探索各種可能性,用網頁說故事、創造工具,邁向更好的生活。

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store