跳到主要內容

發表文章

從 node.js 開始使用 io.js

從 node.js 開始使用 io.js 多想想你可以開始嘗試使用 io.js ,io.js 是從 node.js fork 出來的一個分支專案。 我們可以很直接的說 io.js 有可能就是 node.js 的未來 ,因為 node.js 目前專案掌控權在於在 joyent 手上,可是基於種種理由久久不肯釋出更新的版本,於是更新腳步上逐漸緩慢。 有興趣的各位可以看看 node.js 到 io.js 故事 。 現在 v8 (node.js engine) 幾乎都可以支援許多 es6 的 feature ,可是對於 node.js 久久等待的大大,就這樣子 - 生氣了。 於是 io.js 就是這樣子誕生了,在短短數個月中已經快速的釋出了 v1.0.0 - v1.0.x 版本,目前都屬於公告尚未穩定版本,不過對於 es6 想要嘗試的朋友已經可以進行安裝下載。 installation via nvm 現在你可以透過 nvm 直接安裝 io.js , 請先更新你的 nvm (請注意目前 windows 平台無法直接使用 nvm 指令,詳情請查 官方網站 ),接著可以透過以下指令。 已經安裝過 nvm 的朋友可以透過網站上面介紹的 安裝方式 ,重新進行安裝之後,再進行 source 即可。 nvm install io.js nvm install iojs-v1. 0.3 快速安裝完成之後,顯示的訊息應該為。 ###### ###### ###### ###### ###### ###### ###### ###### ###### ###### ###### ###### 100.0 % WARNING : checksums are currently disabled for io.js Now using node iojs-v1 .0 .3 恭喜你可以開始進入 es6 的世界,開始進入到另外一個 JavaScript 的未來國度中。 推薦你可以開始嘗試使用 koa 來建立自己的服務,或者開始另外一個 es6 探索之旅。 如果對於 es6 feature 有興趣可以從底下文章開始, ECMAScript 6 intro A glimpse into the f...

使用 GitLab 代替 Github 功能

使用 GitLab 代替 Github 功能 前面文章提到 Github flow 的整個用法 ,很多人會建立私有的 Github 不過在公司架構裡面其實很多資料都無法對外開放,因此架設一個內部使用的 git rep 都是常見的事情,因此 GitLab 通常是為第一優選。 why is GitLab? GitLab is open source GitLab is open source GitLab is open source 基於以上原因就足夠說明為什麼要使用 GitLab,他是 open source 那就表示程式碼裡面所有資訊都是透明,而且容易讓人可以知道如何去使用你自己的 rep, source code (就不會發生私自傳送程式碼到,遠端遠端遠端的莫名伺服器中),自己也可以很輕鬆的加上 plugin ,透過社群的力量,開源的力量,控制自己的程式碼。 GitLab 與 Github 相似之處 GitLab 其實用法上大多數與 Github 相似,也因為如此 GitLab 也通常拿來跟 Github 比較,不過我個人覺得兩種基於同樣用途的專案,最後勢必會走向自己不同的用途,解決方案,因此這段就跳過,怎麼發展就各自社群,擁護者自己去觀察了。 GitLab flow 替代 Github flow 其實 GitLab 特別有寫一篇文章,主要是講到如何使用 GitLab flow 替代掉原本使用 Github 的使用流程,基本上這是一個很有趣的文章,推薦大家可以來看一下。 特別是要提到,其實 pr (pull request) 的功能其實在 GitLab 裡面也有,就直接可以採用 GitLab merge request ,兩者之間差異性不大,不過功能大致上相同。 其中可以採用 vote 這個功能來幫助大家,一起進行開發。在 pr 留言的時候,可以留言, +1 -1 來表示對於此 pr 狀態的看法,讓 code manager 可以很快的評估這個 pr 到底能不能夠在當下就直接被 merge. 這對於 開發者 來說其實有很大的幫助,也可以提高大家的認同與參與度。 GitLab & 3rd party 在 GitLab 其實也預設與許多 3rd party 的外掛結合,例如 hipchat, slac...

Web development, from git flow to github flow

Web development, from git flow to github flow from Caesar Chi Web development 一直以來都是一個很有趣的議題,為了可以達到 1 week release 目標,所以開始去找尋適合的開發方式,因此從 git flow 的流程更新開始,我們找了許多方式,之後才找到 github flow 。 發現到這是最適合我們的開發流程,也是一個很自由的開發方式。 從 git flow 轉換到 github flow 總共花費了三週時間進行團隊步驟調整,目前我們透過自己架設的 git reps 建立整個流程,使用到目前,已經達到 100 多個 PR, 數多個留言,給予團隊以及管理上的好處實在是非常的多。 可以從這篇 slide 跟著一起 from git flow to github flow. 補充, 這邊我們的所有分支,feature, hotfix 等都是從  develop 展出,每個循環中再把 develop merge to master ,進行佈署。如果佈署出現任何問題,或者狀況,第一時間立即透過 CI 進行 rollback ,再下一次跌代佈署週期時將會進行再次的佈署。 Ref, Slack Jenkins unofficial plugin SCOTT CHACON talk, GitHub Flow https://github.com/thoughtbot/guides/tree/master/protocol/git

什麼是一位好的 PM ?對工程師來說

什麼是一位好的 PM ?對工程師來說 經過許多專案的洗禮,以及經過許多不同的程式開發流程,很多人都會對於 pm 這個角色既熟悉又害怕。熟悉的是許多事情都可以順利幫你處理好,讓開發的工程師沒有後顧之憂。害怕的是不知道什麼時候會被盯上。這種微妙又有趣的張力,每次在不同專案裏面都有不同展現。 也許對於工程師本身來說,放手讓自己可以好好展開身手就是一個發展的好平臺,對於有領取固定月薪工程師來說,最棒的工作,應該就是每天都可以摸到新的技術,以及每次都可以把新技術直接引用在開發當中。 而在當中最不想管得主要就是兩件事情。 回報開發時間 細節的糾正與調整 這兩件事情對於開發程式本身並沒有任何幫助,也不會讓自己長知識,更比不上使用 php 換成 go 改寫後端程式來的這麼有趣,這麼有爽度。 但是,人生一直以來就是這個『但是』。 你老闆在你背後,現在很火 給你薪水的人,現在很火,很火的事情是,他壓根不知道工程師每天辛苦改寫程式,他所能感受到的事情只有幾個, 你每天都在看 blog 你每天都在開 facebook 你每天都在看 youtube 你每天 … etc 老闆無法知道的是,API 從 2ms 變成 0.5 ms 需要付出的辛苦有多大,但是你每次開 youtube 就是會被看到,人生就是這麼剛好,也都這麼不巧 … WTF 這一切的一切,真的都需要靠一位 PM. 就是這一位 PM 大大 (指的爲  Project Manager)。 聯絡窗口及溝通橋樑 在整個開發流程中,PM 正是擔任此要角,很多人以爲 PM 的工作在於, 幫忙整理文件 畫押日期,與永遠改不完的干(肝)特圖 每天逼問工程師進度 脅迫工程師一日內完成世界奇觀 事實上 PM 能做的比想象的多很多,也因爲經歷過許多專案,以及開發流程,能夠瞭解一個好的 PM 能夠讓工程師省下許多事情。最大最大最大的好處,就是『讓大家知道我們在做什麼』。 讓大家知道我們在做什麼? 這件事情聽起來似乎非常容易,也是稀鬆平常不過的事情。但這其中至少牽扯到對上及對下之間的方式,首先對上來說,PM 可以讓事情的安排有一個節奏。 在與工程師正常回報進度的狀況下,所有的時程,以及進度狀況就 PM 能夠最清楚的全盤瞭解,也是因爲如此,更能夠抓出整個專案『實際開發時間』,...

mac yosemite, gem install error solution

mac yosemite, gem install error solution 更新 yosemite 版本之後出現錯誤,發現自己所安裝的 ruby lib 全部都消失了,前端所需要使用的 compass , sass 就需要重新安裝,可是出現錯誤如下, ERROR : Error installing compass: ERROR : Failed to build gem native extension. /System/ Library /Frameworks/Ruby.framework/Versions/ 2.0 /usr/bin/ruby extconf.rb mkmf.rb can 't find header files for ruby at /System/ Library /Frameworks/Ruby.framework/Versions/ 2.0 /usr/lib/ruby/include/ruby.h Gem files will remain installed in / Library /Ruby/Gems/ 2.0 .0 /gems/ffi- 1.9 .6 for inspection. Results logged to / Library /Ruby/Gems/ 2.0 .0 /gems/ffi- 1.9 .6 /ext/ffi_c/gem_make. out 1 gem installed 解法 首先要先進行更新 xcode 之後還需要,重新安裝 xcode cli 的程式,就可以解決掉這個問題。 xcode- select --install 後記 最後發現除了 xcode 程式要先更新之外,最好也更新一下 brew update , gem update 可以確保之前的程式架構都可以順利執行。 看來預設安裝 ruby 有好有壞,如果更新到新版本之後的 ruby 就會更新到 2.0 版本,所以也要特別注意一下相關的 dependency 有沒有相對應的問題。 最後 yosemite 誤我三小時 … 參考資料 Installing Rails on Mavericks

node.js 重大事件,分支 io.js

近期內看到一個專案 io.js ,一開始的時候覺得很神奇,怎麼會突然出現一個內容跟 node.js 幾乎一樣的程式碼。之後開始在 node.js Taiwan 開始有了許多討論 。才發現事情的始末。 之後也才漸漸瞭解 io.js 的目的,至於發展會如何,就繼續觀察下去,總之相信這股衝擊對於社群以及開源生態是有效的,而且對於整體發展是有幫助的。(期待啦 ...) 在下就隨手把 Max 發出的非官方聲明翻譯成中文,目前看了資料這一份整理的比較有系統,也容易讓人理解 io.js 目標。

yeoman step2, error solution

yeoman step2, error solution Warning: ENOENT, no such file or directory '$owner/app/bower.json' Use --fo rce to continue. 出現異常錯誤如上,跟着 yeoman 一步一步執行,記錄一下以下遇到的問題。 目前知道是因爲 grunt 底下的一個設定出現了問題。 解法 第一種方式,修改 Gruntfile.js 把 cwd 項目,改爲空字串 wiredep : { options : { cwd: '' } } 問題肇因 主要是因爲 wiredep 裏面的 option 設定的 cwd ,如果沒有讀取到適當位置的時候,會導致錯誤發生。 因爲 yeoman 上面的 step2 範例是直接安裝 @0.9.2 ,目前已經將 Gruntfile.js 裏面的 options.cwd 項目刪除,所以可以安心服用。 參考資料 latest version 0.9.7 , not able to build or serve Warning: ENOENT, no such file or directory **/app/bower.json