IT Knowledge Base

01. 又是疫情惹的問題，每年的Annual Dinner公司決定不再大攪，但換來的是Deposit變成外賣的員工飯盒。要求玩法很簡單，固定數目的飯盒，由參加者以先到先得獲取。

02. 第1個版本。想到要由任何參加者都可以簡單參與，很快就利用ddns.net了設立一個對外網站，以便只要參加者可以上網，就能參與活動。

03. 考慮1：為避免參加者按了網站連結，填寫了資料及選擇飯盒後，但被告知所以飯盒已估清。所以只要參加者一按網站連結，程式設計便第一時間告之是否仍有可選擇的飯盒。好處就是保證參加者填了資料一定選到飯盒，壞處就是只要有『高手』一次過連按了85次網站連結(但沒有輸入任何個人資料或直接關閉瀏覽器)，其他參加者就少了一個飯盒選擇。防君子是我喜歡的選擇(其實反正防不了高手)，用簡單的PHP檔案管理，當參加者進入網址，飯盒數目減一，再儲存回檔案內。

04. 考慮2：基本想法有了，用HTML FORM直接將參加者輸入資料及選擇的飯盒，經程式儲存到網站檔案內。但『高手』如果按瀏覽器上頁按鈕，便會出現再扣減一個飯盒數量。問題是，我又不能限制一部電腦給予數人同時參加活動的。所以最後用PHP $_SERVER[“REQUEST_METHOD”] == “POST”，如果參加者在活動後按不斷『重新載入頁面』，依然會停留在原本頁面。如果用戶按『上一頁』，便假設他正在為其他參加者參與另一次的活動。

05. 考慮3：為活動加入不同飯盒選項後，想到如果參加者使用電話登入網站，會與電腦的瀏覽器頁面不一樣。又加上CSS來控制不同設備的頁面設計。

06. 最後為網頁加入圖案、為文字加上顏色，設定好CSS，就完成今次活動的『第1個版本』。

07. 當我以為工作會就此結束時，少年你實在太年輕了。要求依然是固定的飯盒數目，但因為酒店對每款飯盒數量有MOQ的要求，所以不可以任由參加者隨便選擇。但也因為這個原因，參加者按了網站連結減一個飯盒根本不可行。

08. 『第2個版本』，將總數量檢查取消，參加者選擇飯盒後，直接檢查每個飯盒數量存量，如超過某數量便取得此飯盒選項，直至所有飯盒都沒有存量，就終止活動。

09. 看似是完美的想法及方案，但如果是一個一個人進入網站選取飯盒，是完全沒有問題的。因為不會發生當第一個人選擇飯盒時，第二個人已在上一刻取了那個最後的飯盒餘量。

10. 所以，又有了『第3個版本』。沿用第2個版本設計，參加者選擇飯盒後，直接檢查每個飯盒數量存量。但同時，每隔一段時間(我用了15秒)，就更新頁面，以便顯示飯盒真正餘量。而為了在這15秒間，兩人同時選擇最後的飯盒，所以設計是當參加者選擇飯盒後按提交，會即時檢查是否仍有飯盒餘量。如沒有便叫參加者按上一頁，再選其他還有飯盒餘量選項。

11. 也因為每隔一段時間就更新頁面，將輸入參加者個人資料放到成功選擇飯盒下頁，否則當參加者選擇飯盒或輸入資料時，不斷的頁面更新便不能成功選擇飯盒。或有可能是，當選擇好飯盒及輸入個人資料後，按提交後卻被告知已沒有飯盒餘量，到時又會被參加者投訴浪費時間。

12. 而當參加者個人資料畫面，設定是扣減一個飯盒數量。所以如果參加者沒有輸入個人資料，那個飯盒就不能給予下一人。這是考慮到，當最後飯盒被預定後，在參加者輸入資料前，活動理應是已結束了。但如果在某段時間內，那參加者沒有輸入個人資料後就重新放出來繼續活動，便有違先到先得的規定。

13. 加入不同防範小人基制，包括參加者在瀏覽器不同頁面的重新載入(refresh)、參加者使用同一電郵登記、參加者在選擇飯盒後長時間沒有輸入個人資料後,可以利用cronjob將此資料刪除。

14. 與同事提及上面複雜的理論，當然不會有人理會我的想法。那就直接用參加者去做一次用戶接受測試(UAT)。

15. 4分27秒，第1次活動結束，只有30個飯盒被成功預定。原因是我堅持在參加者按連結時計算數量，只要超過85次按連結次數，活動便會結束。但我沒考慮的是，居然會有一人幾機去進入網站。

16. 當然，餘下的飯盒不會不了了之，取消按連結次數限制。第2次活動用了25分鐘便結束，原因不是所有飯盒已被預定，而是參加者選擇了飯盒後，系統即時已預留了參加者的飯盒選項，但參加者卻沒有輸入任何個人資料。

17. 而另一個發現，就是有參加者多次進入活動，選擇同一樣的飯盒選項或不同的選項，那一個人就霸佔了幾個飯盒數量，浪費予其他參加者參加的機會，但難道又要多做參加者身份測試嗎？(其實最後我真的用了電郵作檢查)

18. 與同事討論以上問題，將重覆的參加者篩走，及確認同一參加者不同選項問題，便能再開活動。

19. 但相信再開也會在飯盒餘量上出現之前的問題。因為，問題根本不是在程式設計上，而是要如何防『天才』、防『小人』多於一切。