初嘗Node.js開發管理package.json

發佈自己的程式時，如何解決相依套件的問題是很麻煩的。套件的相依性，簡單來說就是我的程式需要哪些套件，要用什麼版本。最近看到node的npm管理方法，令人驚艷。

開發npm的套件時，需要package.json，這個檔案包含package的各種資訊，如作者和依賴的套件。顧名思義，package.json就是個json，結構也很簡潔。

這裡有官方的文件，我節錄和套件有關的重要的package.json片段，

{ "dependencies" :
  { "foo" : "1.0.0 - 2.9999.9999"
  , "bar" : ">=1.0.2 <2.1.2"
  , "baz" : ">1.0.2 <=2.3.4"
  , "boo" : "2.0.1"
  , "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0"
  , "asd" : "http://asdf.com/asdf.tar.gz"
  , "til" : "~1.2"
  , "elf" : "~1.2.3"
  , "two" : "2.x"
  , "thr" : "3.3.x"
  }
}

從上表我們可以發現，指定相依套件的方式很有彈性。可以指定特定版本，也可以指定某個區間。

設定完成後，只需要用以下指令，npm就會幫忙把套件裝到package所在的目錄下，對於開發者來說實在是很方便:)

npm i

增進程式設計功力的好書推薦

身為一個不太勤快的工程師，從學校畢業後看程式設計相關的書的時間減少很多，在這些書中有三本(其實有認真看的也沒幾本:-D )對我的影響最大。

Pragmatic Programmer / Andrew Hunt and David Thomas



Code Complete / Steve McConnell
Programming Pearls / Jon Bentley

這三本書中我第一名推薦的是Pragmatic Programmer，有兩個原因，其一是夠薄，三百多頁而已，在不算長的篇幅中把單兵作戰守則解說得很清楚。第二個原因是他有一個很棒的小抄。




推薦的第二名是Code Complete，此本為聖經不需多說，應該是所有推薦書單的平均第一名，我沒有放在第一名的原因是因為太厚了我還沒看完。

第三名推薦的是Programming Pearls，很老的書，很薄。最推薦的是"Back of the Envelope"這一章。此書在台灣甚難入手，Amazon上也沒有電子書，如果有機會得到的話一定要買下。

本日學習:
翻到Code Complete的第三十章:程式設計工具，其中一個自我檢查是:你的編輯器是否有自動編譯和錯誤檢查?
我赫然發覺平時用Vim寫Perl程式居然沒有這個功能，我必須用 perl -c 自行檢查。沒關係亡羊補牢猶未遲，趕緊找一個plugin perl_synwrite來幫忙，搭配這個外掛只需在存檔的時候用:W就可以先編譯perl程式，如果錯誤的話就會顯示錯誤訊息。

最後的總結就用 Jeff Atwood 的推薦書單吧

Vim基本心法 - 移動系

你聽說Vim的學習曲線很高而卻步嗎?

你正在學習Vim，但卻因指令難以記憶而苦惱嗎?

Vim和Emacs是電腦高手的唯二選擇。其實Vim的指令設計是很合理的。只要了解一個大觀念:
Vim是上古神器，那時會用電腦的人都會寫程式。
另外一個小觀念是:懶惰是程序員的美德，若可以的話，手盡量不移動位置，用右手去拿滑鼠這件事更是萬萬不可。

第一問: 為什麼Vim預設會進入命令模式而非編輯模式呢? 為什麼我不能夠一開始就打字呢?
試想你打開程式時，大多的時間在閱讀，編程的時間相對的少，所以一開始進入移動模式會比較有效率。

復述一遍:懶惰是程序員的美德，因此在命令模式下通常只需要一個按鍵就可以自在的移動。

用Vim打開你的一個檔案吧，如果沒有可供練習的檔案，可以打開Vim的求助檔案
:help<enter>

移動系四招共21個指令

左下上右 h j k l
移動游標是基本，而上下左右則是中的基本，所以就用右手最容易按的四個鍵hjkl。那為什麼j是下一行呢? 想想我們最常按的鍵就是"下一行"，所以跟最容易按的右手食指j配對正好。決定j代表下一行之後，右邊的k就當作"上一行"，再來就用左邊的h表示向左和右邊的l表示向右。

螢幕頂中底 H M L

除了上下移動，你有時會想移動游標到螢幕的頂部，中間，或是底部。這時就可以用按鍵H (High)移到頂部，M(middle)到中間，以及L(low)到底部。至於為什麼是大寫呢? 因為h和l已經被當成左右了呀。

到指定行 G

xG
x是行號。這指令很簡單，G就是go。

那要如何回到第一行呢? 可以用1G，但是可以用gg更為簡短。

在句子中遊走 web 0^$

w 是移動到下移個word的起始
e 是移動到此word的結束
b 是移動到前移個word的起始
0 是移動到此行的開頭。為什麼是0而不是1呢?我認為這是因為C語言中陣列的開頭是第0個字元而非第1個字元。
^是移動到此行的第一個非空白字元。選用^的原因是它可以被稱為hat，而帽子就是戴在頭上的囉。
$ 是移動到此行的最末端。選用$的原因我還不清楚:p

搜尋和跳躍 /? nN *#
/ 後面加上要搜尋的字串，就會跳到該字串。使用 / 作為指令的原因我猜是因為 slash 和 search 聽起來很像
? 和 / 相似，唯一個差別在於 ? 是用於向前搜尋。使用?的理由就是因為它和/是同一個按鍵。
n和N要配合/?使用。n就是搜尋下一個符合的字串。N是搜尋前一個符合的字串。如果一開始用 / 搜尋的話，n會往文章的後面搜尋，N則會往前面搜尋。如果是用 ? 搜尋的話，方向會相反過來。

學會這21個指令後，有沒有發覺Vim比其他的編輯器更強大呢?

連署網站設計

最近幫人做了一個簡易的連署網站，作為Google App Engine的練習。
第一次看到有這麼多人使用自己的作品，實在是很感動，同時也覺得應該要改進設計。

網頁簡介

此網站非常簡單，只有兩個使用者網頁

• 訪客用: 顯示連署書，加上連署者的姓名、生日、地址和電話。填好資料後按下送出即可。
• 管理者用: 可以下載連署資料，格式為csv。不需任何輸入。

可改進之處

• 採用 https 連線。
• 驗證輸入資料的合法性。拒絕空白的使用者姓名。
• 平衡流量。GAE的免費版本大約只能支援每天1500人。可以採用多重網站，每個的服務都相同，並從入口處隨機分配要連到哪個網站。

Bug

英文地址裡有逗號，會讓csv的欄位判斷錯誤。解決方法為加上雙引號。

自制vimgolf競賽排行榜

緣起
因為朋友ypcatw的介紹開始玩vimgolf，現在一共有104個題目，解決了32個題目之後，晉升到第92名囉，也終於可以在Leaderboard看到自己的名字。不過這個排行榜有兩個特別的地方。

1. 只有前一百名的排名
2. 沒有真正的"竿數"，也就是所有題目的排名總和。

排名規則
補充說明一下，vimgolf官方規定排名是用Global rank來計算，一個玩家的Global rank是他在所有比賽(題目)得到的rank總和。好比說fakecolor在"Get rid of html tags"這個比賽拿到第47名，rank就是47。如果沒有參與某場比賽，那rank就等同於參與該場比賽的最後一名玩家的rank。在計算排名時，Global rank越小的人名次越高。由此規則可知，每參與一場比賽都可以使你的Global rank下降。

自製排行榜

回到一開始的問題，官方沒有公布完整的排名，以及每個人的global rank。沒關係，身為programmer最棒的一件事就是可以自己動手做。為了知道自己和其他人的Global rank差距，我和Y決定自行計算所有人的Global rank，並製作成完整的排行榜。要怎麼自行計算Global rank呢? 要訣在於每場比賽的Leaderboard是公開的，就位於題目的右方。我們只須抓取每個比賽的Leaderboard，然後就能計算每個玩家的排名啦。
結果如下表格:

Ranking	ID	Global Rank
1	clvv42	2147
2	gumnos	2491
3	wondible	2867
4	federicogalassi	2885
5	h_east	2929
6	yslinnctu	3014
7	Korvin79	3800
8	_Balkoth_	3885
9	johnsyweb	4100
10	hujunfeng	4163

...
目前(2012 Feb)一共有約2000名玩家


製作方法
我們採用Google App Engine(GAE)做為平台，每天自動抓取所有比賽(Challenge)的Leaderboard，擷取出每場比賽的參賽者後，放入資料庫，並計算所有玩家的Global rank。使用GAE的好處是Google去別人家撈東西很勤快XD

尚未解決的問題
計算好玩家的成績後，我們利用web.py的template功能來產生網頁。目前為止都很順利，但是我們卻被頻寬的問題打敗。由於玩家約有2000名，所以每次產生網頁都需要從資料庫讀取2000資料。然而GAE是以量計價，免費帳號的資料庫存取量每天只夠我們讀取約60,000筆資料，也就是至多能產生30次網頁。為了減少流量，我們決定每天指更新一次資料庫，並利用GAE本身的記憶體快取(memcache)來減少需要讀取資料庫的情況。不過很可惜的是memcache常常會失敗。我們的第一個常識是把結果轉成RSS格式，並利用RSSPECT網站幫我們發佈，但是很可惜的是Google reader沒有辦法讀取發佈的文章，可能是因為內容太長了。
因此我們改採用另外一招:把動態產生的網頁轉成靜態網頁，放在其他伺服器上，做為權宜之計: http://www.csie.ntu.edu.tw/~b89107/vimgolf/ 。不過還是希望能夠在GAE內部就解決這個問題。

vim競技大賽 -- vimgolf

世界上有各種奇奇怪怪的比賽，在電腦界中常出現的一種叫做某某高爾夫，如同真正的高爾夫以杆數決勝負，電腦界的高爾夫往往是利用程式的長短。最近出現的vimgolf，是以vim編輯器作為競技場，參賽者相互比較誰能用最少的按鍵數目來修改一篇文章。

來看一個實際題目：以下是一份code，但是作者把大括號，中括號，以及小括號弄錯了，想請你把錯誤修正過來。

錯誤的程式
var some_function = function {arg1, arg2} [
   var some_array = (1, 2, 3, 4, 'foo');
   for {var i in some_array} (
         console.log(some_array, [{1 + (8 / 2)}, 'hello (world)');
   )
];

正確的程式

var some_function = function (arg1, arg2) {
   var some_array = [1, 2, 3, 4, 'foo'];
   for (var i in some_array) {
         console.log(some_array, [(1 + (8 / 2)), 'hello (world)');
   }
}; 

可以試試看用你最愛用的編輯器，要按幾次按鍵才能完成編輯呢？用vim的話，最少只需用34個鍵就能搞定！如何，是否有興趣學學vim呢？

奮鬥吧！系統工程師（４）誰都能辦到？專案管理 閱讀心得

這兩天看了小說"奮鬥吧！系統工程師"第四集，這次的主題是專案管理。
拜過去的成功經驗所賜，主角工兵接下PM(Project Manager)的工作，為了制定計畫，以及協調來自不同公司的專案成員而奔走。由於是沒有經驗的菜鳥，主角不知如何對應不受指揮的專案成員，就在焦頭爛額時獲得了正妹高人指點：如何駕馭對立的專案成員。

小說中提到專案成員可分成三類
Server (服務者)：此類型成員將PM是為客戶，可以接受內容粗略的委託，並自行做出適當判斷以進行作業。
Tool (工具)：此類型成員以作業員自居，會順從PM的指示，但並不會背負專案成敗的責任。PM需要追蹤此類成員的進度。
Client (客戶)：此類型成員將PM是為服務提供者，必須替自己排除影響工作的障礙，並且同時提供專案進度和支援。

看到這一段令我十分驚奇，因為這管理的道理和＜僕人：修道院的領導啟示錄＞所說的不謀而合。僕人中說：領導始於服務，領導就是服務。PM做為專案的領導人，也就要"服務"專案成員，為成員整頓環境（比如說解決失戀問題XD)，以及發生問題時的支援。

將成員分類對應到我現在的團隊中也很有趣。我的前輩是Server型的成員，不需多做指示變會自動完成工作，甚至還會反過來指示PM接下來的計畫:) 而我則偏向Tool，只專心在被交付的工作。

最後引用書中角色藤崎的話：專案管理是甚麼呢？就是可以讓大家愉快進行作業的工作。

[推薦] 奮鬥吧！ 系統工程師

[此文適合:資訊系學生，想進入資訊業的朋友，已經在資訊業工作的朋友]

有次同事聚餐的時候，我的大長官語重心長得跟我說了：「雖然我們是軟體業，但是最難的地方不在於技術，而是在於人啊。」我才剛踏入業界一年，很難體會他的感想，只覺得工作就是看能力，努力一定會有結果。最近看到一部輕小說 "奮鬥吧！ 系統工程師"，把軟體業的黑暗真實面描寫得相當清楚。
為了不讓氣氛太沉悶，先放張美美的封面 (圖片來自台灣角川)。

「千萬不要當上SE。」
研究室的教授這麽對我說。
「我站在這裏授課，不是爲了要讓你們過勞死。」
    -- 摘自第一集附錄

還沒被嚇跑的朋友請往下看:)

故事主角櫻坂工兵非科班出身，只是因為畢業找不到工作，被拐騙到駿河系統公司，開始了SE(system engineer)的生活。故事的架構是主角一邊學習，一邊把妹，然後順利完成工作...的樣子。雖然是照著輕小說的歡樂公式，但是本書對於工作的描寫卻是寫實到靠北邊走。好比說主角的主修是行銷，但是卻搖身一變成為工程師，這個設定其實反映了軟體業的入門門檻低，像dot com泡沫時期，阿貓阿狗都可以進入科技公司工作。
不過也不是說非科班出身就不能打出一片天，但隨著故事進行，主角利用美色協調能力讓團隊順利運作，並隨著經驗增加，不斷完成各種管理工作。我個人的感覺是，除了軟體公司裡面幾乎沒有正妹工程師以外，其他的部分都很寫實，好比說顧客任性的改動程序，老闆總是接下超過負荷的工作等等。如果主角換成女生，其他的角色保持男性的話，應該就毫無違和感了！事實上我大學時有個美人學姊，畢業後就到某知名外商當PM，也過得相當不錯。在一片缺乏社交能力的阿宅中，有交際手腕就容易顯得突出。想到這裡，我才發覺當年因為自己不擅和別人相處，還以為資訊工作可以只和電腦打交道，實在是太天真了。想要在這個業界混，還是不能不加強人際管理的能力啊。


發覺寫到這裡還沒有介紹多少內容，但是我懶得打書摘:p 所以放上前五集的標題，看得懂的人想會會心一笑吧

1. 兩週內即可上手？SE入門
2. 從基礎學習？運用建構
3. 絕不失敗？提案活動
4. 誰都能辦到？專案管理
5. Step by Step? Customer Engineer (中文譯名未定)

親愛的軟體工程師，你平常到底在做什麼？

又到了歲末年初的時候，三五好友聚會的時候總是會談到：最近的工作如何呀？誰誰誰受不了要跳槽了之類的。剛開始到業界工作時，我常跟人說我的工作不有趣，好像只是為了賺錢而已，所以萌生的辭職的想法。但是聽聽朋友的意見之後，發覺我其實還蠻幸福的，因為：

• 休假多，而且想放假就能放假，不會有專案緊急被叫回去加班的情況。這點很重要，我聽說不少公司的假很多，但是看得到吃不到。
• 每天平均開會時間約一小時，相當有效率。
• 薪水有外商的水準。
• 主管的技術底子強，不會有外行領導內行的情況。

以上是從外部來評量工作的好壞，但是我實際上在做的事究竟是怎樣呢？有那麼無趣嗎？我試著回想看看自己的工作情況，並看看自己有什麼成長。

Who：和誰一起工作
工作一年後，發覺關鍵果然是人，如果人對了，可以聊天打屁之外，還能夠相互刺激學習。如同一般軟體團隊，我們有
產品經理：收集客戶反應，然後決定產品的功能。
專案經理：scrum master。不曉得scrum是什麼？請收看Teddy Chen的部落格。此人並不需深入瞭解技術，他的工作追蹤專案進度。
架構師：一人，負責決定技術決策。
開發者：我和另外五人。主要工作是依據需求設計程式。
支援工程師：平時不會看到他們，不過當產品上市後，站在第一線面對顧客的意見抱怨的就是他們 :) 所以我們需要寫FAQ給他們用。最近從支援工程師那邊來的抱怨是：FAQ寫太多啦，特別是安裝系統的步驟太繁瑣。

What：做了哪些事
我嘗試用簡短幾句話來說我做了什麼。我們團隊的產品是開發針對VMware虛擬化環境的分析工具。為什麼要做這個產品呢？因為VMware是個包山包海的大怪物，裡面什麼東西都有，即便我接觸快一年了，對裡面各種虛擬硬體仍是不完全瞭解，更別說新近的VMware管理員了。
1. 收集事實：用Perl來擷取VMware環境的所有資料，像記憶體用量，CPU用量，錯誤紀錄，使用者的操作歷史等等等。這些東西都會送到我們後端的專用資料庫中。
2. 說故事：有了事實，我們要找出合適的呈現方法。好比說用折線圖呈現各種資源的用量，讓使用者能快速的瞭解他的虛擬環境。由於我們的前端是Web，所以我們常用到Javascript，將來更會多採用HTML5。
3. 回答問題：雖說預防勝於治療，但是一般管理者平時不一定會去用我們的分析工具，只有在火燒屁股時才會趕緊問：到底什麼東西壞掉了？所以我們事先收集各種錯誤的發生原因，並找出偵測方法，好在問題發生時能快速鎖定。

學到什麼
Script language：我們工作用到Perl和Python。特別是Perl，因為這是VMware官方的SDK之一。在這之前我怎麼都搞不懂Perl裡面的%&$@奇怪符號。說真的script langulage開發起來比C快很多，程式也簡短很多。唯一的遺憾是你沒辦法吹噓說自己寫了上萬行程式碼:)
VMware：這是個龐大的怪物！我好像進了大觀園一樣，改天要整理自己的心得分享一下。
Splunk：強大的搜尋引擎，有著類似SQL但又獨特的指令。

回顧完這一年的工作經驗後，發覺好像也沒哪麼無趣嘛。新的一年如果還在這家公司的話，我想要學習HTML5和jQuery，一方面可以強化我們的使用者介面，一方面可以玩一些資料視覺化。

各位看官，你們的工作是否也能說成一個有趣的故事呢？