ocowchun

sudo postman

Sudo 的電子郵件服務

前陣子在玩 MJML ，這是一個有 RWD 功能的 Email Framework，而且可以做 custom component 。 Sudo 有很多種類的信件需要寄送，使用 HTML 開發郵件遇到的問題包含：不能使用 CSS，需要自行處理 RWD ，而且隨著信件的種類越來越多，主專案也變得越來越臃腫，因此一直有想要把寄信功能抽離出來成為一個獨立的專案，經過研究後完成了新的郵件架構。

當需要寄送信件的時候 Rails 會使用 AWS SNS 將資料與事件通知給 AWS Lambda ，然後 AWS Lambda 會將 SNS 傳給來的資料塞到寫好的 MJML 樣板裡面，然後呼叫 Mailgun 將信寄送出去。

優點

• 可以使用 MJML 開發郵件，開發速度快很多
• 使用 AWS SNS 發通知，除了寄信之外，以後要在相關事件加入其他功能也很方便。
• 使用 AWS Lambda 可以寄信，減少 web server 的負擔，也有更好的 scalability

缺點

• MJML 還不太穩定，常常會發生 Custom Component 跑版的問題
• 要想辦法處理 Lambda 執行失敗的情況。

目前使用起來很滿意，會繼續用這樣的方式來處理寄送信件的工作。

karote00

nodejs express mongodb

上禮拜為了玩 MJML 不小心把 nodejs 搞壞了，禮拜五的時候先安裝 nvm，並重新安裝舊版的 nodejs，然後在有需要用的專案內引用不同的 nodejs 版本，所以目前所有練習的小專案跟公司的專案都已經可以正常運作了

來 Sudo 之前，剛好要幫我姐的公司架形象官網（前幾天因為忘記繳 DigitalOcean 的錢，主機被 shut down 了….資料沒備份），所以學了一下 nodejs 搭配 mongodb 來實做後端，前端用 pure HTML Javascript，不過一直有其他事情卡住，所以 delay 到這週末才開始動工

目前學 mongodb 是看 http://mongoosejs.com/docs/middleware.html

而 nodejs 的 RESTful 實作是參考以下這篇 https://pixelhandler.com/posts/develop-a-restful-api-using-nodejs-with-express-and-mongoose

他的 ORM 寫起來有點像是 CakePHP，比起 C++/C# 來的簡化許多。但是因為太簡化了，當遇到問題的時候會有點不知道該怎麼解。目前 get 已實作成功，但 post 在使用 postman 測試的時候一直失敗，錯誤訊息的指向是說送出去的值是空的，但實際上我送的是類似 {name: ‘123’} 這樣的簡單資料而已，目前仍在繼續除錯中

Peter

Prott 的 30 天試用

Prott 是一個 prototyping 的網路服務， 由於是 Prott 業務拜訪介紹 Prott，覺得功能方面很多元， 所以就以小組方案試用了一下。

小組方案： 1. 兩個使用者 2. 無限個專案 3. 有 Wireframe 功能

但由於 Wireframe 目前我都還是畫在筆記本上，只有稍微玩一下。 比較多試用都是在 prototype 的功能上，那麼來看看 Prott 的功能吧！

開一個專案

image

建立專案時要設定 prototype 裝置，Prott 支援網頁、手機（iOS 與 Android）， 其實還蠻泛用的。

完成後製作的 prototype 和 wireframe 都會以該裝置的尺寸呈現。

Wireframe

image

進入專案面板， 有選擇新增檔案、從 Dropbox 匯入、新增 wireframe 等選擇。 前兩者匯入的是 .psd 檔案或是 .sketch 檔案， 方便設計師直接將 mockup 匯入到專案中。 前兩項稍後介紹，直接新增一個 wireframe 吧！

Wireframe 工具預設許多元件，例如：button、select box 等等， 可以加速製作 wireframe，對於快速建立模型非常有幫助。

Wireframe 是一頁一頁製作，完成後儲存， 完成的 wireframe 會直接加入專案中。

所以可以直接使用 wireframe 先製作一個 prototype 原型， 看看使用流程有沒有奇怪的地方。

Mockups

剛剛上述講到上傳檔案、匯入檔案， 方便設計師將製作好的設計稿匯入到專案中。

上傳檔案可以上傳 psd、sketch， 但是用過 Sketch 的設計師大多知道 Sketch 有許多好用的外掛， 像是支援 Sketch 上傳至 Zeplin 的外掛， Command + E ，輕輕鬆鬆上傳 mockup。 Prott 也不例外，它提供了 Prott Sketch Plugin。

設計師就可以決定自己要將哪個 Artboard 上傳至專案中， 而不用每次更新都丟一整包檔案到專案中。

備註： 使用 Prott 外掛時，要登入 Prott 帳號並選擇專案，完成設定後才可以順利上傳 mockup。

Prototyping

Prott 製作 prototype 蠻直覺的， 點選畫面後，在右側圈選出觸控區域， 就會出現一條線可以連接至其他的畫面並選擇轉場動畫與手勢。

** 備註： overlay ** Prott 的 overlay 功能讓元件以附蓋過去的方式呈現， 例如：模擬點選文字輸入區，跳出小鍵盤， 只需要將小鍵盤元件上傳至畫面，連結畫面時點選 overlay， 就可以設定 overlay 物件出現的方向與轉場動畫。 overlay 非常適合用於模擬 modal、確認刪除訊息、小鍵盤等覆蓋部分螢幕的元件。

另外，prototype 完成的專案除了可以分享， 還可以使用 Prott 的手機 app 模擬操作，用於開發手機應用程式非常方便。

小結論

使用限制

Prott 的手機應用程式多半用於呈現 prototype 專案， 其餘操作與設定大多需要使用 Prott 網站。

使用網站製作 prototype 有個非常難解的問題 — 網路， Prott 似乎無法離線使用， 由於公司的網路經常不穩，所以在設定轉場動畫與畫面連接時經常沒有儲存完全， 雖然有顯示連接畫面，但再次點選元件時卻發現完全沒有連接到畫面， 只有建立觸控區域。

除了有時候儲存連接頁面與轉場動畫會失敗， Prott 支援多裝置的泛用性，還有 wireframe 工具蠻適合團隊使用。

收費方案

image

在試用快到期的時候回首頁了看收費方案， 發現團隊方案（Team）的訂價蠻高的， 團隊方案（$74）： 1. 兩人使用（每增加一位使用者費用將會提升） 2. 無限專案 3. wireframe 工具

就團隊而言，若是專注開發一樣產品的團隊， 頂多開發手機版本、桌機版本、應用程式（iOS/Android）四到五個專案， 使用無限專案似乎有點太過浪費， 寧願限制專案數目，降低價格或是提升使用者數目比較合理。

Henry

cairn

前陣子分享了一款強化版的 StyleSheet react-native-extended-stylesheet，文件中並 沒有明確指出支援 nested stylesheet。雖然這一款 package 支援相對單位、樣式變數等看似更強大的功能 (其實這些功能靠 JavaScript 都做得到，個人認為沒有必要再浪費實作一次)，但我最需要的其實只有 nested stylesheet。另外也找到一款 react-native-nested-stylesheets，不過最後一次更新在 2015 年，React Native 本身變動的速度很快，止步於將近一年前的 package 有很大的機率完全無法使用。

不死心，最後在 awesome-react-native 再翻一次，找到 cairn。cairn 並沒有直接支援 nested stylesheet，但透過一些取巧的寫法，我們可以把它當作 nested stylesheet 來使用。

假設我們有一個 component

import { Text, TextInput, View } from 'react-native';

/* ... */

const component = () => (
  <View style={styles.component}>
    <View style={styles.inputLabel}>
      <Text style={styles.inputLabelText}>{'I am label of input'}</Text>
    </View>
    <TextInput style={styles.inputText} />
  </View>
);

Before cairn

import { StyleSheet } from 'react-native';

/* ... */

const styles = StyleSheet.create({
  component: {
    flex: 1,
  },
  inputLabel: {
    marginBottom: 14,
  },
  inputLabelText: {
    color: 'white',
  },
  inputText: {
    fontSize: 14,
  },
});

可以看到我們必須把所有的樣式手動地展開成一層，然後使用各種前綴字 (prefix) 去避免名稱衝突 (例如 inputLabelText 跟 inputText 都是在定義文字樣式，不過一個是針對 inputLabel 一個是針對 input)。這是 React Native 官方文件最一開始教給我們的寫法，就不再贅述。

After cairn

import { StyleSheet } from 'react-native';
import cairn from 'cairn';

/* ... */

const styles = cairn({
  component: {
    flex: 1,
  },
  input: {
    label: {
      marginBottom: 14, // 注意這一行
      text: {
        color: 'white',
      },
    },
    text: {
      fontSize: 14,
    },
  },
}, styles => StyleSheet.create(styles));

/* ... */

const component = () => (
  <View {...styles('component')}>
    <View {...styles('input.label')}>
      <Text {...styles('input.label.text')}>{'I am label of input'}</Text>
    </View>
    <TextInput {...styles('input.text')} />
  </View>
);

原始碼看起來似乎沒什麼問題，執行結果卻跟預期的不太一樣，I am label of input 多出了 14 單位的高度。回頭看一下 cairn 的文件，我們會發現如果有一個地方沒有理解會在之後實際應用時發生很嚴重的問題。

const styles = cairn({
  compA: {
    paddingBottom: 14,
    compB: {
      paddingTop: 14,
    },
  },
});

const CompB = () => (<View {...styles('compA.compB')} />);

在 SASS，如果寫 .compA .compB，我們會預期 compA 會有 14 單位的 bottom padding，compB 會有 14 單位的 top padding。但在 cairn，如果寫 styles(‘compA.compB’)，cairn 事實上會把它展開成 [styles.compA, styles.compB]，因此 compB 就會有 14 單位的 top padding 與 bottom padding，高度整整多出了 14 單位，這不是我們想要的結果。

要避免這個問題有很多方法，我個人是採用 所有樣式必須完全互斥 的程式碼規範解決。我選擇保留 component 與 container 兩個名稱，然後在需要明確指定 擁有子 component 的 component 樣式 時使用它們。

const styles = cairn({
  compA: {
    component: {
      paddingBottom: 14,
    },
    compB: {
      paddingTop: 14,
    },
  },
});

const CompA = () => (<View {...styles('compA.component')} />);
const CompB = () => (<View {...styles('compA.compB')} />);

這樣 CompA 的樣式就不會污染到 CompB 的樣式了。

React Native <View> 預設背景色

React Native 的背景預設沒有顏色，也就是 透明 (transparent) 背景，而 iOS 的底色預設是白色，這也就導致開發者會有一個錯覺，認為 <View> 的背景是 白色。一般我們不會去注意這件事情，但如果有使用 <Navigator>，在畫面切換的瞬間可能會發現有 下一個畫面在滑動的瞬間破損，卻在到定位後又恢復原狀 的情形。此時我們會下意識地去找是不是下一個畫面有問題，然後開始去猜測是不是有 component 繪製地太慢導致掉幀？還是有 props 重複傳遞導致畫面又多繪製了一次？

事實上問題的確是出在下一個畫面，但就只是因為我們沒有注意到下一個畫面最底層的 <View> 的背景色不是白色的這個事實而已。為這個 <View> 加上白色的背景問題就解決了。

Override React Native Logging Function for Crashlytics

從很久以前就為 React Native 掛上 Crashlytics 了，但每次只要在 production 出錯，回報的永遠是 RCTFatal，然後你就要去看詳細的 log 慢慢爬到底為什麼出了這個錯。另外一個很難過的地方是 error 也因此無法分類，因為都會被歸類在 RCTFatal；這也導致錯誤很難追蹤，因為你會以為同樣的錯誤又發生了。但它們明明就是不同的錯誤。

Add Crashlytics to your React Native iOS app 這篇文章會教你怎麼 override React Native 的 logging function，讓 JavaScript 的錯誤可以正確回報回 Crashlytics。至於成效如何還是未知數，因為我掛上去之後到現在還沒有發生錯誤可以讓我檢驗成果。