這份心得主要是用來分享，
我和夥伴使用Unity開發、上架App至雙平台的過程中，
在程式與專案管理上遇到的特殊狀況與解法。
至於基本的做法，
就請交給Google與翻譯機吧！
首先說明一下開發背景吧！
這個案子是由我＆美術朋友「赫佐艾卡」共同發起的，
分工上就是程式由我負責、美術由他負責，
剩下的雜事誰擅長就交給誰。
原本我們想得很樂觀，
預計花兩個月左右將它完成並上架
（當時規劃的內容很簡單，就只有「點數計算」而已）。
根據不成文的「兩倍工時預估法則」──
「一個案子所花的時間，通常是預估的兩倍」。
我估計核心功能大約需要一個月完成，
然後加上一倍的時間作為測試、除錯、上架之用，
合計也就是兩個月。
但我錯了，「兩倍工時」指的應該是那些不在估計之內的「意外」，
必須保留多一倍的時間來應付它們，否則只要發生意外就一定會延遲。
最後我們花了多久呢？六個月！
自我檢討時，從日誌統計出來的工時大約如下：
核心功能開發（一個月）
追加功能開發（一個月）
多種插件的研究＆使用、雙平台商店設定＆反覆送審上架（合計一個月）
UI優化（兩個月）
宣傳等諸多雜事（零散地吃掉時間，難以計算）
也就是說，核心功能是如期完成沒錯，
而且因為撰寫時就做好完整測試、不欠技術債，
原本估的測試除錯時間幾乎沒花到。
而大量的時間，居然是花在優化UI上！
我們每修改出一個版本後，就會請人試用看看，
並且在一旁觀察使用者的反應，不給予任何提示。
我們藉此找出了不少UI問題，
例如使用者在某些地方會疑惑，
不曉得接下來該如何操作、不易分辨能否點擊的物件，
以及字太小、按鈕太小等問題。
每次改進完畢後，就會去找另一批新的使用者測試，
確保能夠得到全新的測試反應，
如此不斷改進，終於讓新的使用者也能夠順利使用，
而不需要刻意教學了。
這是我們早期的UI，與現在相比顯得陽春許多，
操作起來也很容易誤觸。
優化過後不僅變得漂亮許多，
能點擊的物件也都更加凸顯了。
（感謝朋友「聖淨之風」、「陳淯翔」、「TK」、「Zehe」提供的寶貴意見）
關於UI、UX的知識實在太多，
這邊先推薦一個網站，有興趣的人可以自行上網找更多資料學習：
Google Material Design
而關於我們在設計UI時，
幾個經朋友建議改善的點在於：
「凡是能操作的物件，儘量加上立體感（或陰影），形狀也特別點，
反之則平面化」；
「按鈕之下的背景最好單純點，以免太花而看不清按鈕」；
（這點我們其實做得還不夠完美）；
「當用戶可能疑惑，不知道下一步該點哪時，就應該要強調顯示該按鍵
（例如將「開始計算」和「返回」按鍵改為會閃爍」）
※太多閃爍物件的話會影響效能，因此用在刀口上就好。
而另一個吃掉大量時間的怪獸，就是求好心切（貪心不足），
添加了許多不在當初「兩個月」估計中的功能──
-讓用戶在計算點數時採用自訂規則，並且可以儲存多組設定，快速切換。
例如是否允許食斷、複合役滿，
還能夠判斷許多知名的地方役，如大車輪、八連莊、大七星等等。
因為每個玩家想採用的麻雀規則都可能不同，
如天鳳、雀龍門、麻雀格鬥俱樂部......各有自己的一套規則，
據我所見，目前市面上的所有麻雀計點App，都只採用自己一套寫死的規則，
所以我們相信這項功能，必定能為用戶帶來很大的方便。
-除了「胡牌點數」之外，還能計算「所有聽牌的種類與點數」。
這也是比較少見的功能，可以幫助用戶找出沒發現的聽牌，
以及快速判斷哪種聽牌得點較高、是否足以逆轉。
-收集美少女圖鑑功能（對，最初這款App是沒有美少女的）。
我們想讓App也陪著用戶一起成長，
而不僅僅是用過就丟的計算機。
而且用戶只要看看影片就能取得金幣，
可以完全免費地計算點數、收集麻雀乙女。
-四國語言切換
因為沒有經費將翻譯外包，故80%以上都是我自己查字典翻譯的，
後來兩位赫佐艾卡的朋友（賽巴、真誠）也協助了一部分，感謝他們。
卻碰到好幾個變態外國人騷擾...
英文這麼破還敢來把妹！（怒）
-存檔格式的設計與加密，防外掛修改記憶體，程式碼混淆。
由於是單機版App，邏輯幾乎都寫在客戶端了，
所以不太可能完全防止破解，
只是為了增加破解者的麻煩，延長版本壽命而已。
研究了八門、燒餅這種任何用戶都能簡單運用的記憶體修改工具之後，
針對它做出了基本的記憶體修改防範
（重要參數都不保存在記憶體裡，每次都重新宣告）；
也確認過我們的App被反組譯後的結果，
並將程式碼做過混淆，
但遺憾的是，免費試用的混淆軟體最後仍無法順利運作就是了。
延伸閱讀：
從開發者的角度談遊戲防弊（上）
從開發者的角度談遊戲防弊（下）
-顯示Android狀態列。
什麼是狀態列呢？就是最上方的網路、電量、時間顯示那一列了，
我相信這對許多使用者來說是很在意的事。
iOS要辦到很簡單：
Player Settings > iOS Resolution > Status Bar Hidden 取消勾選
Android在5.3版之後，此選項已被移除，必須用別的方法。
從網路上找到，我目前採用的做法
↓這邊就是狀態列了↓
使用時需注意，別把↑NavigationBar（導航列）↑也開啟了，
否則在hTC等部分手機可能會發生如上問題，
虛擬按鍵常駐而擋到了UI。
（感謝阿智學長、我爸和五伯父特別告知此問題）
-Android獨有的「Escape」鍵，防連點
Escape就是返回鍵，也就是上圖左下方那個白色返回箭頭。
我記得在Android的規範當中，有要求App的Escape鍵必須要有功能才行，
但既然要做我就想做到好，
所以先將所有UI之間的關聯性列清楚，
再設計成讓用戶每按一下返回鍵，就會回到上一層的介面。
再來就是當畫面中正在播放動畫時，要禁止任何操作，包括點擊返回鍵；
也要防止快速連點返回鍵或任何按鈕
（舉例來說，像是快速連點了5次購物，應該只視為1次）。
-使用了許多初次接觸的插件（但真的很實用！）
Unity Analytics - 資料分析後台
非常重要！
若沒有它的話，單機App對於用戶在手機上的任何行為，
幾乎可以說是一無所知。
有了它，即使是完全不自架Server的單機App，
也能夠記錄各種事件，
作為未來的改良參考。
收集到的事件大約4~5小時後會回傳到Unity的後台顯示，
例如DAU（每日活躍用戶）、MAU（每月活躍用戶）、
新增用戶數、留存率等等；
還可以自訂事件，將自訂的內容也回傳到後台。
當沒有網路的時候發生事件，
也會先暫存起來，等網路連上時再自動發送。
※據官方文件所述，自訂事件上限500個字元，
並且最多包含十個參數，但官方未提及的是，
每個參數也有上限100字（不論中英都只算1個字）。
我將自訂事件的參數名稱取成日期+版號+平台（至少可容納100字），
這樣一來就能自動將每天的Log，依平台及版本分類，
而不是像預設的格式那樣全部雜成一團。
而不是像預設的格式那樣全部雜成一團。
就像這樣，事件中包含超過100字的參數是無法傳送的，
僅僅剩下像是"Test110"這樣的事件名稱。
如果事件內包含字數超過500，則連事件本身都無法收到。
而100字當中，即使全是日文也沒有問題，
不會因為全形字就佔兩倍字數。
Unity Ads - 影片廣告插件
顧名思義，就是能在App中提供影片式廣告，
需注意僅限於iOS及Android平台中使用，於其他平台會Error。
分為兩種類型：
1.獎勵式廣告（不可手動跳過，看完後可給予用戶獎勵）
Advertisement.Show ("rewardedVideo", options);
2.可跳過廣告（用戶5秒後可手動跳過，不會觸發獎勵事件）
Advertisement.Show (zoneId, options);
可以在Unity Ads的Dashboard動態改變設定，
決定在播影片時是否靜音，而不需要更新App。
iOS和Android平台分開設置。
因此《麻雀點數計算乙女》是完全不採用這種的，
只有在用戶確定想看廣告（看完可取得金幣獎勵）時才會播放。
在Unity Editor上觀看測試廣告時，點擊操作畫面會穿透點到底下的UI，要小心。
實機上沒發生這種問題，
但為了安全起見，還是加一塊全螢幕半透明擋板（類似Loading效果），
同時也可以讓玩家在等待廣告播放前，明確地感覺到有點擊成功。
※似乎沒有防止連點，所以要自己加上防連點判斷。
技術上的提醒：
雖然預設Unity Ads會自動在Awake()載入遊戲編號，
但偶爾會發生沒載入的情形，所以還是在Awake()幫它載入一次較好。
像這樣：
#if UNITY_IOS
Advertisement.Initialize ("1234567", l_bAdsTestMode);//遊戲編號，是否為測試模式
#elif UNITY_ANDROID
Advertisement.Initialize ("1234568", l_bAdsTestMode);
#endif
廣告Server會自動判斷，每用戶每24小時最多觀看25次廣告，
如果想讓用戶看更多的話，只能再串接其他廣告插件了。
至於廣告能獲得多少收入呢？這因國家而異。
不過用戶看廣告所獲得的金幣價值，
通常是遠大於我們實際得到的廣告收益的，
這麼做還是為了讓用戶能夠完全免費使用，
而經濟上有餘裕的用戶，也可以直接購買金幣，而不需要看廣告。
例如中國明明觀看了最多次影片，結果一毛收入也沒有；
反觀歐美、日本的千次觀看收益高上這麼多。
雖然知道這點，但我們對海外的宣傳真是十分不擅長，
也不好意思去2ch之類聊天的地方打商業廣告，
順其自然的結果就是這樣Orz
明明是市面上最好的產品啊......
要是身邊有在玩日麻的朋友，請推薦他們使用《麻雀點數計算乙女》看看吧，
真的很好用的！
Unity IAP - 應用內付費，驗證付費是否造假
先填寫iOS負責人、稅務與銀行帳戶資料
https://blog.mowd.tw/p/793
http://coderanch.net/138
然後建立iOS App
設定售價與IAP項目
（建議透過Application Loader建立，介面更加人性化，亦可從文件批次上傳）
http://www.jianshu.com/p/033086546126
串接方式請參照Unity官方教學，
https://unity3d.com/learn/tutorials/topics/ads-analytics/integrating-unity-iap-your-game
而當中的Purchaser.cs
要初始化某項IAP商品時，使用的是「產品ID」而非「Apple ID」。
builder.AddProduct ("產品ID", ProductType.Consumable, new IDs
{
{"產品ID", AppleAppStore.Name},
{"產品ID", GooglePlay.Name},
});
這其實不太會弄錯，
但是當功能一直試不過的時候，
一個焦慮的工程師會開始測試修改所有能改的地方...
另外，由於Google Play的產品ID有特別規範，
需由小寫英文字母 (a-z)、數字 (0-9)、底線 (_) 和點號 (.) 組成，
且開頭必須是小寫英文字母或數字，
所以若想在兩個平台使用相同產品ID，則必須遵守此規範。
※需注意，Google Play的產品ID一旦建立，即使刪除也無法再次使用同樣ID！
IAP驗證
UnityIAP驗證官方說明
Unity > Window > Unity IAP > Receipt Validation Obfuscator
將Google Play的授權金鑰貼進去，按 Obfuscate secrets，
就會在專案中產生GooglePlayTangle與AppleTangle兩個混淆過的檔案。
（不要去改它）
畫面中塗黑處就是Google Play的授權金鑰
同時也必須將金鑰貼到Analytics的Dashboard，才能進行驗證。
之後再按照Unity IAP官網的說明，
將驗證用的程式碼加入Purchaser.cs，即可在用戶端付費時驗證收據，
避免用戶在收據上造假。
※官網說明得不夠清楚，
要記得在Purchaser.cs最頂端加上這行，引用該函式庫。
using UnityEngine.Purchasing.Security;
IAP商品上架
在Unity Editor測試購買IAP時，
若設定一切正確，就會直接通過；
但要在iOS和Android實機上測試購買時，還需要做下列準備。
【iOS】
必須先等App初次送審通過，
否則在iTunes Connect會是「遺失元資料」的狀態，
在實機上購物會顯示「驗證失敗」。
App送審通過之後，還必須將App內購買項目也送出審核
（勾選要送審的項目後，網頁右上角會有按鈕亮起），
下圖是送審中的樣子，要等它們通過才能進行測試購買，
否則只會因為找不到商品而自動取消購買。
送審時，每個平台需提供螢幕快照，
並且要足夠說明App內容才行（我曾經因為只提供一張而被打回票）。
只需要提供最大尺寸的版本快照，就可自動適用於其他較小的裝置，
也就是只需提供iPhone 6、以及iPad2大小的快照即可。
螢幕快照必須是 JPG 或 PNG 格式，且必須採用 RGB 色彩空間，72 DPI。
iPhone最大5.5吋 ＝ 縱向1242px * 2208px 或橫向2208px * 1242px
iPad最大12.9吋 ＝ 縱向2048px * 2732px 或橫向2732px * 2048px
這支宣傳影片是由「赫佐艾卡」製作初稿，
再由我的死黨「至尊星」幫忙優化的。
多虧他們的用心，讓App在商店上顯得更加豐富！
格式：M4V、MP4 或 MOV
容量：不超過500 MB
長度：15~30秒
FPS：30以內
分辨率：
iPhone最大5.5吋 ＝ 縱向1080 * 1920 或橫向1920 * 1080
iPad最大12.9吋 ＝ 縱向1200 * 1600 或橫向1600 * 1200
編碼：256kbps AAC
採樣速率：44.1kHz 或 48kHz
必須為立體聲，啟用所有音軌
參考資料：
Apple App Store App 預覽影片準則翻譯
測試裝置清單
將測試裝置的UDID加入開發人員裝置清單中，
裝置的UDID可透過Xcode取得。
（Xcode > Windows > Divices > 選擇連接上的裝置 > Identifier）
但我從App Store直接更新Xcode時一直失敗，
最後是去下載打包好的版本，
並且在解壓縮時，還必須將MacOS更新才行。
註：經實測iPhone 4不能更新至iOS 8，
而新版Xcode要求App最低只能支援到iOS 8，
即使在Unity中設定支援到iOS 7也會被強制改高的，
因此新的App都必須放棄支援iPhone 4了。
接著必須將測試人員加入名單中，
開發者帳戶本身也可以作為測試人員。
然後測試人員的信箱會收到一封信，要求去App Store下載TestFlight，
用它所下載安裝的App來測試（記得使用測試人員帳號登入App Store），
才能夠在沙盒環境下測試付費。
※若是使用Xcode直接將App安裝在手機上的話，
使用IAP購物會失敗。當初在這邊卡好久...
Unity現在有提供方法，不必購買iOS開發者帳戶即可先在裝置上測試App，
這樣會比較省錢，
因為iOS開發者帳戶是在付費通過後就立刻開始計時，一年到期，
等到要送審前一週再申請付費就好了。
完成付款步驟之後，再過幾天就會開始計時了，
並非如網路上某篇文章所說，還要按一個按鈕才開始計時。
iOS送審
官方說明文件
這就是Archive後的畫面，Validate和Export都在右上方
每次要更新版本時，
Xcode > Product > Archive，
成功之後Validate讓它先檢查一遍，
最後Export就可以輸出成.ipa檔，
然後強烈建議使用Application Loader上傳！
上傳後大約需要等10分鐘，就能在iTunes Connect中看到。
跨越了無數障礙，終於讓這個建置版本的「+」號出現，
真是令人感慨哪。
使用Xcode提交很容易出問題，甚至還曾經卡住了數小時，
原來是因為它的UI出問題，明明已經上傳完成卻不會刷新畫面。
其實上傳只需要15分鐘左右，
之後再將Xcode視窗縮到最小再打開，就會刷新了。
什麼鳥問題...
多虧網路上這位仁兄分享，才得以解決這莫名其妙的Bug。
就是這畫面讓我等了數個小時！
但即使Xcode顯示Upload Successful，
等了數小時也仍然無法在iTunes Connect上找到剛上傳的App。
最後改用
Xcode > Open Developer Tool > Application Loader
並且將IAP的敘述、審查資訊的螢幕快照也都補上
（這比在網頁上輸入IAP資訊更加方便許多，推薦），
否則在iTunes Connect的狀態仍會顯示為「遺失元資料」而非「準備提交」。
可是當遞送資料時，等了足足10分鐘才回傳告訴我
「商品敘述至少要10 bytes以上喔」
您下次可以早點講嗎大哥！！◢▆▅▄▃崩╰(〒皿〒)╯潰▃▄▅▇◣
iOS審核效率
我送審過多個版本，每次平均大約1~2天就審完（假日也照審不誤），
比起幾年前動輒審上一週，蘋果的動作真是迅速了非常多。
※據我觀察，他們常在台灣時間半夜2點左右開始審查。
若正在審查中，會顯示在App狀態上
建議先做好一個包含基本功能的版本就送審，
及早發現問題及早修正，
才不會臨到要上架時卻被連續打回票。
反正審過之後可以選擇不要開放給用戶下載，
有什麼次要功能，都可以等初版審過之後再追加。
iOS對上架的App有一套規範，開發前可以去查一下，
就不太會觸犯到他們的禁忌而被打回票，
例如在App中提到競爭對手（例如Google）的名字等等。
我只被打回票過一兩次，
原因是Apple需要瞭解，IAP購買的金幣在《麻雀點數計算乙女》中如何使用，
我回覆解釋完，他們就繼續審核了（不需要重新提交檔案）。
另外還遇到幾個Unity匯出到Xcode之後，需手動修正的設定：
即使在Unity設定過也沒有用，
還是必須手動再設定一次，將此處改為None，
否則在部分手機上可能會安裝失敗。
這邊則是Apple故意的，一定要手動重新設定權限，
才能使用相關功能。
我原本也沒有設定，直到我的膝蓋中了一箭
（Apple寄信告訴我必須設定權限）
【Google Play】
在此將App上架與設定：
Google Play Console（開發者管理網址）
否則會顯示如下錯誤。
並且發佈到Google Play的APK、與安裝在測試機上的APK，
兩者的Version和Bundle Version Code必須相同，這點iOS應該也是一樣。（未測試）
（在File > Build Settings > Player Settings設定）
PlayerSettings設定
Product Name就是安裝後顯示在App Icon下的名稱，
iOS最多顯示六個中文字、或12個英數+1個半形空格，
超過的部分將會被以「...」的方式省略顯示。
Android能顯示的字數較長（依機型不同也有差異），
故此處建議以iOS的六個字為準。
iOS會自動將Icon邊緣裁成圓角，
所以我們做了兩種不同的Icon分別給不同平台使用。
但iOS不支援（會被周圍像素自動延伸填滿，甚至不允許使用），
所以我們就把iOS會裁掉的部分用黑色填滿。
Android iOS
Version最多三個數字，例如1.0.0，超過將不會被iOS所接受。
Target minimum iOS Version至少要設為8.0，否則也會被Xcode強制改高。
※只要上架審核通過了，下次上傳的新版本，
Version、
Build (iOS)、
Bundle Vertion Code (Android)都必須比前一版大。
Android使用測試裝置測試IAP購物須注意：
1) 測試用的帳號，不可與上架用的開發者帳號相同。
2) 測試用的裝置，Google建議先「還原至原廠設定」，
然後要先以測試用的帳號登入，才會讓測試帳號被設定為主帳號。
「欲練神功，必先自宮」，
若不自宮，就不保證會成功啦，請自行嘗試了。
3) 將測試人員加入測試名單（僅限使用gmail帳戶），
讓測試人員透過「選擇接受網址」下載apk，
再收驗證信同意加入測試才行。
版本管理 > 應用程式版本 > 管理Beta版（或Alpha版亦可） > 管理測試人員
4) 在Google Play的App內測試購物是真的會付款，之後可以在「訂單管理」退款
記得測試購物之後，一定要馬上去退款！
像我有一次刷了一筆3000元，
隔了半天才想起來，結果...
...就晚了半天才退款成功，嚇自己一跳。
建議大家不要學我，如果等到信用卡帳單都結算了才想退，搞不好就沒辦法了。
順道一提，由於雙平台都會抽取30%的費用，
還要再扣除各國不同的稅率，
實際能從IAP得到的收入大約只有用戶付出的一半金額甚至更少。
IDFA（廣告ID）
以前要辨識不同用戶時，通常會去取得裝置的唯一編號，
但後來iOS和Android政策都傾向保護用戶個資，
所以雙平台最好一律改採用IDFA（廣告ID）。
它跟用戶裝置的唯一編號差別在於，
此廣告ID是無法永久對應裝置及用戶身份的，
僅用於此單一App，
而且一旦移除App重新安裝的話，又會改為新的廣告ID（更新則不會變）。
而這項功能在每次iOS App送審時，都會被詢問是否有使用，
有使用的話才會開啟此功能，當送審通過之後便能夠產生用戶的廣告ID。
僅限在iOS平台取得廣告ID：
UnityEngine.iOS.Device.advertisingIdentifier
iOS和Android平台取得廣告ID（Windows不可）：
Application.RequestAdvertisingIdentifierAsync (
(string advertisingId, bool trackingEnabled, string error) =>
{
Debug.Log ("advertisingId " + advertisingId + " " + trackingEnabled + " " + error);
}
);
正式上架發佈
Google Play會立即出現在商店上，
iOS則大約會晚個半小時～一小時。
如果要做宣傳的話，建議等確認出現在iOS商店上再做。
由於中國的網路長城，
不翻牆的話只能連接iOS App Store，
無法直接訪問Google Play和Youtube，
因此最好另外尋找中國用戶可訪問的空間。
影片我試了許多空間，有的甚至才剛上傳，
就被系統以莫須有的罪名自動屏蔽了。
最後是找到bilibili可以成功上傳，
不過在這之前還需要回答一大堆問題就是了。
不夠宅還不行呢！
而存放apk，供中國用戶自行下載安裝的空間就難找了，
現在因為實名制的關係，
幾乎全都要綁定中國手機、或者付費，
只有騰訊微雲免費又不綁手機，
提供10G的免費空間，但連結只能維持一週。
所以最後我們也放棄了，
如果有人知道在中國可用的免費空間的話，
可以留言告訴我，我會再補充進文章裡的，感謝您。
最後還有一些開發專案的心得，也順便跟大家分享──
版本控管
很重要，很重要，很重要，所以要說三次。
在本專案中，Unity幾乎只有我在使用，
因此我跟夥伴之間沒有同步專案的需求，版本管理起來算是很輕鬆。
但即使如此，將專案區分版本備份至雲端依然非常重要，
在開發期間內至少發生過四次，
我把專案改壞了而非得還原不可的情形，
幸好有做備份，只要幾分鐘就能救回來了，不然可是欲哭無淚。
先確認「最困難、最核心」的部分做得出來，並且要先做
例如我們做的這款App，目標是以「廣告＋IAP（App內付費）」收費，
提供「日本麻雀點數計算」和「抽籤收集美少女圖鑑」的單機服務，
都是先確認過做得出來，專案才正式開跑的。
否則若等進行到一半才發現無法克服的瓶頸，
會讓專案承受毀滅性的打擊。
再來就是從這些最核心、最難做的項目先開始進行，
不僅是為了保險，更是因為成員的動力在一開始最強，
若到了結尾的時候才來面對最困難的項目，
會更容易產生逃避、草草了事的心態。
分工與獎懲要明確
三個和尚沒水喝的道理大家都聽過，
多人合作時很忌諱權責不清、獎懲不明的問題，
一件事「沒人做」「出問題無人可追究負責」「做得好不知該歸功獎勵誰」
都不是好事。
所以我們一開始就講好職責及利潤分配，確實遵守。
並且一開始就在App中建立開發人員名單，根據實際工作內容更新，
如此能夠更直接地激發榮譽心、責任心。
※雖然職責區分明確，但我們做出重要決定時都還是會互相確認想法，
常常因此將點子優化得更好，
若猶豫不決時再由負責人做最後決定。
公佈開發人員名單的做法，即便會讓好的人才更容易被其他團隊看上挖走，
我也覺得這是每個人努力所應得的名聲
（反過來說，做不好的話也能從名單上找到是誰負責的）。
不過因為我們的案子並非上下雇傭關係，
而是朋友間的合夥關係，
所以就不採用獎懲的形式，
而是各自承諾每項工作的完成期限。
定期瞭解彼此的成果，對雙方都有激勵作用；
而若有成員的進度遲緩下來，
也能夠及早注意到，給予關心和協助；
逾期的人也會自發地請個飲料什麼的。
多虧彼此的這種「加分式」合作，
才讓這個案子持續六個月以來，
即便已經遠遠超出當初預期的兩個月，
兩人都還是不鬆懈地努力到正式上架的一刻。
下次分享日期：2017年9月
下次分享主題：PTT首家線上《ACGN股票》交易所上線啦！
沒有留言:
張貼留言