【社群】意外找出沒睡飽時寫出的日期Bug

今天意外catch到一條Debug.Log，
雖然不影響正常流程，
但總覺得哪裡不太對勁，
沿著Log抽絲剝繭下去才發現，
原來是我之前寫的某個類似「每日登入」機制的部分寫錯了。
.
為了計算出隔天0時的日期，
我寫了像是這樣的代碼：

System.DateTime l_datetimeNextDay = new System.DateTime (i_dateTime.Year, i_dateTime.Month, (i_dateTime.Day + 1));

假設原始時間是2017/01/05 15:30:00，
它就會得出2017/01/06 00:00:00的結果，
這在平常都能夠正常運作，
但相信大家如果有睡飽的話，可能已經看出問題了。
.
那就是當日期進入本月份最後一天時，
會得出2017/05/31 + 1 = 2017/05/32的錯誤日期！
應該寫成這樣才對：

System.DateTime l_datetimeNextDay = new System.DateTime (i_dateTime.Year, i_dateTime.Month, i_dateTime.Day).AddDays (1f);

真的很慶幸我每天都在認真工作，
才能在今天這個日子檢查出這個Bug。

【社群】自己的要求自己做！

過去在當遊戲企劃的時候，
從網路和周遭學習到不少發生錯誤的案例，
因此當時總是會在企劃書中特別加註
諸如以下的事項──
.
「數值都要設置上限，防止溢位」
.
「所有介面按鈕都要禁止玩家連續點擊，
以防產生重複或矛盾效果」
（例如重複領取同一份禮物N次）
.
「購買道具時，必須先扣錢再給道具，
而且扣錢之後就要先記錄收到、再播動畫」
（以免玩家在動畫途中跳出遊戲而白白損失）
.
我覺得像這些都是很重要的事，
但當時的我因為只是企劃，
所以每多寫一項，就是工程師要多費一份心力，
因此總是對合作的工程師抱著一份不好意思和感謝。
.
現在自己當工程師，
這些要求自己都能做到，
再也不用不好意思了，
對於我這種務求謹慎的個性來說，真是安心啊！

【社群】算機率算到記憶體爆炸

最近勒索病毒猖獗，
大家都把Windows更新，做好防範了嗎？
.
這週終於進入最後一個系統——
「御神籤」的製作，
抽籤非常講究機率與期望值計算，
自然又到了必須把高中數學拿出來的時候了。
.
而我為了多人協作、雲端備份、版本控管等好處，
平常就會用Google雲端文件來取代Office，
誰知卻在這時候遇上了瓶頸——
.
計算的資料太龐大，網頁把記憶體吃光啦！
.
幸好最後把表格移到Office上就夠用了，
這樣就不用花力氣去簡化公式了，
科技始終是為了滿足惰性 (喂)

【社群】送審版相當順利地通過了

幸好事前有詳細讀過Apple的App規範，
送審版相當順利地通過了，
中間只被兩個小問題退回來過：

1.Apple人員找不到在哪裡消耗遊戲金幣，請我說明。
2.遊戲拍照沒有完整表達出App功能
（因為只是送審版，沒有要真的上架，我就隨便拍一張而已）

美術夥伴的進度也正急起直追，
離正式上架不遠了！