Loading...

Calendar Task

使用過大量的 todo app 後發現日曆對於我來說才是最重要的，對我自己來說工作上有公司的任務管理系統，所以剩下的只有時間管理，日曆本身就是最好的時間管理工具，但總不能把我幾點要做什麼都能通過畫上一段時間來處理，畢竟在公司除了會議以外，很少有明確時間（當然會以大多也無法準時），一項任務也無法保證能在確定的時間完成，這點也是為什麼 Todo app 與日曆僅能部分整合在一起，因此也讓我開始找尋更好的工具輔助；找工具前首先要明確需求，經過當前的狀況列出了幾點：

1. 最簡單的 Todo list (打勾就算完成)
2. 能與日曆整合
3. 有 Tag 或類似功能
4. 有搜索

從以上需求來看 Fantastical 已經能夠很好的滿足，並且我也使用了多年，但有個最痛苦的是用深了以後開始很亂，並且 Fantastical 沒有 Web、Android 版，這點讓一位 Web 愛用者很不舒服，後來開始找到了子彈筆記 Bullet Journal，有紙本、筆就可以完成，同時也有很多變種，Google 一下就可以搜到很多，在此就不介紹。

從子彈筆記開始讓我思考，如果這概念能夠與日曆結合確實能夠達成我要的需求，上述的幾點中除了 1 以外基本都可以完美支持，Tag 可以做為關鍵字搜索滿足，因此我定下了幾個簡單規則來讓日曆上也可以使用子彈筆記：

1. 一個 todo 一個全天事件
2. > 開頭為未完成任務
3. >< 開頭為已完成任務
4. 使用 ! 表示優先級，P1 !!! P2 !! P3 !

範例：
* > !! 201902月報 - 未完成 P2 任務
* >< !!! 201901月報 - 已完成 P1 任務

這樣做之後有幾個好處
1. 日曆就像是看板(Kanban) 一眼看過去就知道當週有哪些任務以及會議
2. 定期重複事件天然解決，如果有細節可以直接記錄在日曆事件上
3. 100% 跨平台，Web 版也有很棒的 Google calendar 可用
4. 周邊工具非常多，IFTTT, Google App Script, iOS 有 shortcuts 可以協助你做好各種自動化以及生成報表
5. 能夠解決公司數據安全問題，一般公司都有自己的日曆的服務

但這樣只能解決小、單一的任務，如果有長期的任務還是不好管理，這時候就會有兩種方式，如果是公司的事就直接使用公司的項目管理工具，個人我是使用 Bear 配合 Markdown 可以快速的整理出完整的計畫，當然這就可以看個人習慣。

如果有人對於 IFTTT, Google App Script, shortcuts 的應用細節有興趣歡迎直接聯繫我 :)

CMS Next

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

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

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

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

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

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

以人為中心的管理模式

這陣子打算在團隊中引入敏捷開發，在推進過程中受到了些阻力，確實也是些不同的觀點值得參考，整件事背景源自於某個產品忽然人都被抽調走，由原本的 8 人剩下 2 人，試想原本 8 人的工作變成兩人來承接該怎麼辦？

先來看看原本 8 人的配置方式，每個功能指派給 1 個人負責，把整個系統拆成 8 大功能，好處是任何功能出錯了都可以立即找到對應的人，對於每個人都有長期可延續的事，並且也可以開始學習規劃自己的產品；看似非常棒，並且這模式也跑了 2 年之久，但這種模式在 KPI 的壓力下就會開始變成非常詭異的東西。

產品主從關係沒了，每個功能負責的人都認為自己是主，就像一場電影中每個人都不顧劇情一直搶鏡，其中幾個角色的搶鏡能力不同還是可能出現幾個主線劇情出來，可以想像觀眾的感受是如何，當然這也可能是種特色，但這種特色作為個長期的產品來看簡直無法想像，首先影片好不好看完全取決於角色，如果角色間還存在職級、匯報關係可以演的比起鄉土據還狗血。由人的能力自然競爭出優秀的功能看似很正向，確可能造成因為人的能力不同，某些淺在重要功能就這樣被搞砸而造成走偏。

KPI 角度來看確實在 8 個人各自負責獨立功能的時候很好寫，站在管理角度也很好打分，然而管理者放任這種發展就是對產品的不負責，變為以產品開發者為中心，好聽點叫由下而上的工作模式，實質造成產品發展與人強關連，並且產品功能間不互通，某個人休長假、轉換崗位、離職等因素都會造成產品各種淺在風險。

收回原本的問題，產品維護的人由 8 -> 2 依照原本的邏輯繼續走下去會變為把 8 個人的事拆成兩半，然後還是一樣各幹各的，頂多是出現重要緊急的事才會有合作的時候出來，產品自身仍然出現多條行進路線。我想法是把兩人手上負責的所有內容改由一人統一負責，由一個人來規劃產品，可以讓每個人盡量做相同方向的事，但優先級是以整個產品來思考而非單一功能，以用戶需求唯出發點而不是以功能該如何支持用戶。

每個產品需求新增的同時必須來思考如何刪除，尤其是容易跟業務掛勾上的產品，業務邏輯隨時在變，然而一個不小心可能產生大量歷史業務邏輯在系統中，長期下來就形成了技術債，嚴重的話就會變成系統重寫。

屁話一堆...簡單總結就是
1. 產品的走向應該統一規劃，而不是依賴每個人負責一小部分，管理者必須把產品功能、開發流程疏理清楚
2. 傾聽用戶的聲音，明確產品定位，業務邏輯必須抽離主架構中
3. 上新功能前先想好如何刪除，確保產品核心功能不受影響

國泰世華銀行

國泰世華銀行從我開始上班以來就幾乎是一直是最常用的選擇，也因為在趨勢時期更是因為公司長期與國泰世華銀行合作，因此在兌換外幣等服務上甚至免手續費，所以後來也慢慢把其他銀行結清掉，全部統一到一個銀行來，使用上也很方便順手。

但是我申辦的是 combo 卡（信用卡、悠遊卡、提款卡），因為這卡質不是很好，因此常常會有上面塑膠膜脫落，嚴重點讓卡片都有問題，因此需要換卡，過去大多時間待在台灣其實還算方便，但是現在只有少部分時間帶在台灣，因此換卡這事情變得格外麻煩，首先換卡需要先致電銀行客服幫你轉到卡片相關部門，在確認後你必須把卡片先寄回銀行指定的地址後新卡才會發放給你，新卡必須再去國泰世華銀行 ATM 開卡，開卡同時需要一個 4 位數開卡密碼，如果你不是在銀行分行開卡就必須找到上次開卡時候的4位數密碼。

問題來了，現在大多時間不在台灣，因此換卡只好直接去分行直接把卡片交回給分行櫃檯，等收到卡後再開卡，但是…把卡片交回前已明確告知我馬上就離開台灣沒辦法等到卡片送回來，並且下次回來就是過年前，因此卡片必須要可以用，不然過年就哭哭了，行員表示沒問題後就開始悲慘的開始…

2/6 晚上大約11點多到家後馬上衝去銀行開卡才知道需要開卡密碼，並且開卡密碼是什麼我根本不知道，並且銀行早已全關，隔天就開始過年肯定沒辦法到分行處理，在 ATM 旁開始查國泰世華銀行客服電話後找到 ”02–23831000”，連續打了兩次都馬上被接起，然後就沒聲音，回家後馬上改撥打 ”0800–818–001” 總算語音有接了，但是客服等候根本沒人接，也不知道還要排多久，等了兩次 10 多分鐘後最終放棄，隔天再試。隔天一早撥通後客服表示：「這開卡密碼如果要重設一定要本人到分行櫃檯，現在必須要等年後才可以處理」，FXXK!! 難道我必須要過這沒半毛錢的年？這將會是有生以來最難忘的年….

到這邊有幾個問題點： 1. 當時到分行換卡為什麼沒告知必須要有開卡密碼？ 2. ”02–23831000” 這客服電話壞了為什麼還要擺在網路上 3. ”0800–818–001” 這語音為什麼不能讓等候的人知道前面還有多少人在等？如果太多我就換個時間再撥打 4. 國泰世華銀行不光 ATM UI 設計不良，網站也是原始人等級，各種訊息引導簡直爛到不行

後來因為太火大就寫信到客服，很開心的 6 天后電話回復了，告訴我兩件事： 1. 開卡問題只能重回分行辦理 2. 可以幫你先把卡片的預借現金功能開啟，讓你先有現金可以用

聽到這更火大了，原本只是知道我需要過一個窮苦的年，年後可以去分行解決，現在還可以預借現金，然後再來還利息就好，這樣銀行更賺錢 ^.<~* (啾咪)，神經病！客服還再三跟我說這方案很好，馬上就有現金可以用，解決我的問題，這真的有站在客戶的角度了思考該如何處理問題嗎？還是只站在銀行的角度處理？

現在滿腦子只有該如快速的結清戶頭，並且把以前的代扣快速轉移到其他戶頭，完全不在乎如何解決卡片問題，感謝客服、感謝分行重辦卡的櫃檯，對不起沒辦法幫貴公司賺錢，並且讓我過了這難忘的過年。

記帳

記帳是個好習慣，長期下來可以知道到底過去花了多少錢，未來有什麼改進空間，有了記錄才知道該從什麼地方開始節流，不僅是幫助自己也是幫助家人。

記帳最大的敵人就是懶惰，往往是懶惰殺死了記帳，就從懶惰這點看來最大的問題點就是工具，想想大學時代買了 MAC Money，還是從露天拍賣上買的，現在光想想就不可思議，當時遇到最大的問題就是必須在 MAC 上使用，外出也不太可能吃完馬上掏出 MAC 來記帳，每天晚上回家後開始記著回憶錄，雖然是很不堪的方式，但也確實讓我知道花在零食、飲料的花費有多少，一個月減少下來就多了 2k 左右，一年下來也省了不少，MAC Money 就這樣陪伴我到當兵結束。

後來買了第一隻 iPhone 開始使用了 cashbase，有效解決了要回家才可以寫回憶錄的問題，並且把MAC Money以前記錄過的一起匯入，並且還有 Web 版，讓我隨時隨地更新一些小到不行的流水帳，可以讓我在微薄的薪水上得到良好的控制，但馬上遇到下一個問題，cashbase 必須有網路才可以記帳，記帳後雖然有 Web 可以很清晰的查閱，但始終無法突破手機當下沒網路的點，在無法忍的狀況下開始了查詢新的方案，並由這次經驗知道符合我的記帳習慣軟體該具備什麼：

簡單操作的介面，最好一打開就可以記
手機上必須有 App，最好也有 Web 版
可以建立支出、收入分類
區分多個帳戶，每個帳戶必須支持獨立的貨幣
可以導出過去記錄的數據，避免被這軟體綁架
App 絕對要支持沒網路下仍然可以正常運作，到有網路狀況下自動同步
有報表、圖表
可以搜尋、fliter 出過去的消費記錄
預算功能，給自己每個月預算，當超過後能提醒，預算最好還能針對支出類別分別計算
支持多國貨幣，並且能直接展示出日/週/月/年等消費（直接以匯率作為計算）

經過這一連串要求後最後選擇了挖財，Web/iOS/Android 都有 App，並且在支持以上功能，尤其在多國貨幣上真的幫上大忙，手邊常常有美、日、人民幣、港幣、台幣流動，能夠同時支持真的是非常方便，並且也把過去在 cashbase 記帳一併匯入，可以讓長年的累積不中斷，挖財最大問題就是 90% 功能是不需要的，裡面為了深入分析你的花錢狀況甚至常常會要求你把銀行帳戶做綁定，或是信用卡，常常會推銷給你一些用不到的理財產品、基金、保險，這些確實讓人很頭大，但在我的需求基本用途上真的是幫了大忙。

時代不斷在演進，過去需要人工記帳的部份現在也讓我也新的想法，在杭州食衣住行 70% 以上都可以用支付寶，小到路邊攤，大到各種便利店、超市、高級餐廳都支持，所以一般出門也很少在帶錢包，支付寶上所有花費都已經幫你分類好，或許未來也不再需要記帳這行為也可以知道過去的消費習慣。

這邊簡單分享一下當前記帳的方式，其實就記住兩個要點：簡單、快速，這工具要讓你快進快出，最好可以不需要思考，因此在支出上主要分類為：

禮物
醫療/健康
娛樂
1. 一般娛樂
2. 電影(因為太常看，長期下來也是不小的花費)
3. 旅遊
吃飯
悠遊卡/各種電子儲值卡
住家/生活繳費
1. 一般住家、生活
2. 手機電話費
3. 電費
4. 水費
5. 瓦斯費
6. 住家網路費
7. 房租
交通
1. 一般交通
2. 自行車(因為太常買自行車零件…因此需要獨立出來)
服飾、搭配
教育
3C
其他

其中幾個點特別重要

吃飯、交通(Uber/機票/火車票)非常常用，因此可以建立出快速模版
悠遊卡、儲值卡類，當已經儲值進去後的花費就千萬不要再另外記，不然記錄上會變得異常複雜（例如你儲值 100 然後用悠遊卡買了一杯 20 元飲料，是要記兩筆還是一筆？）
銀行間轉帳最好也記下來，或是把悠遊卡/儲值卡類的也當作一間銀行來記錄

收入部分就是簡單記了，基本上就分三類”薪水、銀行、其他”，其中薪水不需要多說，銀行這分類是偶爾有比較大筆的利息收入等再記錄，基本上也可以省略，其他大概就像是超爽 der_撿到 100 塊，或是意外參加抽獎中獎類的，基本上就是這些。

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

evernote export to apple notes

過去都是用 Evernote 很長一段時間，但我唯一使用 Evernote 大概也就是筆記，還有些簡單的紀錄，剛開始還有在使用 web clip 功能，後來發現 web clip 會讓搜索結果變得很複雜，真正想找到的筆記反而都不在搜索結果前面，最終還是把 web clip 放到 pocket，並且後來 Evernote 功能越來越複雜，90%以上功能都是我不需要的，也因為這些功能讓整體變得更複雜，尤其是 iPhone 上的介面，在 5s 內容的可視區域真的小到不能忍，只是想要單純的筆記在使用 Evernote 讓我感到負擔沈重...orz，難怪 Evernote 會跳出來說所有用戶平均使用我們功能的 5%，但是每個人的 5% 都不一樣（總感覺這句話似曾相似XD）

由於很巧的我所用的裝置都是 apple 的，所以後來嘗試一段時間後就改用 Apple Notes，iOS 9 後 Apple Notes 做了很大幅度的升級，提供了匯入各種不同的格式以及可以畫畫等功能，並且球員兼裁判的 iCloud 可以做到無縫快速的同步 iOS、MacOS 平台，雖然現在同步還是很掰咖，很常發生同步錯誤造成產生兩個 notes，以及離線同步常常發生問題等，但就以我的基本的筆記功能還算堪用，比起 Evernote 來說簡單很多。回到資料問題... Evernote 原本的筆記怎麼辦？還好有人寫了這一段腳本來把 Evernote 內容同步到 Apple Notes 來，使用方式也很簡單：

打開 Evernote MAC app
選出你從 Evernote 要同步到 Apple Notes 的 notes
打開這腳本，然後按下執行，完成後會跳出提示

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 來配置，但是...網路上幾乎是找不到相關的文件或是不完全，最終找到幾個簡單的語法可以來做這調整，可以參考以下的寫法

note

難得就這樣忽然又有感而發，想把這一切記錄下來給未來的我。

來大陸快滿一年了，也漸漸開始熟悉這環境、文化、生活步調，在這與全世界一樣，唯一不變得就是變，只是變的有點超乎預期的快，在我試用期間就換了三個老闆，每個老闆的風格都不盡相同，唯一能不變得就是找到自己的舞台，盡力的表演。

互連網（網路）在這真的是熱到不行的詞，每個人都像有信仰一樣的崇拜，很有趣的沒人知道他該是什麼，該怎樣做，每天都有新的解釋，新的結合。從線上到線下，一步步的走入我們的生活，但真的有人考慮過充滿科技的生活是怎樣嗎？至少我是不願意的，某些層面還是希望能保持簡單。

從來了之後真的與身旁同事學了很多，既使是剛實習轉正的也是有相當多值得學習的點，對於事情的專注、效率真的很厲害。這近一年來讓我成長很多，過去所期望的舞台我找到了，找到隨便都可以有數千萬人的環境，證明不是我不行，而是沒被用對地方，回頭看到過去做的東西真的有點可笑，代表我又成長了，但真的得到後反而產生了點空虛感，就好像比賽理所當然衝到了終點卻不知道接下來該怎麼辦，是阿！我的下一步是什麼？有了家庭後的下一步又會是什麼？

卡在瓶頸的日子感覺快過完了，有種快要突破出新世界的感覺，30 而立，40 不惑，感覺是需要再加把勁，已經明顯感覺自己變老了，要在有限的歲月做出點貢獻才行。

Mi Band review

拿到小米手環剛滿一週，來分享一下使用心得，其實整體體驗上還算不錯拿到手環前覺得手環功能只有記步有點失望，因為手機本來就有使用 moves app 來做整體記錄，感覺有點雞肋，但使用後改觀很多，這也是我的第一個穿戴式裝置。

優點

睡眠記錄功能很滿意，讓你知道淺眠、深度睡眠的時間，也讓我知道深度睡眠超過4小時整天精神都很好，如果不足三小時就會非常有沒睡飽的感覺
來電提示，因為手機大多時間都是調整為震動，走路時放在口袋也常常會漏接電話，這時候手環震動提示就很方便了，又或者像在家中常常手機放著充電去做事情，就發現提示功能的好
續航力，目前使用一週使用電力 40%，這點真的很讓人驚訝的好照這樣兩週充一次電綽綽有餘

缺點

剛拆開手環要跟手機配對的體驗上有點失望，在配對上後手環並沒有個提示告知已經配對成功或已經開始正常運作
在登入小米帳號這段遇到困難，後來才發現台灣註冊的帳號在大陸要登入必須要翻牆後才可以登入…這應該是遇到最大的挫折
介面上的列表文字感覺偏上 2px，應該是文字的基礎線對齊中央而不是依照字體對齊，但懷疑是多國語系的問題，由於習慣用英文介面，對中文優化後並沒有針對其他語言、字體優化
iPhone 开始异常的耗电

windows break line ^M in unix

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

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

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 中直接播放影片，交給開發者自行配置。

iOS AFNetworking error 1005

Error Domain=NSURLErrorDomain Code=–1005 “The network connection was lost.”

When you got this message can restart your simulator to solve this problem.

Chrome default font size

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

下圖為我的預設環境

IE6,7 calc 解決方案 expressions

過去支援 IE6, 7, 8 在 CSS 上少了 calc 這個好用的功能實在很不方便，今天才知道原來在 IE7 以前的版本其實是有類似的東西可以解決「expressions」

微軟官方已經表示不再支援 expressions，但在 IE7 前還是可以使用 http://msdn.microsoft.com/en-us/library/ie/dn384050(v=vs.85).aspx

使用方式也與 calc 不太相同，在 expressions 寫的是 javascript，官方給的範例如下： <DIV ID="oDiv" STYLE="background-color: #CFCFCF; position: absolute; left:expression(document.body.clientWidth/2-oDiv.offsetWidth/2); top:expression(document.body.clientHeight/2-oDiv.offsetHeight/2)"> Example DIV </DIV>

詳細範例可以參考： http://msdn.microsoft.com/en-us/library/ms537634%28v=vs.85%29.aspx

nodejs run coffeescript via javascript

CoffeeScript 一直都是我很愛用的語言，但使用上常常需要先 compile 成 javascript 才可以執行，如果是 F2E 的還好，畢竟在出 build 過程中直接 compile 就可以，但 nodejs 上這樣感覺有點怪，能夠直接跑 coffee 當然是最好，好在 CoffeeScript 1.7 後有了這項功能。

首先必須在專案中安裝 CoffeeScript

npm install coffee-script --save

安裝完後在程式進入點如下，其中 './lib/main' 就是 './lib/main.coffee'，之後的檔案也就直接使用 CoffeeScript 來撰寫就好

require('coffee-script').register();
require('./lib/main');

相關連結
CoffeeScript

Mac OSX Yosemite window close button

Yosemite beta build 裝了以後發現 UI 不少怪問題，但其實都感覺還好，視窗關閉（最左邊紅色）按鈕感覺歪歪的，但實際上放大後卻是正的

平常看的樣子，感覺向左偏了 1px

放大後

感覺應該是圖縮小後因為 pixel 是偶數所以一定要偏一邊，因為圖片太小所以感覺特別嚴重

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

javascript 強轉 boolean，數學運算

一些小小的 javascript 數學運算，第一個是快速的無條件設去的方式，但是用 "~~" 開頭會在 jslint 被擋下，雖然是較為快速，但使用時還是必須考量一下整體的 coding style，下面的是把變數強轉為 boolean，這也是個更快速的方式，但一樣會被 jslint 擋下，斟酌使用。

訂閱：文章 (Atom)

框架