對於 VIM 的 plugin 管理方式一直用的是 https://github.com/tpope/vim-pathogen
Vundle 有聽過,可是一直沒有真正的搞懂,差別是什麼,直到看到了海大簡單的說明 http://tzangms.com/2012/01/18/vim-plugin-manager-vundle/ 才了解,Vundle 真是懶人救星,可以解決,我一直以來,用 git submodule 的方式同步 bundle 下面各的 plugin 的動作
可以讓所有的 plugin 的管理都濃縮到 .vimrc 裡頭
更新後的 github vim base file https://github.com/terryh/dotvim
prism
2012-01-29
2012-01-17
NWM
如果你是 MS 視窗的開發者,可是想試試看 node.js with mongodb 的人
也有視窗版的懶人包
http://nwm.julianxhokaxhiu.com/
或是自己安裝
MongoDB
http://www.mongodb.org/downloads
Node.js
http://nodejs.org/#download
PS: 我自己完全沒有試過,開發都在 Linux 上面,所以請自行體驗,好用的話記得也 blog 一篇,或是 twit 一下
也有視窗版的懶人包
http://nwm.julianxhokaxhiu.com/
或是自己安裝
MongoDB
http://www.mongodb.org/downloads
Node.js
http://nodejs.org/#download
PS: 我自己完全沒有試過,開發都在 Linux 上面,所以請自行體驗,好用的話記得也 blog 一篇,或是 twit 一下
2012-01-10
NPM package.json
一般不管什麼語言,幾乎都沒有內建套件管理,但是 Node.js 現在除了一直保持初衷,
要維持核心程式的精簡外,加入了 node 一直以來,必裝的 npm 套件管理,方便 node 的使用者,管理套件,及更新
所以 maybe node.js is not battery included but with charger.
參考資料
官方網站
http://npmjs.org/
原文
http://blog.nodejitsu.com/npm-cheatsheet
http://package.json.nodejitsu.com/
中文
http://dreamerslab.com/blog/tw/npm-basic-commands/
2012-01-05
screen
改一下 ~/.bashrc
小抄一下別人的 ~/.screenrc
參考
http://adam8157.info/blog/2010/05/terminal-bash-screen/
http://archerworks.blogspot.com/2010/05/linuxscreenbindkey.html
這樣,顏色,還有訊息都豐富了,不會逛到哪一台主機 git 到哪一個 branch 都分不出來
GITPS1='$(__git_ps1 " (%s)")' case "$TERM" in xterm*|rxvt*) PS1="${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]${GITPS1}\$ " PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1" ;; screen*) PS1="${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]${GITPS1}\$ " PATHTITLE='\[\ek\W\e\\\]' # Use program name as title PROGRAMTITLE='\[\ek\e\\\]' PS1="${PROGRAMTITLE}${PATHTITLE}${PS1}" ;; *) ;; esac
小抄一下別人的 ~/.screenrc
# Caption line #caption always "%{= R}[ %{=b b}%-w%{=rb db}%>%n %t%{-}%+w%{-b}%< %=%{R}][%{M} %Y-%m-%d %{G}%c%{R}]" caption always "%{=b k}%{b y} %m-%d %c / %{k}%L=%-w%7>%{g}%n %t%{-}%+w%-014< %-016=%{c} %l " # Set default encoding using utf8 defutf8 on # Refresh the display when exiting programs altscreen on # Dynamic title shelltitle '$ |bash' # Set xterm's title hardstatus string "screen: %t" # C-a b --(switch to)--> view big5 data bind b encoding big5 utf8 # C-a u --(switch to)--> view utf8 data bind u encoding utf8 utf8
參考
http://adam8157.info/blog/2010/05/terminal-bash-screen/
http://archerworks.blogspot.com/2010/05/linuxscreenbindkey.html
這樣,顏色,還有訊息都豐富了,不會逛到哪一台主機 git 到哪一個 branch 都分不出來
Get your Node
MEMO 一下 Debian testing 上面的 Node 安裝
實在進步太快了,裝 pre compiled 的套件沒有感覺
sudo apt-get install build-essential python-software-properties libssl-dev libreadline-dev git-core curl libcurl4-openssl-dev
記一下 libcurl4-openssl-dev # 只是目前 debian testing 上面依存的套件
git clone https://github.com/joyent/node.git cd node git checkout v0.6.6 # 目前最新的 release tag ./configure make sudo make install
發展快速,社群活躍,最重要就像的第四台老師有說得 Location, Location, Location
Node.js 是 Open, Open, Open (community, community, community, 內建的 npm 套件管理, 這一點夠方便吧)
想要變高,變帥,變聰明前,不要忘了,上場前,把 node.js 的傢伙戴上
http://www.webresourcesdepot.com/the-awesome-node-js-and-its-gang/
https://github.com/joyent/node/wiki/modules
參考
http://fred-zone.blogspot.com/2011/12/debian-nodejs-express.html
http://www.freshblurbs.com/install-node-js-and-express-js-nginx-debian-lenny
八卦一下,我的 VPS RAM 太小,本來是要說 Get your JVM,不過看起來,這一隻怪獸,還是要找多一點 RAM 的主機,才願意開始幹活
terry@atomvm:~/node$ java -version Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine. terry@atomvm:~/node$ node -v v0.6.6
2012-01-03
得了不寫 Test Case 會死的病
許久以前每開始一個專案,會以時間為重要的考量因素
(很像沒有作過不趕時間的專案)
漸漸一個專案,如果不是像活動性質的案例
專案功能少有幾十項,多則分到各個模組拆作
沒有寫 test case ,團隊成員新增功能,或是修復 bug ,只要整個程式庫有了變動,都是風險,越來越膽小,小到,現在都是邊寫程式,到一個階段後,直接把 test case 寫完,才敢上線,或是更新,不然沒有安全感,以前舊有的 test case 就是一點一滴,紀錄整個系統進化的日記一樣,可以確保每個細節,可以安全無誤
一般人的想法,可能覺的寫 code 都沒時間了,還寫什麼 test case 尤其是在台灣的軟體生態裡,更是如此,有 bug 可以修的修,不好修的,藏起來,時間為先,只要這不是一個用過就丟的系統
不過現在欠下來的,以後還是要還,尤其是自己的產品時,都會有長遠的發展,及早養成習慣,使用正確的工具,可以讓你的測試,寫起來,又快,又笨,又簡單,時間花的就不會像你想像的那樣多了 ;-)
PS: test case 我是泛指所有的測試,不管是功能測試,效能測試,還是介面的部份...
訂閱:
文章 (Atom)