2013年5月4日星期六

開發者轉換到 node.js 開發方向 - Node.js for php develpers PHP

0 意見

Node.js for php develpers

從某一種語言跳到另外一種語言,通常來說痛感應該是不會太大,只要有些觀念釐清即可,畢竟每種語言存在都是有某些特別的道理,或者是有他的歷史存在意義,所以語言的對戰比較之類的事情,我對於這種事情通常是一笑至之。有時間去吵那些莫名其妙的事情,倒不如發揮自己所長,好好將產品快速產出,這才是『實現的王道』

話說回來,前面談到前端開發者來說 JavaScript 是一個很棒的利基點,也是一個很好出發點,轉向到後端開發當中。那是否意味著其他語言開發者就沒有相對的機會呢?

就個人在其他語言上琢磨並沒有這麼多, PHP 倒是寫過不少年,因此我從 PHP 開發者的角色來檢視一下,有哪些觀念需要被改變,需要被調整。

Node.js 是一個整體的服務 / 語言

對於 php 開發者來說,一開始的環境就是要先開始架設 Apache / Nginx,接著使用 cgi 的方式來起動 php ,當然在 linux 底下的話,直接使用套件管理,直接進行安裝會是更為方便。

apt-get install php apache

但是在 node.js 裡面,node 本身就是一個服務,不需要其他相關的程式進行啟動, node 本身就可以是一個後端的服務,或者一個 web service ,更或者是一個 command line 的進行,所以 node.js 是不需要任何相依設定。

也因為如此,所以許多 apache 幫你處理掉的事情,在 node 裡面都需要自己處理,這件事情聽起來或許很煩,事實上也是如此,開發 php 的時候許多事情 apache 都已經幫你處理完的事情,node.js 在 web 上,前面的所有開發都需要自己來,這是一個很大的不同,你需要稍微了解一下之前 apache 到底幫 php 做了哪些事情,接下來開發 node.js 才能夠了解,為什麼他要做這些事情。

Node.js 每個檔案都是獨立的 Class

node.js 每一個檔案都可以視為獨立的 Class ,這跟我們之前所認知的 JavaScript 似乎有很大的不同,JavaScript 本身都是採用 fuction call ,變數宣告也很容易互相影響,可是因為 Node.js 採用 CommonJS 標準,因此在每個程式裡面,變數都不會互相影響,每個檔案內的變數都是獨立的。

開發 php 的時候很經常會使用到 require,而 php 將會把這個檔案讀取進來,當然變數也會連帶的影響到,可能 a.php 的變數會出現在 b.php 裡面,這都是時常發生的事情。
a.php
<?php
$hello = 'abc';
?>

b.php
<?php
$hello = 'world';
?>

main.php
<?php
require('a.php');
require('b.php');
echo $hello;
// print 'world'
?>

範例如上面,當我們執行 main.php ,就會得到 world 這個資訊,可見 a.php, b.php 兩者的變數會互相干擾,同時 main.php 可以直接讀取已經宣告過的變數,這在多數的 php 開發者都有深刻的經驗,當然這也是一個特性,開發 php 的時候這個特性,是個很方便的東西。
在 node.js 開發裡面卻不是這麼回事,每個檔案都是獨立的 class,的程式都有不同的東西。

a.js
exports.hello = 'abc';

b.js
exports.hello = 'world';

main.js
a = require('./a.js');
b = require('./b.js');
console.log(a.hello);
// print 'abc'
console.log(b.hello);
// print 'world'

從上面的範例來看,在 node.js 開發上的確與 php 有許多不同,尤其是變數宣告處理上,更是不一樣的架構,這樣的好處 node 不會有變數互相打架的狀況發生,當然麻煩的部份也是,無法共用變數,思維上的確與 php 原有的宣告思維上有許多不同。

Node.js 的套件都存在於 NPM 上

php 開發的時候大多數時間我們的環境都已經把所有需要的套件安裝上去了,或者是需要憑靠著經驗,從 log 中查看到底還缺少哪些套件,當然 php 之前有 pear 這樣的東西可以進行套件安裝,不過對於 pear 的社群維護度來說,通常我還是在一開始架設 apache 的時候就先把所有的套件全部設定完畢。

在 node.js 裡面,套件相依性,以及套件管理是很重要的一環, npm 就是如此的東西,可以透過 npm 進行 node.js 套件的安裝,例如我們常用的 express

npm install express@2.5.8

可以透過指令去尋找,安裝,解除,更可以透過指令來指定版本號碼,特別是每個 node.js 專案幾乎都需要重新安裝一次套件,這個部分對於 php 開發者是覺得神奇,而且浪費空間的事情。

不過仔細想想,開發專案,在不同時期,不同時間點,我們需要的 module 可能也會不同,因此在每個專案裡面安裝套件似乎又如此的合情合理,當然還是必須要說,這樣子是真的比較佔用空間,不過又如何,目前的硬碟這麼大,對於開發者來說,裝 code 的空間佔用多少?

因此每個 php 開發者轉移到 node.js 時候,需要去了解、熟悉 npm 這個指令。

Node.js 的 package.json 設定是必要的

如上面所提到,每個 node.js 專案都是需要去被執行 npm ,進行相依模組的安裝。接下來你將開發許多不同的 node.js 專案,請先做好相依模組記錄的習慣,在每個專案目錄底下設定 package.json ,設定好版本號。

cd project_name
npm install

接著開發、維護的成員,可以不用再去猜測之前的模組為哪個版本,直接透過你之前設定的 package.json ,透過 npm 進行快速的安裝,立即進入開發的行列之中。

Node.js 是 Event driven I/O 處理

對於 php 開發者來說,開發程式的習慣就是很直覺性的 debug,設定 break point ,觀看 log 跳到的地點,程式的執行是依序的,由上往下依序執行,以前我們的老師也都是這樣子教導我們的,程式的確也是這樣看的,

$my_file = 'file1.txt';
$handle = fopen($my_file, 'r');
$data = fread($handle,filesize($my_file));

$my_file = 'file2.txt';
$handle = fopen($my_file, 'r');
$data = fread($handle,filesize($my_file));

但是,在 node.js 開發裡面,事情似乎變得不一樣,我們的開發寫法開始有了許多改變,event-driven 是一個很強的衝擊,許多的東西都使用 callback 都使用匿名函式來銜接,當然連同裡面的變數也是如此,而這些變數的來源,通常都要去參考 nodejs.org/api 的部份,事情是需要不斷的在 callback 裡面慢慢被完成,這的確很奇怪,也的確很神奇,

var fs = require('fs');
var my_file = 'file1.txt';
var data;

fs.readFile(my_file, 'utf8', function (err, data) {
    data += this.data;
    my_file = 'file2.txt';
    fs.readFile(my_file, 'utf8', function (err, data) {
        data += this.data;
    });
});

如同之前的 php 程式,讀取兩個不同檔案的程式架構卻全然不同,在 node.js 裡面許多程式都是以非同步的方式執行,你無法依照以前排序的方式進行開發,當然程式的執行順序也不會如你所願,如果希望讀取檔案完成之後,進行另外一個檔案的讀取,那就只能進去 callback 裡面,進行另外一段程式的進行。

聽起來似乎非常奇怪,不過這就是 JavaScript ,這就是 node.js ,這是他獨特之處,如果希望開發 node.js 就請習慣這種風格,也請習慣 event-driven 的方式。程式只會等到被執行的時間點才會進行,程式執行的時間並不會依序進行。

後記

就在你看這篇文章的時候,表示你對於 node.js 應該是有聽過,或者是有想要進入這個領域,想看看 node.js 到底要怎麼開發,當然這是一個好的開始,表示你期待改變。

這邊很尊重你想要改變的心情,如果你是要拿來測試新的專案、新的服務、甚至於公司目前有改造計畫,這是一個不錯的發想開始。不過,如果你的程式已經有了許多基礎建設、許多歷史的累積,這邊不建議妳採用新的語言進行開發,也不建議妳整個重新打掉這個『正在運作的服務』。

node.js 是不是很不穩定? node.js 是不是適用於我的開發架構? node.js 到底能不能開發大型架構? 如果有開發者問我這樣的問題,我通常會回答他,先使用 node.js 想辦法建立一個 todo list, 留言板之類的簡單網站,之後,我們再來討論。

程式語言只是一種實現的工具,每個階段都會有不斷的程式架構調整,程式只有更好,沒有最好,不斷的調教,不斷的改善,當每段程式上線我們舉杯慶祝的同時,下一秒,開發人員又回到座位上繼續進行下一個里程碑,『程式只有更好,沒有最好』

本文章同步轉載於:

2013年4月24日星期三

[閒聊] socket.io scaling out solution

1 意見

socket.io scaling out solution

socket.io 一直以來都是在 node.js 許多 module 當中,受人注目的一個項目,自己也不例外,從 socket.io 6 進展到目前 socket.io 9 都一直持續關注他的發展。
長期以來這種 Comet 連線模式的環境,最讓人質疑的部份有幾個,
  1. server extend (scaling issue)
  2. message lost *. user connection
首先拿 server exetend 來說,最簡單的解法,同時也是 socket.io 支援的模式,
  1. 設定 socket.io redis config
  2. 使用 load balancer like 的機制
  3. 將 socket.io 服務視為一個 Application
因此就可以如下圖,所表示



http://blog.davidmisshula.com/images/4.png

使用者透過連線到 load balancer 之後,透過 load balaner 將資源分散到每個不同的 Application 機器,每個機器最終將會去向同一個 DB (SQL/ NoSql) 機器取得 session, user, message … 資訊回到應用程式當中。
讓每個使用者的資訊不致於斷線,在這邊 socket.io 預設的使用方式就是採用 redis。
這種連線方式其實有幾篇文章已經說明的相當清楚,
這邊的方式都是採用如同上述表示的規劃架構,可以達到 socket.io scaling 的機制。
當然聰明的各位也想到了,有需求就會有解決方案,因此也有廠商提供了類似的解決方案,
這兩間廠商都是提供 real time web service 給予 Web App provider ,當然這是一件好事情,對於開發者來說正是這個 provider。

可是其中有個問題就是,對於開發者來說這些服務都需要先熟悉他的 API 以及架構,假設…如果今天這個服務商倒了,或者使用者變少之後,那是不是就又成了另外一個科技孤兒。
當然我相信這是一種 trade-off ,對於開發者及廠商都是,話說回來如果我們今天針對的目標族群是 Node.js 開發者,那情況是不是又不太一樣。

針對 Socket.io 開發者


如果是 Node.js 開發者,族群上是針對 socket.io 開發者的話,似乎又有另外一個新的選擇。
沒錯,就在本月份 Widnows Azure(沒錯,就是你知道的那個微軟),目前也提供了類似的服務稱為 Windows Azure service bus,
http://ntotten.com/2013/04/05/scaling-out-socket-io-with-windows-azure-service-bus/
文章中提到了,如何去 scale out socket.io 服務,當做自己的後端服務。

how you can scale out Socket.IO to multiple servers in order to handle many simultaneous connections by using Windows Azure Service Bus as a backing store.

總之這是目前 real time service 當中,少數一個以 socket.io API 為基礎的一個服務(當然之後會不會偷改,我不曉得),不過對於長期關注 Socket.io 的開發者來說,是一個優勢。

從此之後我不需要再持續去注意 socket.io scale out 的問題,只需要去關注 deploy 的問題。

實際情況?

實際上,卻好像不是這麼簡單,如果真的要做到一個 real time service 實際上,對於服務背後幫你做的事情,身為一個開發者還是要可以知道後面的 log 狀況。

message lost

目前線上到底有多少 session connect 有哪些已經 fail, 哪些還是 alive ,這些都是需要被關注,而且需要可以查看 log 的部份。

如果真的要確保訊息都有被完善的發送到每個使用者手上,似乎 Queue 的機制也不得不製作,讓每個訊息不管是針對特定使用者,或者是廣播訊息都能夠使用 queue (例如 rabbitMQ, ZeroMQ),能夠確保訊息的傳遞,以及 log 的檢視。

似乎這樣的服務才足以讓開發者有十分強度的信任,不需要自己建立自己的服務,將整個 Web App 移植到某個 Service Provider。

對於開發者

其實親善開發者真的不難,要做到的就是幾個
  1. 統一的介面(API)
  2. 足夠的訊息回顧(Log)
  3. 穩定的網路
  4. 開源的程式
這四點,每個其實都打到許多廠商的要害,總之說很簡單,做很難,但是不論怎樣,做就對了,我們知道距離目標還有千萬公里遠,但是一步一腳印,就慢慢把步伐向前邁進吧!

註記:
此文同步轉載於,http://blogger.micloud.tw/2013/04/socketio-scaling-out-solution.html

2013年4月4日星期四

[推薦] JavaScript 前後端學習書籍

0 意見
JS 道現在已經變成一種顯學,從以前不太重要的瀏覽器端,到現在從瀏覽器(瀏覽器也只能夠使用 JavaScript 執行),到後端程式語言 Node.js ,甚至是 mobile 上都可以使用 JS 進行程式開發,因此這個語言變得越來越重要,也越來越為更多人重視。

身為網站開發者,是需要好好學習一下這個語言的奧祕,

首先從瀏覽器端,一開始對於我自己所困擾的是什麼是 AJAX,翻遍許多書籍之後,終於找到一本比較能讓自己所了解的,

前端部分:

[IMG]http://i.imgur.com/RobJpDt.jpg[/IMG]
Bulletproof Ajax

這本書裡面講解 AJAX 如何與伺服器互動,同時講解瀏覽器到底 DOM 是什麼東西, DOM 如何運作,到最後面漸增強的部份都有做簡單的講解,十分適合初學者入門學習。

當然這本只是概念,如果需要更深的層次,每個名次都有一本專門的書可以提供參考,會推薦 Bulletproof Ajax 給初學者,也是因為他的輕薄,試著從這種簡單的書,開始進入 AJAX 的世界。

[IMG]http://i.imgur.com/gXSJOfC.jpg[/IMG]
JavaScript for web developers

當開始對於瀏覽器,DOM,ajax 有了基本概念之後,接著可以試著看這本 JavaScript for web developers ,這本書相對前一本就厚重許多,裡面從 JS 的每個屬性開始講解,到 funciton, closuure, timer 等一一解釋,甚至於瀏覽器中的事件(Evetn) 都有相當詳細的說明,裡面解釋了許多 JavaScript 在瀏覽器執行時,可能會發生的問題以及避免方式。

當真正深入開發產品的時候,可以從這本書籍裡面,避免掉許多細節問題。

[IMG]http://i.imgur.com/dPVTj1R.jpg[/IMG]
JavaScript good parts

這本書籍並不分前後端,只要是寫 JavaScript 的人,過一段時間都可以重新回味一下 JavaScript Good Parts,裡面提供了對於 JS 的見解,對於自己開發的 naming, conviention, logic 這些問題處理上,偶而重新翻一下此書籍,都會有新的體認。

JavaScript good parts 這本書,推薦給已經開發 JS 一段時間的朋友,可以當閒來無事的時候,或者睡前的床頭書籍(至少我是如此)

後端部分:

因為後端程式相關書籍還是比較少,因此推薦幾本給大家,

[IMG]http://i.imgur.com/k3gzCjW.jpg[/IMG]
Learning Node

這本書是目前覺得少數幾本寫 Node.js 最扎實的教學書籍, Learngin NODE 當然一開始從安裝開始說起,之後提到 REPL 的觀念,甚至後面的 module, flow control, testable 都講解的十分恰當,如果你已經是開發過前端 web 的朋友,想要試試看不同挑戰,這本 Learning Book 推薦給大家。

[IMG]http://i.imgur.com/bkOENxe.png[/IMG]
Node.js 台灣社群協作電子書

這本書籍,由 Node.js Taiwan 社群的朋友一起彙編,裡面從基礎安裝,到個別模組教學,更至於是範例程式都有詳細的說明,這本書推薦給想要學習 Node.js 的朋友,可以透過此書,學習怎麼進入 Node.js 的程式開發,特別是透過範例,進行簡單的修改,就可以完成自己的第一個 Node.js 網站開發。

更特別的部分是,這本書籍完全免費,希望聽到大家的回饋,讓學習 Node.js 變得更為簡單,讓技術變成 0 門檻,如果有興趣,歡迎到這個網站,瀏覽此書籍。

http://book.nodejs.tw/

後記:

以上書籍,是自己的學習歷程,也是從眾多書籍中歸納出來,覺得適合分享給初學者,進入網站開發的 js 入門書籍,如果各位有更好的書籍,歡迎一起來分享



2013年3月22日星期五

[教學] 你所不知道的 ssh 連線方式

0 意見

[教學] 你所不知道的 ssh 連線方式



最近因為準備 KSDG 課程活動,重新看一次 Paul Irish on Web Application Development Workflow ,裡面發現了些好玩的東西,特別是 ssh 的部份,通常每次我們連線到某台機器,都需要一直 ssh 進去之後,開始輸入密碼,



大家經常忍受這件事情,可是時間長久下來,會變成一個沈重的負擔,建議大家把自己的 publis key 放置於遠端機器的路徑下,

產生 public key

建置部分,首先在自己的機器裡面輸入,

ssh-keygen -t rsa
[enter your password]
[enter your password]

之後輸入

cat ~/.ssh/id_rsa.pub

會出現一大堆奇怪的字串,複製它

連線到遠端機器

接著進入到遠端機器裡面,到底下路徑中,

vi ~/.ssh/authorized_keys

將剛才複製的字串貼上,儲存後離開,

測試連線

回到自己的本機,測試連線是不是能夠,恭喜完成以上步驟,之後就不用再輸入密碼了。
ssh user@ip.ip.ip.ip

alias machine setting

可是還是有個問題,就是每次 ssh 還是要輸入一長串的使用者名稱,ip 位置,在 .ssh 裡面可以提供簡單的 alias 設定,
在自己的本機內,編輯檔案路徑為

vi ~/.ssh/config

修改內容

Host [alias name]
    HostName [remote ip || domain name]
    User [login user name]
    IdentityFile [identity file path(option)]

範例可以參考如下,

Host demo
    HostName 213.80.200.1
    Port 22
    User caesar

之後將檔案儲存,離開,接著進行指令測試,

ssh demo




很快的,我就可以直接連線到機器裡面,不用再記憶一堆使用者名稱,ip 設定等問題,直接透過更直覺的 alias 機器名稱方式,連線到自己工作環境。

結語

身為開發者還是要讓自己工作流程變得簡單,只要多嘗試使用工具,善用身邊人的意見,也許只是某個提示,都能夠大大的提升自己的開發效率。

推薦連結




工商服務

Node.js Taiwan 中文教學資料,現正更新中,如果你覺得書中缺少的區塊,或者自己有關於 Node.js 開發應用與大家分享,歡迎大家投遞 issue 至 github Node.js Taiwan,讓資料更為完整。

2013年3月4日星期一

[教學] zen coding (emmet) 安裝使用方式

0 意見

Zen coding 改名為 emmet



Zen coding 身為一個 web developer 不應該繼續花時間在浪費重複的事情上,這個好用的專案已經改名成 Emmet, 網址為,

Emmet 官方網址

Sublime text 2 安裝 emmet

輸入底下指令就可以安裝完成 emmet,
command + shift + p
input `package install`
input `emmet`

Vim 安裝 emmet

vim 安裝方式可以參考底下連結說明,
https://github.com/mattn/zencoding-vim
可以參考之前介紹使用 coffee plugin for vim 安裝方式

使用方式

在 emmet 網站裡面也有介紹如何開發 html,以 html5 樣板開發為例,在編輯區輸入內容如下,
html:5_
_ 為游標位置,在 sublime text 2 預設按鍵為 『tab』,在 vim 底下使用方法則為,『ctrl + y + ,』接著就會產生簡易的 html5 架構,內容如下,
<!DOCTYPE HTML>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title></title>
</head>
<body>

</body>
</html>
接著游標就會直接跳至 body 中央,即可立即開發雛形頁面,開發似乎變得更為方便,
其他詳細的使用方法,可以參考 emmet 語法說明,

後記

現在已經有許多好用的工具,可以讓前端工程師縮短開發時間,很多工具在不知道或者沒有人分享的狀況下,總是會自己重新刻一套,或者使用『複製』、『貼上』繁瑣的工作重新持續著。
就自己使用 Emmet 的經驗上,在產品的雛形開發上是十分方便的工具,如果大家有什麼類似的工具,或者前端輔助工具,也歡迎大家分享。

Facebook