f2e-interview

最近面試好多前端，就來寫下這面試的感覺吧，不得不說前端這領域相對其他領域還是個新的領域，百家爭鳴，不像後端一樣，幾乎已經在各觸最佳實踐（又或者我接觸還不夠深）。

框架

但就我自己的看法來看目前所有的框架，到最後還是圍繞著幾個點： 1. 架構是否足夠彈性、有結構、組件化 2. 學習成本 3. 活躍社區

我認為一個好的架構不是能夠讓你少寫多少行 code，而是更結構化的幫你快速切入，讓整個團隊協同開發同時能有個中心思想，別讓樓越蓋越歪。常在面試聽到我之前用 XXX 框架開發結果性能很差，現在換了 XXX 後變好快（考試都考 100 分了 ^.<~* 啾）。其實不管什麼框架，只要你能夠有時間重構一次幾乎都會比原來更快，很簡單的道理，當你熟悉當前的業務邏輯後當然可以比起剛開始設想的更加周全，各方面自然就好起來了。

但框架不是一切，更重要的是了解這框架的實際運作方式以及前端所在容器的特性，例如在 PC 瀏覽器、手機瀏覽器、webview、各種 webkit 抽象出來的容器…等，能夠完美跟容器結合的就是最好的框架，能夠摸透框架、容器運作原理就能夠寫出做完美的結構。當前也是有許多優秀的框架，如 Reactjs, Angularjs, polymer, vuejs, … 等，每個框架設計上自然有他適合的場景，也會有他不適合的場景，能夠依照當前的需求做出最完美的配合自然是好框架。

近來如 Reactjs 發展出了 React Native，阿里造的 WEEX，也是框架上的另一種突破，讓除了熟知的 web 容器外更延伸到了 Native 重新打造一個容器，但說這個真的有未來市場在這我還是保持懷疑的態度，回想起幾年前的手機瀏覽器也是如此的不堪，近來硬體運算能力越來越強，手機瀏覽器的問題也少了。你說 React Native 是用 Native 渲染，速度很快，比起 Web 體驗好很多，接近 Native 體驗，就我目前看來都是個階段性產物，最終還是會回歸到 Web。但你說這些嘗試都沒意義嗎？其實不盡然，沒有這些創新的演進還是無法解決當前手機瀏覽器內的效能不佳問題。

專案管理、開發、測試、發佈

專案管理這邊應該指的是如何管理你的 source code，很多人或許會說直接用 git 不就好了，git 確實解決了本地開發、團隊協同開發上的問題，但在多人開發同時該如何用 git 控制好品質才是這根本問題，團隊人多，每個人的開發習慣也不同，是否在 pre-commit 進行 lint 就能夠把持？pre-commit 要跑的 lint 該如何即時同步？是否有 CI 機制保障穩定性？是不是該每個需求都切分支出來開發？是否養成送 PR 的好習慣？任何小改變該如何同步給所有人？該如何自動化？git, svn, perforce 這些都是工具，幫助開發、多人協做的工具，絕對命令行多會幾個考試就會考一百分。

管理好 source code 下一步就是該如何同步、自動化的本地開發環境，在這很多人會說用 gulp, grunt, npm, make … 等，但這又回到了工具問題，這些工具很棒，隨便 google 也可以知道很多 plugin，但我更想知道的其實是你如何用這些工具，做了哪些事情？JS 是否 lint, minify, 去除 debug 訊息…等？CSS 用什麼 preprocessor？進行了什麼處理？html 有沒有做什麼樣的處理？用了什麼模版引擎？本地模擬 API 還是統一的測試 server 模擬 API？每次 build 是如何管理版本？圖片是否壓縮？圖片以什麼方式壓縮？哪時候壓縮？…… 等等等的一堆事情，這其實才是這核心所在，絕對不是我用 gulp 管理本地環境一句化就結束。

測試應該是目前遇過最少有經驗的，10 個裡面大概有 8 個沒經驗 1 個瞎掰 1 個有簡單的經驗，這邊要特別感謝過去在趨勢有龐大又有經驗的測試陪伴著我成長，測試絕對是必要的，一個好的 RD 必須能完成三件事才算是優秀，開發完專案、高覆蓋率的測試、線上監控，能夠把視覺搞完美還原這頂多是 60 分，也就是一個入門程度，做到測試再加20，做到監控再加20。詳細測試還有很多細節就不再一一贅述，基本如果能做到 TDD…這我只能膜拜了，因為你做的事情應該跟業務已經脫節或產品週期很長。但坦白在我心中團隊中是不需要有 ”測試” 這角色，養成良好的寫測試習慣絕對有助於增加品質減少測試人力。

發佈這就又是另一門大問題，現在基本聽過的是 FTP 直接上傳 server，git/svn 直接傳，有轉職人員幫忙（好耳熟…閃開！讓專業的來！）等，其實比較想了解是整個出 build 的流程，是否用 build server 打包？打包完是人肉發還是自動發？出完 build 發上線後是如何運作？直接放上 CDN 做靜態資源還是透過模版引擎解析？

效能、兼容性

這應該是整體來說非常重要的一環，尤其在體驗上更是致命的重要，基本的 js/css/html 要 minify，減少請求數量，圖片要壓縮，icon 可以用 iconfont 或 image sprites，進階一點大概到圖片要針對不同環境載入不同壓縮品質、尺寸，打開頁面後有多少請求，總共多少 k，dom 數量如何最簡化並且控制數量，圖片不在畫面中的不要提前載入，適時使用 loader 來載入 script，該如何有效控制記憶體避免 app crash，長 list 該如何做到最好的效能，css3 的新需求要小心使用減少 render 層，cache 該如何有效應用，app 內的 webview 該如何有效利用 app 特性來 cache，預載 …等，這些東西講起來都很簡單，但就目前為止所有收到的履歷上沒有一個做到好，很多人會說這些我都知道都會，但是該如何讓大團隊也能運行起來就是能否從 junior 到 senior 的關鍵。

AMD, CMD, Commonjs 這也是我常問的一個問題，雖然也是很基礎，但我覺得蠻重要的，因為搞清楚著些組件化的方式對於整體架構上非常有幫助，在按需載入上也是重要的一環。

判斷在不同裝置、容器下做出最好的體驗，在 ie6 等較舊的瀏覽器該如何做最好的降級處理，使用哪一種寫法可以有效的兼容不同平台，用上最少的 hack，不斷使用 hack 方式只會造成越來越難以維護。

網路、安全

網路方面最重要就是跨域問題，問到很多人都回答用 jsonp 就好啦，但卻不知道 jsonp 實際上是如何運作，以及 CORS 在 http response header 該加上些什麼？http preflight 用途是什麼？200, 204, 301, 302, 400, 500, … 這些 error code 用途是什麼？哪些點可能有安全風險？該如何避免 XSS 攻擊…等。

open source

開源也是我常問的點，我相信喜歡參與開源專案的小孩不會變壞(誤，常參與開源的人大多有幾種狀況，喜歡分享，喜歡與人討論、協做，我認為這部分對於在企業內是非常加分的，分享不但可以知識沈澱還可以推廣給更多人，對於團隊長期來看是非常重要的要素，唯一要小心的就是怕把公司內部的資產也 open source 出去…

未來、新技術、設計

對於未來的眼光、敏銳度，關心 W3C 標準或更深入參與 W3C 標準定義，看到未來的技術走向並且能夠提前帶領團隊移動到這條軌道上。保持新技術的探索，就算不能參與也要保持觀望，別讓自己成為最後被通知的人，不然當你需要時永遠處於被動。對於設計、體驗要能夠感同身受，試想用戶使用的場景，不是一昧的把視覺搞、產品需求拿到就開始做，前端就是產品到用戶的最後一哩，你掌握著用戶看到這產品後的體驗，每個字大小、間距、行高或許你會比設計師更有感覺，API 慢了也要做點過場掩蓋掉，千萬別小看自己所在的這位置的重要性。

總結

剛好想到什麼就寫了什麼，簡單羅列一下，當然還有很多細節魔鬼在其中，這些是我做前端以來的一些簡單心得，也是小魯我認為身為前端該有的部分，想當年小魯我也是被老闆說了一句「你如果還想待在這家公司就轉前端吧，這邊沒有 iOS 的缺了」一個誤闖誤入，現在是相當感動當時這句話讓我更開拓新的一條路出來。

最後想說的就是…歡迎加入 天貓前端，看我們在 2015 雙11的 912 億人民幣背後做了多少準備，歡迎把履歷寄到 taicheng.htc@alibaba-inc.com

windows break line ^M in unix

今天遇上了一個 git clone 後自動產生 windows 換行問題，查了一下造成在 unix like 都會造成無法正常使用問題，最後解決方式是直接用 vim 來把這換行符號刪除，由於少量就沒再去找其他方案，在 vim 當中刪除方式為按下 ESC 後輸入以下這段，再按下 enter，由於 ^M 是特殊符號，而不是你所見的，所以必須要按下 ctrl 的組合鍵來輸入。

:%s/<CTRL+V><CTRL+M>//g

git show commit user and count

github 上有個很酷的圖表是看到所有人的 commit 數量以及增減多少行 code，相同功能在 git 上也有，如同下方的顯示方式可以很清楚的看到所有 commit 數量以及是誰 commit

1266 Isken ******
139 Kyle ******
3 Randy **

只要使用以下指令就可以叫出上方這列表

git shortlog -sn

其中 shortlog 有以下幾個指令可以使用

usage: git shortlog [] [] [[--] [...]]

-n, --numbered sort output according to the number of commits per author（依照 commit 數量降覓排序）
-s, --summary Suppress commit descriptions, only provides commit count（不顯示 commit 內容，只顯示 commit 數量）
-e, --email Show the email address of each author （顯示 email 來分別不同 user）
-w[] Linewrap output

如果指令改為 -sne 會再加上 email 來判斷為不同人，所以同一個名字可能會出現兩個

git shortlog -sne

1266 Isken ******
216 Isken ******
139 Kyle ******
3 Randy **

如果後面再加上檔案路徑就只會顯示針對這檔案的 commit 數量

資料來源
https://www.kernel.org/pub/software/scm/git/docs/git-shortlog.html

git hooks deploy (nodejs)

deploy(部屬) 是個 production 的必經階段，該怎樣做的方便又穩定是個重要的關鍵，先來談談一般 web server deploy (以 nodejs 為例，這邊暫時不談 server side 架構)

(假設使用 bitbucket host git repo)

1. 把 local source code push (本地端原碼推到) bitbucket
2. ssh 連到 web server
3. git pull 想要的版本
4. npm install（更新 package）
5. restart node process (重起線程)

以上的步驟看起來其實也不難，ssh 連到 web server 的步驟也可以使用 key 的方式來減少輸入密碼步驟，進入後需要進行的東做也不是很難，但總是要問自己一下 "還能不能更好？"，立馬想到先前使用些 saas 的經驗，如 heroku, openshift, nodejitsu ... 等，使用方式非常簡單，只需要把 code push 上 saas server，就自動可以跑起來，這種感覺真的太棒了！以 heroku 為例，會要求你在原本的 local repo 加入一個 remote 的位置(如下)，之後想要 deploy 只要 `git push heroku master` 就可以丟上 heroku 並自動重起。

git add remote heroku GIT_REPO_URL

想要自己實作這段就必須使用 git hooks，以 bitbucket 為例(下圖)，可在 repo 設定收到 push 後要執行哪些指令，bitbucket 很貼心的與很多不同的 service 合作，讓 hooks 更方便(一般常見的 git host 都有實作，不論是 github, gitlab...等都有)。


這段收到 push 後必須執行哪些指令的行為就是 git hooks 的 post-receive，收到 push 後想要執行哪些指令，pust-receive 為 bash script，所以可以方變得跟各種 cmd 整合，基本上可以將最上面的步驟 3, 4, 5 整合，pull 想要的版本、更新package、重起 node process，但還是缺少了最重要的東西，git 要 push 到哪？

首先建立一個 git repo 並且使用 bare



接著更新 $HOME/deploy.git/hooks/post-receive（範例中使用 forever 來管理 node process，亦可使用 nodeman, pm2 等來管理）


最後就是在開發的 repo 中加入 remote 路徑，ssh user, ip 就與 ssh 登入是相同的

git remote add production SSH_USER@SSH_IP:~/deploy.git

完成後 deploy 就與 heroku, nodejitsu, openshift 一樣只要下指令就自動完成 deploy 所有流程（更新最新版 source code，更新 node package，重啟 nodejs process）

git push production master

相關連結
heroku
openshift
nodejitsu
bitbucket
github
gitlab
git hooks
forever
nodeman
pm2

git SSL certificate problem

今天在某台 centos 的伺服器上遇到這（下面這段）問題，看似 certificate 的問題，去 google 一下會發現超多種解決方式，看似非常複雜但其實有更快的 workaround。

error: SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed while accessing http://github.com/xxxxxxxxxxxxx

這問題應該會發生在 git clone 或 npm install 時，某些 package 造成，但其實就是 certificate 出錯，如果是 git 最快速的解決方式

GIT_SSL_NO_VERIFY=true git clone https://github.com/.......

但是如果是 npm 並沒有辦法這樣下，所以要用另外的方式

export GIT_SSL_NO_VERIFY=true
npm install

git remove remote branch

一般來說想要刪除遠端的 branch 直接使用：

git push REMOTE_NAME BRANCH_NAME
sample: git push origin dev

但是可能你無意中把 branch 名稱與 tag 名稱設定相同，當你想要刪除時 git 會給你錯誤訊息：

error: dst refspec BRANCH_NAME matches more than one
error: failed to push some refs to 'https://github.com/IskenHuang/xxxxxxxxxxxxx.git'

這時候如果你還是想要刪除遠端的 branch 請改下指令：

git push REMOTE_NAME :refs/heads/BRANCH_NAME
sample: git push origin :refs/heads/dev

相關連結
Deleting remote branches

search code in git commit history

常常寫到一半看到過去的一段 code，內心的 OS 不禁嘶吼「WTF 怎麼會這樣寫」，這時候就只好回去找是哪一次 commit，但問題來了，每個 file commit 數量這麼多要怎樣找？還好 git 有提供查詢的功能（淚奔～～～）

如果只是要查詢專案目前的 source 可以使用下面這行，REGEX 就是你想查詢的條件，當然還有很多參數可以帶(請參考：http://git-scm.com/docs/git-grep)

git grep REGEX

如果是要收尋整個專案所有過去的 commit 可以使用下面這行，SEARCH_STRING 就是想要搜尋的字串，FILE_PATH 檔案的路徑，如果是想要搜尋整個專案可以使用「.」，詳細參數可參考：http://git-scm.com/docs/git-log

git log -S SEARCH_STRING FILE_PATH

相關連結
http://git-scm.com/

ubuntu git clone error: server certificate verification failed

ubnutu git clone error message

Cloning into 'trend-branding-styleguide'...
error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing https://gitlab.tw.trendnet.org/randy_lien/trend-branding-styleguide.git/info/refs
fatal: HTTP request failed

input below in the shell

$ export GIT_SSL_NO_VERIFY=1

Reference: https://blog.breadncup.com/2011/06/09/skip-git-ssl-verification/

Git

Git init
git init

Saving State
git commit -m "[content]"

Saving State
git commit "[content]"

Add all files
git add .

Add all file
git add [file name] [file name] [file name] ...

Remove file
git rm [file name]

Rename file
git mv [old name] [new name]

Log
git log

Undo
git reset --hard [path]