Skip to main content

Node.js 的發展

· 4 min read

2009 年推出的 Node.js [^1] 是讓 Javascript 成為一門廣為通用的程式語言的關鍵。Node.js 將原專為 Chrome [^2] 瀏覽器開發的 V8 引擎抽離出瀏覽器，讓使用者在一般命令行環境中就可以執行 Javascript。

開發者的需求​

要完成一個全功能的現代網站，開發者除了需要至少理解某門語言相關的網站後端技術之外，Javascript 也是身在 Web 開發領域的開發者至少必須 "略懂" 的腳本程式語言 (scripting language)。

既然不管精通哪門程式語言的開發者，想在瀏覽器上發揮，都仍需要某種程度地熟悉 Javascript 程式語言。那麼，如果在瀏覽器之外，也可以拿 Javascript 來做事情不是很好嗎？

Node.js​

Node.js 並不是第一款讓使用者在一般命令行環境中就可以執行 Javascript 的工具 (最早推出的可能是 Mozilla 的 Rhino 或 XULRunner [^3])，但它跟上了潮流。 2008 年推出的 Chrome 瀏覽器，裡面使用了同被 KDE 與 Apple 使用的 Webkit 作為渲染引擎 (Render)，並自行開發了全新的 Javascript 引擎 (V8 引擎)。Chrome 瀏覽器的 V8 引擎率先支援 JIT (Just in Time) 編譯技術，使得當年 Javascript 的執行效率一舉提升了 8 倍以上📈。基於 V8 引擎的 Node.js 也比其他 Javascript 運行環境有更強的競爭力。由於執行速度的改善，Javascript 語言終於有了和其他程式語言在瀏覽器之外的環境同場競技的實力。

Node.js 的好夥伴: NPM​

Node.js 推出當時，除了擁有一個比其他相似競爭者快上幾倍的引擎之外，在隔年整合的 NPM (Node Package Manager)[^4] 套件管理工具，讓 Javascript 開發者擁有了更有效率地分享與重用函式庫的方式。到了今天，下載大多數使用 Javascript 語言撰寫的專案，只要執行npm install(或衍生的yarn install)，NPM 就能自行安裝與解決套件之間的依賴關係。NPM 實是今日 Node.js 之所以能形成圍繞著 Javascript 語言建立起龐大生態系的不可或缺的功臣。

Node.js 衍生發展​

隨著 Node.js 更加成熟，Web 開發者也圍繞著 Node.js 重新發明他們常用的工具。最先是 Web 開發框架（如 Express.js [^5], hapi, koa）與資料庫接口，再來是相關的編譯工具（grunt, gulp, webpack [^6]）。同時，也有人開始嘗試將 Node.js 與原有的瀏覽器環境結合，讓開發者得以使用網頁相關技術打造桌面應用（nw.js, electron [^7])。基於此技術還發展了數個流行的程式編輯器（atom, Visual Studio Code [^8]）。時至今日，也可透過 Node.js 相關編譯工具，使用網頁相關技術來做行動裝置 App 開發（Cordova, React Native [^9]）。圍繞著 Node.js 的種種發明，讓使用網頁技術的開發者，得以從開發到部署，全都在圍繞網頁技術的生態系中完成。並由此誕生了稱之為 "Full Stack" 全端工程師（前端，後端，整合，測試）和大前端工程師的工作。全端工程師除了需處理網頁端（前端）頁面版型與互動效果外，也要兼顧伺服器端（後端）與資料庫處理。大前端工程師則是除了網頁端之外，也須兼顧行動裝置 App 的開發。

參考資料​

Current Progress of Netmonitor.html

· 5 min read

Update: Full instructions are avaiable on Netmonitor Readme to run the Network Monitor in the browser tab.

Firefox Devtools is in progress of modernizing its infrastructure to use the same toolset that modern web developers are familiar with. When talking about modern web developers toolset, I mean React, Redux, Immutablejs, and npm modules.😎

What Firefox Devtools team did last year​

Firefox Devtools was no different from Firefox itself. The Devtools panels are written in XUL, an HTML-like syntax language, and use several Firefox internal API called XPCOM or Chrome privileged API(Nothing related to Chrome Browser) to make the browser works.👽

In last year(2016), Firefox Devtools team's main goal is to convert the code base from XUL to pure HTML. The second goal is convert each tool with React/Redux structure for maintenance. Debugger, Inspector, Web Console are the first batch in the conversion progress. Debugger.html is the very first attempt from Firefox Devtools team to embrace the modern web developers' toolset. Now new Debugger and Web Console are available in Firefox Nightly🍸

Debugger.html, Perf.html(Performance) has their standalone repository hosted on Github. A developer could use git clone to get the repository, and then do yarn install, yarn start(similar to npm command) to debug the debugger.html/perf.html with any browser's devtools!🚅

What Run on the Browser tab means?​

Run on the Browser tab is a term versus Run inside of the developer panel. Traditionally Devtools are running inside of the browser's developer panel. But some of new Firefox Devtools support run as normal web pages. Those pages can be opened in a browser tab by any modern browser such as Chrome, Safari, or Edge. The benefit is we can improve Firefox Devtools with any Browser's Devtools, its an unfair advantage.🚀

We are going to make more Devtools easy to debug and can be used for cross-browser debugging.

Current Status​

To replacing the jet engine while still flying is a challenging engineering work. To make it happen, we take several engineering experiments around Devtools.

Here are the projects in progress and where they are hosted from:

What we have done in Netmonitor.html​

Ricky Chien and I joined the effort of convert Object Inspector from XUL to HTML. Object Inspector is a more complicated tool to convert, so Object Inspector is still half React and without Redux in the playground.

When the Object Inspector is fully converted to HTML, we shift our focus on convert the next important Devtool: Netmonitor. With Honza, Janda, Steve Chung, and other contributors' help, at the end of Feb we have reached our first phase tangible goal: Converted the whole Netmonitor panel from XUL to HTML, with React, Redux, and Immutablejs. Now we have confidence that the code base is easy to read and contribute.🤗

Imgur Picture: How current Netmonitor looks like

What we plan to do next​

We just finished the Netmonitor workweek (Fred, Honza, Ricky) in Taiwan, plenty of discussions have occurred, and we have good progress for what should be going on for the Netmonitor.

Here they are:

  • We’ve triaged all new Netmonitor bugs and identify good-first-bugs
  • We have Prove-Of-Concept branches to prove we can run netmonitor on the browser tab
  • We decide to keep using mozilla-central(The gecko) repo. Beside the current workflow, a developer would able to run yarn start command to debugging Netmonitor on the browser tab with any browser's devtool.
  • We stop Netmonitor.html phase I work immediately (convert XUL to HTML, MVP 100% completed)
  • We'll start Netmonitor.html phase II (To run Netmonitor on a browser tab so that we can debug Netmonitor with any browser's devtool)
    • All phase II bugs are filed in the Meta-bug

What could expect in the future​

Currently, Debugger.html have supported both Firefox and Chrome remote debugging protocols, so Debugger.html could be used to debug Firefox, Chrome, or even Node.js!😮

Since Debugger.html's pure web stack nature, you can imagine one day the debugger.html can be embedded into some editors(Atom, Visual Studio Code) as plugins, or even in other browsers!😇

Run with different remote debugging protocols is the next step once we make Netmonitor.html run on the browser tab.

如何修改 git commits

· 2 min read

與其他人合作🤝使用 git 版本控制系統時，為了讓最後合併（Merge）的 commit 好看，常常會需要調整自己的 commit。

同時修改一個 commit​

剛開始工作時一次只修改一個 commit，最常用到的命令是：

修改 commit 訊息 (message)​

git commit --amend

在 commit 後加入--amend(修正) 參數，可以修改最後一個 commit 的訊息。

將後續修改合併成一個 commit​

git rebase -i HEAD~2

將要合併的 commit 從pick改成s(squish) 後儲存，修改 commit 訊息後，可以得到剩下的一個 commit。

同時修改多個 commit​

到後來為了讓審查 (Review) 更容易，漸漸開始嘗試在遇到某些較複雜的問題時，在同一個 Branch 堆疊多個 commit 的開發方式。

假設手上有 3 個疊在一起的 commit (commit 1,commit 2,commit 3. commit 3 是最新的 commit), 這時在修改的過程中會遇到的主要問題， 就是現在的修改與最新的 commit (commit 3) 無關，但與最前面的 commit (commit 1) 相關。 這時若想要將現在的修改與之前的 commit 1 合併，原本常使用的git rebase就不是那麼好用了。

為前面 commit 的打補釘​

要為前面 commit 的打補釘，可以使用命令

git commit --fixup <commit>

<commmit>代表之前 commit (commit 1) 的 hash。輸入後最新的 commit 中會出現fixup <commit 1>的註記。

合併所有的補釘​

當一系列修改完成後，只要使用命令

git rebase -i --autosquash

儲存後可以得到干淨的 commit 1,2,3🤘

修改任何之前的 commit 訊息​

如果只想修改之前的 commit 訊息，可以用命令

git rebase -i HEAD~3

將pick改成reword，儲存後就可以修改訊息。

參考資料​

2017年，我的部落格改進了什麼?

· 2 min read

在去年改用 Hexo [^1] 架部落格後，由於用 Markdown 寫起來更方便了，又有 Mermaid [^2] 語法支援可以快速畫出一些流程圖，因此多寫了幾篇。

在此期間，也陸續為這個部落格加了一些小功能。主要有

  • 將 Hexo 預設的 Markdown 引擎換成 markdown-it，以支援顏文字 (emoji)[^9] 🎉
  • 加入類似 Medium 的文章預計閱讀時間 (每篇文章標題下方顯示 x min. read) ⏳
  • 支援腳注 (footnote)🔗，如下方的參考資料

為了折騰這些功能花了些時間，不知道這樣的投資能不能攤平到下個十年 :p

🔸以下是在改進部落格的過程中發現的一些小知識:

將 Hexo 預設的 Markdown 引擎換成 markdown-it 🎉​

為了要支援 emoji，在網上找到的做法是改用hexo-renderer-markdown-it[^3] 引擎並同時安裝markdown-it-emoji[^4] 最後必要的是在_config.yml 裡加入相應的markdown設定 [^5]

加入類似 Medium 的文章預計閱讀時間 ⏳​

原本我裝的是 hexo-reading-time[^6]，整合好後一看，所有中文文章的閱讀時長都短得可以，讓我懷疑它根本沒有支援中文字數計算。後來找一找，才拿可支援中文字數計算的hexo-wordcount[^7] 來替換掉。隨後又丟了個 PR [^8] 過去來調整預設的閱讀時長，最終才接近想要的效果。

參考資料 📓​

聊天機器人是怎麼運作的(I)

· 7 min read

聊天機器人（Chat bot）已存在許久，常見於各種即時通訊工具中。一般人最可能接觸到的，還是銀行的語音服務（Voice Response System）。

當我們打電話到銀行免付費專線，會有語音提示我們輸入驗證資料，然後輸入對應的數字來得到銀行服務。 只有在根據一串語音提示，輸入特定數字時才轉接到真人回應的專線。這個過程跟使用聊天機器人基本上是一樣的。

銀行的語音服務流程

行動裝置的完全普及​

近年來聊天機器人能重新進入公眾視線，主因還是行動裝置的完全普及： 幾乎所有的人都擁有一台智慧型手機。而且所有人的手機上都有一至數個聊天 App（LINE, Facebook Messenger, Wechat）。

邏輯思維 2017 年跨年演講 [^1] 裡提到，美國，中國想上網的人基本都已經能上網（上網人口已經接近飽和），人們每周平均花 24 小時上網，而這些數字都已經沒有太大的提升空間。因此所有的網路服務都得從有限的總量中搶占使用者的上網時間與關注。

換句話說，2016 年我們已正式進入行動網路（移動互連網）的下半場，廠商除了需要想方法佔用更多使用者上網時間之外，另一條路或是協助使用者更有效地利用上網的時間。

聊天 App 佔用使用者更多上網時間​

2016 年初的調查顯示，人們每天平均在手機和在電腦上所花的時間差不多。 隨著手機 App 的發展，人們能透過手機完成的事也越來越多。可以預見到的是人們每天花在手機上的時間佔比會再增加。 人們在手機上花費最多時間的是聊天 App 和社交 App。而今天的聊天 / 社交 App 都已內建網頁檢視（webview）功能。 看到「朋友」分享的新聞連結，點選後可以直接瀏覽內容，完全不需要另外再開啟瀏覽器來查看新聞。

由於聊天 App 佔用了使用者多數的時間，依照「使用者在哪，機會就在哪」的原則，聊天機器人，或是對話式界面 (Conversational UI) 成了一個選項。

Siri, 聊天機器人的濫觴​

這波新一代聊天機器人的濫觴，也許可以歸功於 2011 年蘋果推出的 Siri [^2]，雖然 Siri 並不存在於聊天 App 中。 iPhone 的使用者可以透過手機上的 Siri 智能助理應用，做到用口語詢問近期天氣，日程表，查詢地圖，餐廳，設定鬧鐘等行動，從而用更便利的方式取得服務。 雖然今天 Siri 與其他選擇相比，已盡顯不足之處，但當時 Siri 的推出，讓人們感知到與機器直接對話已不再遙不可及，這直接鼓勵了眾家廠商願意加大投入。

近幾年語音辨識，人工智能 AI 的爆發式進展，與此必然有著千絲萬縷的聯繫。

聊天機器人有什麼用？​

Reddit 曾有用戶提問，如果某個 1950 年代的人突然出現，最難向他解釋的現代事物是什麼？
最多人推的回答是： 「我擁有一部機器，就放在我的口袋裡，我可以用它來存取任何人類已知的知識。
我常用這個來看貓咪的圖片，還有跟陌生人筆戰。」
-- @wastemobile

就像现在手机 App 一样，大部分的 App 其实没什么用，用了只是消耗自己的时间。 但是像 Siri 所能做的，使用者透過聊天機器人簡化日常的瑣事，或是快速得到常見問題的答案。 Slack 平台上已有許多機器人，可以同步 Github Bug，同步代辦事項資訊，提醒今日任務等。這些 Bot 能省下使用者寶貴的線上時間。 我們更多需要的是這類型（用更便利的方式取得服務）的聊天機器人。

聊天機器人與使用者的互動方式​

在網際網路上，沒人知道你是一隻狗

聊天軟體原本的功用是讓使用者可以和「另一個使用者」或「一群使用者」交流。聊天機器人則是取代「另一個使用者」的角色 [^3]，讓使用者和「聊天機器人」一對一交流，或是讓聊天機器人加入群組，和「一群使用者」交流。

一對一

群組（多對多）

聊天機器人的應對方式​

除了「一對一」，「群組」（多對多）之外，依據聊天機器人的應對方式，還可以分為通知型（Notify），模式型（Pattern Matching），對話型（Context Aware）等幾種聊天機器人 [^4]。

通知型（Notify）​

通知型機器人會根據使用者「訂閱」的資訊，傳訊息通知使用者。例如明日天氣預報機器人可以定時告訴使用者明天氣象狀況與溫度，出門需不須要帶傘。 使用者一般不需要輸入任何訊息與機器人對話。

模式型（Pattern Matching）​

模式型機器人會比對使用者送出的訊息，如果符合機器人設定好的一些模式，就做出對應的回應。

例如使用者可以透過天氣機器人，輸入 "weather in Taipei" 查詢當前台北的天氣。

基本的模式型機器人沒有對話的概念，並不會根據使用者過去的應對而改變回應的結果。 例如使用天氣機器人時每次都需要指定想查詢的地點，或是透過預先設定地點 / 偏好溫度格式來簡化使用方式。

除了傳統使用正則表達式 (Regex) 來比對模式外，Facebook Messenger bot 則提供更接近口語的自然語言處理（Nature language Processing）模式比對。 多數聊天機器人框架目前都仍偏向模式型。

對話型（Context Aware）​

對話型機器人會從與使用者過去的對話中提取使用者的偏好，並運用到後續的對話中。

例如 Google Assistant 會根據你之前的查詢，去進一步找到你想听的音樂。

能理解與使用者過去的對話，也是對話型人工智能的重要特徵。當使用者在聊天軟體中新加入一個 bot 服務，使用者與這個服務的對話都與和一般服務員的交談無異，那麼服務的後面是不是真人還重要嗎？

參考資料​