跳到主要內容

技術轉換需知,學習 Node.js 的前期準備

image


技術轉換需知,學習 Node.js 的前期準備


持續推廣 node.js 對於新手教學上,通常會遇到許多狀況,以及許多不同的迷思,總和出來其實可以看到一些常見的問題。
這篇文章也是藉由數次的活動發想實踐當中,延伸出來的導讀文章之一,也是每次在活動一開始的時候,就會跟大家介紹的這門技術的一個初探介紹部分。

學習之前,先學會忘記

就像是所有武功絕學一樣,要學一門武功,一個新的技術,首先你需要改變自己的既有思想,這實際上真的很難,但就對於自己來說,也很有多既有概念,框架其實是無法捨棄,但是既然決定學習一件新事物,那勢必就是要改變。
對於已經有學習過一些程式編輯,或者一些程式框架的開發者,建議一開始學習 node.js 的朋友,先忘記掉所有你學過的語言,以及開發方式,試著忘記既有框架的狀況下,去學習這門技術。
在沒有既定框架下,不去過分討論,比較任何語言上的差異,而是先從他的背後歷史意義,演進接著再瞭解近期的改變以及未來規劃等。
以 Node.js 來說,在 2009 年,給與的示範就是一個聊天室,也表現提高 high concurrency 的實做,在當時定爲爲處理高承載量的新語言新服務,透過 JavaScript 實踐出來的結果。
到了 2012, 2013 年開始, Node.js 朝向不同環境中,透過許多公司投入全職開發者,將 Node.js 發佈到不同平臺上,同時依靠社群的力量,開始有極具的成長,也帶來不同的聲量。
最近的趨勢是開始走向, Node.js 嘗試解決分散式系統架構,以及直接嵌入式系統中,所以意味着開始有許多不同的發展,也有發展出不同於 Web 的應用。

JavaScript 並不是 bala, bala, bala …

講了許多過去歷史,雖然說大家已經開始試著要去忘記以往框架這件事情,但是我相信一開始還是做不到,這真的很難,但是請務必嘗試著,至少試著親手輸入每次的程式碼以及每次的相關測試,哪怕只是 hello world,跟着一起從頭開始進行所有流程。
在開宗明義上,根大家說,Node.js 其實就是在寫 JavaScript ,拋棄以往對於所有瀏覽器上的謬誤,以及對於所謂 IE 或者其他瀏覽器上面可能發生的錯誤。現在開始所有的事情都發生在背後,全部的事情都是在伺服器裏面進行。
所以可以說是,Node.js 程式編輯,其實是使用 JavaScript 爲基礎,透過 Google V8 engine (JavaScript interpreter) 進行後端程式的編譯。

非同步 ASYNC & 同步 SYNC

在以往的程式開發,一般的教育上我們都跟所有人講說, synchronization 序列化的程式開發,意思就是每個程式都是序列化進行,每個程式都是一步一步的慢慢進行。
在開始 Node.js 之前,接觸程式之前執行任何範例之前,我們必須記住在 Node.js 裏面,所有的東西都是非同步化,這也意味著其實你無法預測程式什麼時候會結束。
雖然聽起來有點怪異,不過這的確比較像是真實世界正在發生的狀況,最常舉的例子就像是準備早餐,當一開始準備早餐的時候,其實就是一個 process ,一開始我們需要準備煎蛋,準備咖啡,準備麵包。
如果使用 sync 的方式進行,我們的進行程序會變成
/*
1. 先開始煎蛋,直到蛋煎好了
2. 開始泡咖啡,直到咖啡煮開了
3. 開始烤麵包,直到麵包完成
*/

getEgg();
getCoffee();
getBread();
序列化的方式增加我們的準備時間,整個準備時間開始大幅增加,因爲每個執行序列都是一個一個完成後才開始執行。
可是在現實世界裏面,我們會怎麼做?
* 開始煎蛋(做好了,再取蛋)
* 開始泡咖啡(泡好了,再拿咖啡)
* 開始烤麵包(做好了,再拿麵包)

var cook = require("cook");

cook.getEgg(function (egg) {
    return egg;
});

cook.getCoffee(function (coffee) {
    return egg;
});

cook.getBread(function (bread) {
    return egg;
});
在執行 async process 當下,我們就直接進行了所有的事情,執行了所有方法一開始我們就並行了所有的程式,並不是一個一個等待,而真正完成時間我們並不知道,我們知道的是,這些事情其實都是同時並進。
所以程式並不是一個等待一個,一個等待一個,而是一次性的併發出來,觸發之後再進行通知動作。

Callback 程式藝術

剛剛提到的 Async,肯定要提到的就是 callback 這個特性,所有的流程處理都是在 callback 裏面所進行,這聽起來有點難懂,大部分的人也搞不清楚到底是怎麽一回事。
最長舉的例子就是直接啓動一個新的服務器。
var server = require("http");
var fs = require("fs");

server.createServer(function (req, res){

  res.end(content);


}).listen(3000);

console.log("start server");
特別要說明的部分就是,大部分的程式都是採用類似的方式執行,注意 createServer 這個部分,裏面的匿名函式雖然宣告,但是並不是直接觸發,而是等到當有使用者登入伺服器的時候才會觸發這個事件。
這也是通用的 callback 寫法,大部分的處理都是如此,就只要先記住這種寫作的感覺。
所以這也意味著,雖然 Node.js 是單一 Process 的程式,實際上可以透過 callback / event driven 機制達到類似像 mulit-thread。

爲何要學習 Node.js ,優勢?

最後是給所有對於 Node.js 質疑的人,Node.js 從 2009 年宣告之後,被發展到今天的狀況,透過 open source 的力量,加上許多企業全力的合作,已經把 Node.js 這個程式形成一股無法動搖的力量,也成爲這些企業的基礎建設之一。
就實際上來說,我們可以說 Node.js 可以透過程式開發來瞭解到平行化處理的流程,同步化處理的效益,因爲使用 event-driven 的特性,加上 v8 engine 的效能,因此 Node.js 在相同機器底下能夠支撐的 concurrency 會提高許多,所以對於開發高併發,高承載量的服務器其實是很有幫助的。
雖然說這對於開發成本上是比較高的,但另外一方面,這也是對於前端開發者的一個優勢,因爲沒有人比前端還要瞭解 JavaScript 特性,目前來說大部分真正瞭解 JavaScript 特性的就是前端開發者,也表示你們可以親眼見證轉職的可能性與機會。

後續討論

大部分的人都會問,對於目前的項目有沒有可以建議的 FRAMEWORK ,或者問現在是否適合改變到 Node.js 進行改寫。首先這個問題,沒有絕對的答案,但是先問自己,
  • 目前這個網站運作,有需要提高高承載量的需求?
  • 允許多久時間進行網站改寫,能否接受至少一個月沒有任何新進度?
如果以上答案都是 Y ,那答案就在各位心中。
在最近幾年其實 Node.js 已經有許多更多不同的變形,例如透過 node-webkit 可以進行 GUI 程式開發,透過 johnny-five 可以將 js 程式直接執行在 aduino 上面。甚至目前也有許多 robots 可以用 Node.js 進行程式開發。有人聽過 JavaScript 也可以寫音樂嗎?
因爲這些種種,我們必須承認 Node.js 的確對於 JavaScript 這門語言帶來巨大的震撼與改變。今年度 JSDC 2014 ,我們也特別規劃許多對於企業端,開發,JavaScript 最新流行趨勢的方向邀請各國講者來到臺灣。最精彩所有 JavaScript 頂尖技術全部都在 JSDC 2014

留言

這個網誌中的熱門文章

[分享] 腳踏車環島注意事項

很多人都期望自己能夠做點什麼,做些什麼,而退伍之後的第二個星期,就展開了環島之旅。

對很多人來說這不算什麼,甚至有人展開了走路、跑步、溜滑板、單輪車等方式環島一周,充分展現對台灣的愛與關懷。

這篇主要讓不知道怎麼準備環島的人,作一個完善的解說,首先隨身的東西要有:

證件現金類
身份證健保卡學生證現金提款卡悠遊卡

館長的網站技術瓶頸,小弟弟來解答 - notorious-2019.com

館長的網站技術瓶頸,小弟弟來解答 - notorious-2019.com昨天看到館長的網站倒了,也看到館長說一個月花費大概一百萬左右的月費在支持這個架設的電商網站,也對外發布出來訊息,希望求救,直接講結論建議解法,1. 首先要做的事情是讓整個網站可以橫向擴展 (Load Balancer + n 台伺服器),對,相信我,IIS 也是可以做 Scale out, 這是對於 Application layer 服務的解法。2. 資料的部分 SQL 吞吐量,建議改成 GCP Cloud SQL, 或者就直接轉到 Azure SQL Server 環境上會相對容易解決 SQL 的問題。上述 2 個步驟都處理完,其實 100 萬的費用,應該 20000 concurrent user 是沒有問題的,但前提是要設定『對』!額外需要花較長期時間要處理的,建議就是在 Queue 的處理,購物車的狀態都可以進入到 Queue 再來處理 SQL insert 的問題,減少不斷的 insert / update 的狀態,後文會提到 ...底下詳細的會再說明如何後後續還有哪些處理的細節。這兩天剛好有個小空擋,就來分析一下狀況,可以從外部讀取得到的服務大致上如下,ASP.Net: 4.0IIS 10 + Windows (廢話)SQL Server (推測)OP Service: PleskWinHost: Google CloudDNS: Cloudflare前端服務內容架構Server-side render, jQuery base, 推測有可能採用現成購物車來進行,看起來不太像是用 wooCommerce 比較像是 Cart Functionality 這類的項目直接搭建而成(當然這純屬猜測)功能拆解因為網站是透過 Server site render 所有頁面都需要重新透過伺服器進行載入,這樣的狀況,如果在頻繁忙碌的 eCommerce 網站架構下會是一個致命傷,簡單來說,數量的查詢,特惠價,優惠碼等等資訊的處理,使用者每做一步都需要重新跳轉頁面,或者整頁面重新讀取,只是為了部分的資料更新,這些都可以抽取出來成為 API ,透過 AJAX 的方式進行讀取。讀寫分離在不了解目前資料庫複雜狀態下,首先要讓所有人都可以讀取到資料,頁面可以跑出來,建議至少將讀取資料庫,和寫入資料庫的…

Scrum management tool 敏捷開發工具概觀介紹

Scrum management 工具概觀介紹
會有這個念頭興起主要也是因為這幾個月內,是在公司內部訓練透過 Teddy 老師 Scrum 課程了解整個 Scrum 的流程,開始進行團隊的 Scrum 流程導入。

在過年春節期間去嘗試市面上的 Scrum 管理軟體,也透過眾多大大得到解答

這邊就不詳細討論怎麼進行 Scrum 的軟體開發,而是在於管理機制,就整個流程上,對於自己需要的項目有,
SprintUser Story (Backlog)Task management task time countertask assigneeburndown chart 以上這幾個是在 Scrum 流程裡面最基本的需求以及解法,而根據大量搜尋結果,也找到許多不同平台,以下為個人分析經驗,
trello.comhttps://trello.com/ 一開始很直覺的就會採用到 Trello ,而經過測試後,如果直接的使用 trello 是沒有辦法達到以上的所有方法,必須要結合,scrum for trello ,所以也表示如果你的電腦沒有安裝 Chrome的話,勢必就是 GG
的確這是一個假命題,身為一個開發者,或者前端人員怎麼可能沒有 Chrome ,(也許真的沒有),不過比較麻煩的是,雖然 trello 加上套件後可以管理 Task, time counter, burndown chart 都有支援,但是通常一個 Sprint 會有兩到三個 User Story ,所以對於 task 橫向管理對應 User Story 是比較麻煩的。
taiga.iohttps://taiga.io/ Taiga 也是許多人推薦的一套管理系統,就整體表現以及流程上,的確沒有像是 trello 這麼順暢,不過從另外一個方面來看,他是完全 open source ,而且可以 self host 這點來說,的確是非常適合用於自己的敏捷專案管理上,這點的確可以說是開源軟體的轟炸機。

不過就回到 Scrum 管理層面來說,畢竟人家 taiga 開宗明義就說了,流程上是符合于 kanban ,所以缺少了 task time counter 的部份,也沒有 User story 管理。所以回到 Scrum 本身,Taiga 就並不是這麼適合。
blossom.iohttps://www.blo…