熱血漢誌 - 技術新鮮人到技術經理人，必懂的事

使用 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 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 這個角色既熟悉又害怕。熟悉的是許多事情都可以順利幫你處理好，讓開發的工程師沒有後顧之憂。害怕的是不知道什麼時候會被盯上。這種微妙又有趣的張力，每次在不同專案裏面都有不同展現。 也許對於工程師本身來說，放手讓自己可以好好展開身手就是一個發展的好平臺，對於有領取固定月薪工程師來說，最棒的工作，應該就是每天都可以摸到新的技術，以及每次都可以把新技術直接引用在開發當中。 而在當中最不想管得主要就是兩件事情。 回報開發時間 細節的糾正與調整 這兩件事情對於開發程式本身並沒有任何幫助，也不會讓自己長知識，更比不上使用 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 更新 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

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

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

JavaScript Closure usage, Closure 用法整理 在本次內部技術分享會，所看到同事分享 closure 的議題，這邊把資料做個整理，以及加上 reference 補充，如果同事們有把資料釋放出來，再繼續更新。 closure 對於 javascript 開發一定要接觸的課題，對於許多人來說大多是在於變數全域與區域上的差異。事實上在 javascript 裏面可以更爲有趣，裏面有許多好玩的地方。 最常見的方式爲 JavaScript function execution, 兩者之間的關係，就是完全沒有關係，雖然都是同一個 constructor，當然這個前提是回傳的資料必須是一個 object ，當如果回傳是 value 的時候，通常會被判斷成相同物件，實際上兩者還是不一樣的，這又關係到 JavaScript value is call by value 。會是有這樣的因果關係。 function fn ( ) { return {}; } var foo1 = fn ( ); var foo2 = fn ( ); console. log (foo1 === foo2); // reutn false; 基礎用法 basic usage 基礎的方式大概是，這種方式在許多實作上都會看到，特別是在 JavaScript 開發中，可以很簡單的使用這種特性，達到轉換的效果 var doSomething = function () { return function (x) { return x; }; }; var foo = doSomething(); foo( 10 ); // return 10 Y-combinator 如果我們需要參考到許多不同的變形，最經典應該就屬於 Y-combinator，直接應用在費式數列上，也可以試著用函式迴圈來做處理，如果用 Y-combinator 則是採用空間換取時間 function Y (dn) { return function (fn) { return fn(fn); }( function (fn) { return dn( fun

hubot integrate slack service 整合方式非常簡單。大部分的資料都是顯示遠端，而且需要 deploy 到 heroku，簡單的使用方式如下， 預先安裝 node.js coffeescript redis [option] yeoman 安裝方式 可以參考 hubot 官方提供資料。 npm install -g yo generator -hubot 接着新增資料夾 mkdir myhubot cd myhubot 設定 yo hubot 透過 yeoman 的建立流程，最後會問需要哪一種 adapter ，請輸入 slack 透過輸入之後就可以試著去啓動你的 hubot 整合 slack 請先到 slack 進行設定 hubot slack 連結網址 設定參數如下， HUBOT_SLACK_TOKEN= HUBOT_SLACK_TEAM= HUBOT_SLACK_BOTNAME= 啓動方式 bin/hubot - - adapter slack 如果需要建立特定 port ，請記得設定 PORT = 3000 bin/hubot --adapter slack 記得到 slack 設定頁面 設定好 Hubot URL ，如果是本機測試像上面的指令輸入，就可以直接測試 http://localhost:3000 測試方式 可以進行測試 @mention 的方式，進行 @webslack ping 可以看到回答 PONG 就表示正常執行。 其他參考資料 hubot hubot script hubot slack hubot slack steps