CMS Next

從 CMS 開始出發，在這領域上確實是發現不少的可能，CMS 核心在於內容管理，說穿了也就是如何幫助用戶把數據轉化為可見的東西並產生價值，數據來源可能是用戶創造，也可能是引入其他的數據來源，核心就在於如何把價值最大化。

一切從前端開始，最初這套 CMS 目標是解決前端人力資源問題，頁面中所有的東西需要由前端來將數據與設計結合展示給用戶，因此開發出很多的模塊，模塊把業務邏輯成載於其中，並且定義出標準數據源規範來對接各種不同的數據；確實有效了解決人力資源問題，因此前端開始更專注於頁面使用體驗，如何把性能變更好、滑動更順暢、各種監控與業務流程跑順；如果沒定下標準，現在肯定還是在收需求、做需求，無法深入到商業更核心的點。

到今天體驗已經不再是問題，透過整體優化已經能做到 app 內 96% 平均 1 秒內用戶可操作，這概念就像是 96% 用戶訪問在偷喵隔壁走過來正妹的同時頁面已經可用，並且能在穩定性與滑動體驗的都能保持順暢，以上好的體驗當然還是靠 Weex 達到，並且端上各種黑科技支持；那麼解決完這塊後下一步是什麼？目前我們理出兩個方向需要來再深挖，第一是 CMS 能力下沈為框架，這套體系確實完整，但仍然無法快速支持不同類型業務拓展，CMS 設計再好也無法解決所有的問題，通用只能解決最大公約數，但製作內容的流程與效率取決於組織人員配置與職責，尤其在業務不確定並且快速發展的狀態；第二是介面個性化，過去在內容數據上做了各種不同個性化，介面上僅有少數透過 ABTest 或定向投放來做測試，確實在 ABTest 下我們知道不同類型用戶給予不同 UI 樣式能讓點擊、轉化有所提昇，但無法像 Bandit testing 的方式能夠讓 ABTest 同時動態調整分桶比例，讓效果不好的部份即時減少流量，確保每次調整都能保留好的部份。

介面個性化這事讓我想起當年在學校談的衍生設計，當數據已經有穩定的算法優化後如何讓這些數據自己找到最適合的 UI 給到適合的人，人貨場是新零售所談的實踐之一，每個人對這三個字的解讀也有所不同，就我自己來看人貨透過數據已經有算法在背後努力，場就是由 CMS 生成適配，初期可以由數據自動找到適合的模塊，中期可以再進一步找到對應模塊後把模塊內可展示的內容個性化，長期來看就是設計一套語言來根據數據找出適合的介面。

這步完成後 CMS 在其中所代表的就不再僅是前端效率提昇或設計師落規範的應用，而是商業、設計、開發共同協做的 framework，CMS 也不再僅是某個端的範疇，提供的是一套端到端的服務。

感覺很多事還想的不是很透，後續該好好疏理下...

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

mitmproxy

最近在找 mac 上 charles 的替代方案，mac app store、google 查了一下都沒有比較完整的工具，在不想直接用 nodejs 重寫一套的狀況下最終找到了 mitmproxy。

就如同官方文黨上面說的很全面，擁有 command line tool 又擁有 GUI（簡直不可思議），所有功能都提供 command line 啟動時配置以及啟動後隨時修改，最厲害就是 open source，可以按照你自己的方式來 hack 他，或是有開放一些 script 進行簡單的修改。

在平常開發上除了抓封包看內容以外最常用就是把某個 url 代理到本地文件、url 做 302 到特殊 url，或是簡單的修改 http 的參數，但是以上這幾個功能只能使用都必須使用 script 來配置，但是...網路上幾乎是找不到相關的文件或是不完全，最終找到幾個簡單的語法可以來做這調整，可以參考以下的寫法

How to transter form Front-end developer to Client-side developer

最近在準備整理該如何教一位 Front-end developer 快速上手成為一位 Android/iOS Developer，以下整理個幾個同事問我的問題：

記憶體管理

但是 objective-c arc/java gc/ swift 雖然看起來差不多(不需要去處理 retain count/ pointer)，但還是有很多最佳實踐方式不同。

看的到，选不到

在web上只要看得到的元素都可以用 selector 找到然後修改，在 native 上卻是要找到相對應的記憶體才可以修改，不管是 xcode 還是 android studio 之類的 IDE 對這方面其實都有很強大的索引功能，只是需要花點時間習慣。

档案碎片化，找不到到你是哪個檔案

一般 web 開發可能全部寫在一個檔案或分成幾個 js 載入，看先後順序就知道能不能用，native 上使用的語言都比起 js 看起來更結構化，如果習慣 AMD 架構的 js 可以更快上手。

HTML/CSS/JS 好像被組合起來了，想要調整樣式找不到位置

native 所提供的 SDK UI 組件可以看做是 web component，不論在 iOS, android 都有提供大多數基礎的 UI 組件，但這些組件也都會和原本系統的 UI 樣式相同，因次該如何 hack 他就會成了你非常常去查詢的問題，大多數原生的組件都有提供非常可靠的客製化功能，遠遠比起自己重寫可靠。

不知道該從哪裡切入？

這問題應該是最常聽到，就如同作事一樣，如果沒有目標，作起事來完全沒效率，關於這點目前是參考 Mozilla 相同的作法，每個版本都會有些小 bug，小如圖片放錯、顏色調整，這類的 bug 就很適合給新手來切入，順便在了解過程中就一併開始看架構，就像寫書法一樣，在開始創作前肯定有臨摹的階段。

環境、環境、環境

web 算是個相對成熟的架構，對前端來說不論你用 nginx, apache, nodejs, python, ruby, go 都可以很方便的幫你起一個 server 來開始工作，甚至只要有瀏覽器就可以馬上開始工作，環境這塊還是建議交給專業的來，請專業的人先幫你配置好，或有文件可以參考來靠自己建立起來，這就依賴時間緊迫程度來變動，簡單還是一句話「讓專業的來」。

專業分工

我認為大多數的前端都是對於畫面有一定程度的美感，對細節體驗有一定程度的要求，尤其是有「圖層」的觀念，從這方面出發我認為陣痛期是最短的，因為你負責的還是 UI 相關的事，底層的事可以讓原本熟悉框架的專業人士來負責，一來有成就感（作完馬上可以看到畫面，別再老是看 Hello world!），二來在前端的追求細節精神可以連貫下去。如果不小心寫出興趣還可以往圖學發展XD

Multiple thread

這就牽涉到語言的特性，需要搞清楚點觀念，只要作過 UI 的都知道，main thread 絕對不要處理任何會卡住的事情，任何 http request, 大量運算處理都要做 async 處理，這道理就像你做一個 web application 但是你絕對不會等到所有東西都載入完成後才出現畫面。



最後我想要說的是，最近身邊、老闆總是在談 native 吃掉 web 這回事，我本身是完全不認同，web 不會消失，市場也不會縮減，目前唯一可以跨平台的方案就是 web ，只是他在手機上的方式還不比在 pc 上成熟，效率上無法跟 native 相比，我認為最大原因就是歷史包袱，ios 只需要考慮在 iphone 的使用狀況，不需要考慮在 android, windows phone, browser 上跑起來的狀況，自然可以效率高許多，就像一把瑞士刀肯定不比菜刀好切菜。

多學一種技能也是挺有趣的，可以讓你有不同觀點來切入一件事情，思考上也可以更靈活，在我看來換個語言、平台都是差不多的，就像你會用中文罵「幹」會用英文罵「Fuck」一樣，沒什麼了不起，熟能生巧罷了。多學一點對自己肯定不會吃虧的，如果真的不知道該從哪種語言、平台開始，就找的自己看順眼喜歡的吧，我相信再過不久前端(Front-end) 就會變為客戶端(Client) 或終端工程師跑出來，把控這與使用者接觸的最後一哩路。

html5 video player full screen issues

這問題被問許多次，就是 iPhone/iPad 上的影片是不是可以不要全畫面播放，這問題其實官方已經寫的很清楚，以下節錄至 Safari developer：

Optimization for Small Screens

Currently, Safari optimizes video presentation for the smaller screen on iPhone or iPod touch by playing video using the full screen—video controls appear when the screen is touched, and the video is scaled to fit the screen in portrait or landscape mode. Video is not presented within the webpage. The height and width attributes affect only the space allotted on the webpage, and the controls attribute is ignored. This is true only for Safari on devices with small screens. On Mac OS X, Windows, and iPad, Safari plays video inline, embedded in the webpage.

Note: Prior to iOS 4.0, iPhone and iPod touch did not play audio inline. Audio was presented in full-screen mode. Audio plays inline on iOS 4.0 and later, on all devices.

最後這段重點就是，為了給小畫面最好的瀏覽品質，所以在 iphone 使用 mobile safari 或 webview(APP 中) 會用全畫面播放，而 iPad 因為畫面夠大，所以可以提供使用者/開發者選擇是否全畫面播放。

但是在 App 中還是有例外，因為小畫面無法非全畫面播放這件事情在 iOS SDK 中是一個參數，可以提供給開發者修改，在 webview 可以修改「allowsInlineMediaPlayback」參數，預設 iPhone 設定為「NO」，也就是強制播放影片時都是全畫面播放，如果設定為「YES」就可以在 webview 中直接播放影片，交給開發者自行配置。

相關連接 http://stackoverflow.com/questions/5054560/can-i-avoid-the-native-fullscreen-video-player-with-html5-on-iphone-or-android https://developer.apple.com/library/safari/documentation/AudioVideo/Conceptual/Using_HTML5_Audio_Video/Device-SpecificConsiderations/Device-SpecificConsiderations.html

Chrome default font size

Chrome 預設字體大小為 tiny. 也就是不受限制的縮小，但是今天遇到一位中國同事說 Chrome 安裝後預設最小字體大小被設定為 12px

下圖為我的預設環境

web 小觀念， id 自動會變為 global 變數

如同標題，只要用加上 id，基本上都可以直接 console.log 出來 dom element，除非你用其他變數覆蓋過去，小觀念。

Javascript URL parsing

這也忘記是從哪來的，沒記錯應該是 stackoverflow.com 上找到（有發現記得告訴我），這是個快速 parsing url 的方式，使用了 html 本身的功能來做 parser，效能上當然不用多說。

Log 變為模糊

此方式可將 inspect 打開後所看到的 log 變模糊，但不是每個瀏覽器都適用，目前測試 Chrome, Safair, Opera 可以正常運作。

禁止使用 iframe 讀取你的頁面

算是個小技巧，幫自己筆記一下，加上這行後別的網站就無法使用 iframe 的方式把你的網站 load 進來。

if (window.location != window.parent.location) window.parent.location = window.location;

iOS7 safari mobile minimal navigation bar

在手機上畫面基本上已經不大，又被討厭的網址列、上一頁、下一頁 等按鈕佔去了上方與下方一部分真的很礙眼，還好 iOS7 有解決了這件事，就是在 head 內的 viewport 加上 minimal-ui，如同下方的方式：

<meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1.0, maximum-scale=1.0, minimal-ui" />

加入 minimal-ui 前，上方的網址列以及下方的按鈕列都存在


加入 minimal-ui 後，上方的網址列以及下方的按鈕列消失，旨剩下 page title


點擊上方的 page title 後網址列、按鈕列才會出現，中間那塊加上灰色遮照來做區隔

Youtube api

Youtube 是個很棒的串流影音服務，也開放初完整的 API 提供開發者使用，在這邊唯一要幫自己筆記的一件事就是，找出影片的內容

首先是下面這影片，關鍵就是紅色 highlight 出來那段，這 11 碼就是影片的 id

http://www.youtube.com/watch?v=lAM3p_rp78Q

如果是要用 iframe 嵌入 html 中使用方式如下，也可以從上連結中找到"分享"找出

<iframe width="560" height="315" src="//www.youtube.com/embed/lAM3p_rp78Q" frameborder="0" allowfullscreen></iframe>

如果使用 GET 來送 http request 到下面這連結就可以看到完整的影片資訊

http://gdata.youtube.com/feeds/api/videos/8mKivE8WqI4?v=2&alt=jsonc

相關連結
Youtube
Youtube Docs

Backbone solve IE ajax cache result

一般來說 Backbone 在針對 model 送 ajax 到後端時使用方法如下：


但在 IE 會針對相同的 ajax request 做 cache，所以必須將 ajax 的 cache 設定為 false，在 backbone 必須要這樣設定：


相關連結
http://stackoverflow.com/questions/6178366/backbone-js-fetch-results-cached

sailsjs router regex

相信很多人都有在 sailsjs 的 config/router.js 中看到下面這段，這問題就是當 controller 與 static directory 衝突時 router 該如何處理，官方其實在下面這段有寫出解決方案，但實際使用上沒辦法正常運作。

// What about the ever-popular "vanity URLs" aka URL slugs?
// (you remember doing this with `mod_rewrite` in PHP)
//
// This is where you want to set up root-relative dynamic routes like:
// http://yourwebsite.com/twinkletoezz993
//
// You still want to allow requests through to the static assets,
// So we need to set up this route to allow URLs through that have a trailing ".":
// (e.g. your javascript, CSS, and image files)
'get /*(^.*)': 'UserController.profile'

如果想要達到相同的效果可以使用另一個方式如下：

'get /[^.?]+?': 'UserController.profile'

但這時可能會遇上另一個問題，原本 sailsjs 的 router 設計為 :controller/:action，所以如果是想要把所有 '/XXXXXXXXX' 都對應到 UserController 的 action，就沒辦法在 controller 的 req 拿到 req.param('action') 取得要對應的 action，因此可以將上方這段修改為：

'get /:action([^.?]+?)': 'UserController.profile'

修改完後只要是連到 '/XXXXXXXXX' 都會被指向 UserController 的 profile action，而 UserController.profile 的 req.param('action') 就會是 XXXXXXXXX 的名稱，如果是連到 '/logo.png' 等連結會被指向 static directory，這邊也建議如果要使用這種方式請把 profile 改為 index，由 index 來做處理，畢竟 profile 這字這樣使用不太恰當。


如果是想要只開放幾個特殊狀況才進行上面這段可以修改為：

'get /:action(profile|page)': 'UserController.profile'

這樣修改後會發現只有 '/profile', '/page' 會指向 UserController 的 profile，而 req.param('action') 也會拿到 profile/ page，其他的如果沒有 static file 就會被導到 404。


-------- update 2013-11-11 -------
其實這段 regex 跟原本的寫出來會略有不同，真正原因是 sails 會對這段 regex 作些調整：

如果你寫 /:action(*) 會被 sails 轉譯為「^\/(?:( YOUR_REGEX ))\/?$」，而「*」會被改為「.*」也就是所有字元都可以，這部份目前看起來是直接將轉譯後的 regex 對應到 expressjs 的 router。

-------- update 2013-11-11 -------


相關連結
sailsjs document - router

facebook page feeds

由於看到一些 feed 內容還不錯，但是每次從 RSS reader 看完後再手動儲存下來有點累(我習慣儲存在 google form)，雖然每次作一次這種複製貼上的過程中可以再多看一眼，但久了還是會累（已經蒐集了700多筆後...）

Facebook 的 page 有提供 rss feed 給其他網站使用，其提供的型態有三種 AOTM, RSS2.0, JSON，使用方式如下：

JSON https://www.facebook.com/feeds/page.php?format=json&id=246748395427671

ATOM https://www.facebook.com/feeds/page.php?format=atom10&id=246748395427671

RSS https://www.facebook.com/feeds/page.php?format=rss20&id=246748395427671

最後面所帶的 id 就是 pageId，如果不知道 pageId 可以到下方連結查詢，只要把 url 中的 'AppStore' 至換成你的 page 名稱

https://developers.facebook.com/tools/explorer/?method=GET&path=AppStore%2Ffeed

查詢結果會顯示 pageId 如下圖

以上已經完成了一大步，順利取得 Feed 來源，接來來就是快快樂樂使用 Google Apps Script 自動儲存到 google form 中 :)

相關連結
facebook developer
Google Apps Script

SlideNote new feature transition and themes

SlideNote 過去只有一個樣板，我認為字型就像是投影片的靈魂，沒有好的字型看起來就是有點缺陷，所以新增了 8 個字型與配色，以及 7 種過場動畫。

Screenshot


字型、配色：Default, Beige, Moon, Night, Serif, Simple, Sky, Solarized


Transition：Cube, Page, Concave, Linear, Fade, None


相關連結
SlideNote

http response \ufeff

前幾天遇上從 server api 拿到的 response 會在第一個字元收到 \ufeff，jquery 的 ajax 會直接 fail，但直接看 response 會發現 status code 一樣是200，json 的內容也是正常，但 ajax 就是會變成 fail。

目前查詢到的資料來看，這是 utf8(BOM) 的問題， IDE 的編碼在儲存時如果編碼為 BOM 會在第一個字元插入\ufeff，而\ufeff這字元是個特殊的空白字元，一般的 IDE 會自動把這濾掉，所以你將 response 貼上 IDE 想要檢查問題出在哪一般也看不到，建議使用 vim 來看，會清楚的看到這字元，或者 chrome 的 inspect 也會發現如下圖的紅點：


其實這問題看起來真的跟使用的語言無關，似乎與 IDE 關係比較大，從 google 搜尋看起來就是跟網路相關的語言都容易碰上（如下圖）


Nodejs 的 V8 會自動將這字元濾掉，除非你連續寫了兩個\ufeff，不然不會發生，其他語言可能就要注意一下，在發生這問題請不要懷疑自己寫的 code，應該先去查 IDE 的編碼，而這問題也不會是前端的問題，由 server side 處理更為恰當。

grunt-contrib-connect fake api with yeoman

依照現在 F2E 正夯的狀況，很多 front-end 都會希望不需要等 backend 先寫完 api 才可以接資料，或者要等 backend 先開出假的 api 後才能動工，最好的方法就是先確定好資料結構後雙方就可以開工，也可以減少 api 寫完後才發現沒辦法接好的問題。 yeoman 是個相當好用的前端開發輔助工具，尤其 liveboard 大量增加 f5/ctrl + R 的壽命，如果能再結合假資料 api 拿來測試那就再完美不過了。

立馬下載
git clone https://gist.github.com/7210042.git

使用方式 （好讀版）
Step1. 下載 redirect.js 到專案根目錄.
Step2. 編輯 Gruntfile.js

var redirect = require('./redirect');

...
...


connect: {
options: {
port: 9000,
// change this to '0.0.0.0' to access the server from outside
hostname: '0.0.0.0'
},
livereload: {
options: {
middleware: function(connect) {
return [
lrSnippet,
mountFolder(connect, '.tmp'),
mountFolder(connect, 'app'),
redirect('api')
];
}
}
}
},

Step3. redirect 有三個參數. rootDir 是假 api 根目錄. indexFile 是預設連結的檔案. headers 是 http response 的 header，範例：

/app
...

/api
/user
index.json
list.json
...

/Gruntfile.js
...

Step4. run "grunt server"
當讀取 url "/user" 會自動導到根目錄的 "/api/user/index.json"
當讀取 url "/user/list.json" 會自動導到根目錄的 "/api/user/list.json"


相關連結
https://gist.github.com/IskenHuang/7210042
yeoman

SlideNote - markdown makes slides

Markdown 是個很棒的編輯文件方式，尤其在程式文件嵌入原始碼也是非常方便，甚至坊間也很多專門做 Markdown 的編輯器，但是每次整理完文件如果需要再做出一份簡報同時就會造成很大的困擾：

1. markdown 要怎樣 copy/paste 到 keynote/powerpoint 上？
2. 基於理由一，乾脆放棄，開始問：「能不能直接用 markdown 來簡報？」

所以認為最根本的問題是「怎樣直接拿 markdown 做簡報」，方法很多，直接轉換為 ppt(powerpoint)/key(keynote) 檔、讓 markdown preview 為 slide show、直接線上轉換為 slide，這些想法都非常棒，但為了最快速解決「怎樣直接拿 markdown 做簡報」的問題做了現在的「SlideNote」

SlideNote 主要的目標：

1. 用 Markdown 直接產出 Slide
2. 完全使用 Markdown 語法
3. 線上編輯，線上產出

截圖 slide show


截圖 編輯 markdown 文件


截圖 首頁



因為快，所以很多東西都還不完整，歡迎隨時來亂玩它，有問題或建議首頁左下角有 feedback 可以馬上回報給我：）

相關連結
SlideNote

nodejs hosting service - openshift

從 nodejs 的 github wiki 上可以找到一個頁面為 Node hosting 上面有相當多的服務可以選擇使用，著要是測試用機器，所以幾個重點條件就是：

1. deploy 後立馬可以使用
2. 可以跑 nodejs 並且支援 0.8+ 的版本
3. 使用 Git 做版本控管
4. 免費(超重要)

基於以上條件目前使用過兩個服務：

1. heroku
2. openshift

這次先來介紹 openshift，oepnshift 是頂頂大名的 redhat 提供的服務，這次使用的是 openshift online，產品定位為 Public Paas，有支援語言：Nodejs 0.6+, 0.10+, JAVA, PHP, Python, Ruby, Perl, GO (註1)，或是可以直接在上面架設 Jenkins, Drupal, Wordpress 可直接開啟不需要自行 deploy。 openshift 官方還有寫了一套 Command-line client 工具來對 deploy 上去的 app 坐操作，關閉、啟動、重起、目前的 log 等，詳細可至官方查詢。

當然最重要的 openshift 符合我們所有的條件，並且免費的 Gear(instance) 可以開三台，如官網價錢：

Size	MemMemory	Storage	Recommended for	Cost
Small	512 MB	1-6GB 1GB expandable	PHP, Perl, Python, Ruby, Node.js, MySQL	$0.04/hour after the first 3
Medium	1GB	1-6GB 1GB expandable	Java, MongoDB, PostgreSQL	$0.10/hour
Medium (with JBoss EAP 6) Java EE6 Full Profile	1GB	1-6GB 1GB expandable	JBoss EAP	$0.13/hour

這麼佛心看到只能馬上跪下說聲「謝主龍恩」不然也不知道該怎麼辦，目前使用上除了 deploy 速度很慢（相較起 heroku），web 介面非常醜並且不人性化，常常找不到資料，官方文件看不太懂以外，其實還蠻不錯的，畢竟是要免費的測試機還是別太苛求。

目前就一點特別需要注意，deploy 上去後 port 與 root url 設定上與一般不太相同，必須修改如下：

port 必須設定為「process.env.OPENSHIFT_NODEJS_PORT」
root url 必須設定為「process.env.OPENSHIFT_NODEJS_IP」

以 sails 為例，local.js 必須修改如下


註1. 除了nodejs 外其他語言支援版本可至官方開發者中心查詢

相關連結
nodejs
github wiki
Node hosting
heroku
openshift
openshift developer center
openshift Command-line client
openshift pricing
sailsjs