Peter

1. ** mockups 怎麼命名**
2. 管理 mockups

mockups 怎麼命名？

其實 mockups 的命名真的非常頭痛， 嘗試以版本號作為 mockup 名稱的結果非常悲劇。 版本號需要功能對照表，才能找到需要的 mockups， 若沒有版本號功能對照表，找 mockups 豈不是非常悲劇？

為什麼 mockup 的命名規則不能更直覺好懂呢？ 一目了然的名稱可以提升設計師找尋 mockup 的效率。 那麼，什麼才是一目了然呢？

其實我想的很簡單，就以網站的 Route 作為基礎， 例如求職者的履歷呈現頁面，就會以下方規則命名：

profile show.sketch

但是光這樣還不夠，因為 Sudo 網站本身又分成 WeStudent 與 Sudo， 兩者的樣式雖然接近，但還是有些許不同，因此在 route 前面再加上綴詞。

Sudo 的求職者履歷呈現頁面就會變成：

s_profile show.sketch

因為 sudo 的前綴太長，所以省略成 s。 而 WeStudent 則變成：

ws_profile show.sketch

當然，Sudo 與 WeStudent 網站有做手機版網頁， 目前沒有想到更適合的解法，只好再加上一個前綴：

m_ws_profile show.sketch 代表 WeStudent 手機版。

m_s_profile show.sketch 代表 Sudo 手機版。

如此一來 mockup 的名稱多了語意，設計師可以更直覺的找尋 mockup。

那麼要如何管理版本呢？

捨棄掉版本號的命名方式，要如何管理版本呢？ 只要在 Sketch 檔案中開出不同的 page，將 page 命名成版本號即可。 但目前我還是比較習慣以日期作為 page 名稱， 這樣就可以追蹤每一個時間點的設計稿狀態，達到版本管理的目的。

還是老話一句，版本號給 PM 與 工程師看，設計師要確保每一個階段的設計稿不要遺漏。

以 Route 切分檔案的隱憂

乍看之下以 route 切分檔案與畫面管理 mockup 是合理的， 但是一個網站不是由一個一個獨立的畫面組成，而是畫面串連成的流程。

將 route 作為切分檔案的依據會產生使用流程硬生生地被斬斷分割成細碎的小畫面， 舉例來說，企業用戶要徵才會有以下的流程： 1. 建立職缺 2. 編輯職缺 3. 管理職缺下收到的履歷 4. 查看求職者的履歷 5. 對求職者履歷管理相關後續動作

若是以原先的邏輯，這些畫面都會被切割成各自獨立的檔案， 過度分割畫面會讓設計師無法以宏觀的角度看使用流程， 更別說跳入使用者情境，畫出實用的 UI。

最終的 mockup 命名與分類

鑑於 route 切分檔案與 mockup 命名的隱憂， 切分畫面與命名必須考量畫面與畫面之間的相依性。

Sudo Ninjia Tsao Pin 表示 可以維持以 route 命名，但使用 tag 管理檔案。 但目前 Sketch 檔案無法標注 tag， 只好使用資料夾管理（不是很直覺）

Kalan

上個禮拜因為精神不佳的關係，在禮拜一的時候喝了 4 杯咖啡提神。原本已經對咖啡因免疫的我一下子超標太多，所以心悸將近兩天才好。這讓我開始檢視自己的身體。

認真覺得身為工程師，身體一定要照顧好，長期坐在電腦前面，在辦公室裡吹冷氣，如果不好好照顧的話，最後一定會得不償失，像上個禮拜我那樣。

DOM 節點操作筆記

基本上如果不是太複雜的節點選擇，我幾乎都會用原生的 js 去操作。雖然 jQuery 幾乎形影不離了，但是瞭解一下原生的 API 總是好的。 或許，可以參考一下史上最輕量 js 框架vanillaJS

Modal 的思考

現在主站的 Modal 越來越多，這篇文章總結了目前 modal 設計的趨勢，做了一些總結，還挺不錯的。

對於主站來說，我們的 modal 也會因為功能上的不同而有些許差異，所以在做 modal 的特效設計時（openModal closeModal），還是盡量不要綁 class 而是另外加上 attribute 的方式會比較恰當，來應付多場景的 modal。

Ramda.js

上禮拜聽到 Henry 興致勃勃的分享給我，稍微看了一下，就是 FRP 版的 lodash 嘛！這裡的 API 都還蠻實用的，而且完美符合 FRP 的概念，值得一用。

Vuejs 初探

Vue 給我的感覺很像在寫 Web component。vue-cli 甚至在裡頭幫你把 webpack 等設定都處理好了。對我來說是個很值得關注的框架。

不過學什麼不是重點，而是裡頭的概念是不是真的能解決問題，那才是關鍵。

Henry

React Native 白色螢幕閃爍問題

React Native 在大部分的情況下只會有一個 view controller，這個 view controller 被 render 出來之後，iOS 就會將控制權交給解析完成的 JavaScript bundle 去 render 剩下的畫面。問題是這個 view controller 在交付控制權之前，view controller 自己會有一個預設的 view，而這個 view 的背景是白色的。如果整個 app 走淺色調，那不會有什麼太大的問題。問題是 Sudo 自己的 app 走暗色調 (配合 logo 的配色所做的決定)，因此在暗色調的 splash screen 之後，會有很短暫的白色螢幕閃爍一下 (view controller 預設的 root view)，之後才進入 app 的主畫面 (JavaScript bundle 接手後 render 的畫面)。雖然閃爍的時間非常短暫，但還不夠短到使用者完全注意不到，因此這是一個勢必要解決的問題。

Changing the React Native RootView Background Color (iOS and Android)

照著以上教學的解法去做，的確能解決白色螢幕閃爍的問題。但另外一個問題是，在 iOS 將背景顏色改成其他顏色 (例如黑色) 後，進入到 React Native 階段後這個背景色會被保留下來，接著就會影響到沒有設定背景色的畫面 (黑色就會透過去，因為沒有設定背景色的畫面背景色是透明的)。我現在想到的解法是在 React Native 透過 NativeModule 去呼叫 iOS API 來將 view controller 的背景顏色修改回來。但問題是 NativeModule 先天設計無法直接存取 view controller，因此還要再研究其他方式。

Facebook SDK for React Native

第一次聽到有廠商建議將 SDK 放在 ~/Documents 底下，那我如果把 Git repository share 給同事不就把我自己的電腦的路徑全部展示給他看了？另外一點是每一次同步都要修改路徑位置，多麽不方便啊！？

「幹，同步失敗？又是 Facebook SDK！」

所以我決定使用 Cocoapods 來管理 Facebook SDK。Cocoapods 這一端沒有什麼問題，Pod 編譯通過、也連接得上、Xcode 也有正常辨識。接下來要做的是將 React Native 與 Facebook SDK 串接起來。Facebook 官方有開發一套 react-native-fbsdk，推薦使用 rnpm 安裝。安裝之後…然後就沒有之後了，因為 Xcode 抓不到 react-native-fbsdk 的 NativeModule。

使用 open source 開發專案等於跟開發者借錢賭博，借久了總有一天一定要還。

react-native-fbsdk 的開發者在 0.2.0 版時將 .podspec 移除了，導致 Cocoapods 再也抓不到 react-native-fbsdk，也就無法生成連結檔，進而導致 Xcode 無法辨識 react-native-fbsdk。詳情可參考 #210 podspecs removed?，幸好在 0.2.1 版本將這個檔案加回去了，升級之後一切就運作正常了。

Cocoapods 熱門到 GitHub 以為自己被 DDoS，可見 iOS 開發者對之依賴之深。斷然移除 .podspec 可能是不小心或是沒有認知到 Cocoapods 還是很多人使用的套件管理工具，無論是哪個原因，都是身為一個工程師不應該犯的錯誤。

JavaScript 真的快統治世界了，但是 還沒有。

請 Facebook 的工程師要有這一點的認知。

React Native 沒辦法串接 jest、flow 等 Facebook 開發的測試工具

讓人想砸爛一切的新發現。

React Native 因為特定原因 (可能是為了縮減 JSBundle 的大小，或是 iOS API 的限制無法導出對應的 iOS 介面，或是 JavaScript Core 有 bug 所以不能在 iOS 上使用特定的 JavaScript function)，實作了自己的 preset，然後包死在 react-native 這個 npm package 裡。當然有人覺得這是一件很蠢的事情，因為 jest 或 flow 等測試工具就無法正確的轉譯從 ES2015 轉譯出來的 JavaScript，遑論啟動測試。

其實還是有方法，你可以自己寫 jest 的 preprecessor，然後自己把 react-native package 裡的工具函數、轉譯程式 一個一個 抽出來接上，然後你還要面對可能會從任何地方噴出來無法辨識的錯誤跟原來專案無法運作的風險 (為了測試加上的新設定會污染專案的舊設定)。

React Native 太熱門了，而且大部分的開發焦點都放在 component 的設計上，結果連測試這個 基礎且重要 (fundamental) 的功能都做不完善，實在讓人不禁擔憂會不會踏上 ActionScript 3.0 或 ECMAScript 4 的後塵啊…

我真的不想要去用 Weex，強國人天生手賤喜歡放後門在人家的 app 裡面。而 Weex 如果沒有意外也是使用 JavaScript Core 去執行，那麼就一定要摻入 dylib 去連接 iOS 與 JavaScript，而這邊就很有可能藏污納垢了。你說知名廠商怎麼可能這麼幹？別問我去問百度啊！

光想到就覺得噁心。

Facebook 的 Test App 跟著開發者的帳號跑

所以 沒有分享 Test App 給其他開發者這件事。

假設…

1. 今天有三位開發者 A、B、C，分別負責開發 Web、iOS app、與 Android app。
2. Facebook app 的所有權在開發者 A 手上。
3. 開發者 A 自己建立了一個 Test App 來測試 Web Staging。
4. 開發者 A 將 Facebook app 分享給開發者 B 與 C。

那麼…

1. 開發者 B 與 C 看不到開發者 A 新增的 Test App，而開發者 A 也沒有地方可以將開發者 B 與 C 加進自己建立的 Test App。
2. 開發者 B 與 C 必須自己建立自己的 Test App，然後分別使用在 iOS Staging 與 Android Staging 上。
3. 開發者 B 與 C 要注意現階段 Facebook app 並沒有辦法針對欄位設定權限，所以 *如果開發者 B 或 C 動到例如 Callback URL 的欄位，就會導致 Web Production 的第三方登入功能無法運作*！

別看這一段短短的而且很好理解，Facebook 官方可是連加上去都懶得加上去。