像天貓、京東、唯品會，經常會推出各種各樣的營銷活動來吸引使用者購買，營銷活動是有狀態的，一般來說，有以下幾種狀態。
活動未開始，活動已開始、活動已結束、活動已廢棄活動未開始、已開始、已結束，這三個狀態可以使用活動開始時間和活動結束時間來得出。
public int getactivitystate(activity activity,date currentdate)
if (activity.getbegintime().compareto(currentdate) <= 0 && activity.getendtime().compareto(currentdate) > 0)
if (activity.getbegintime().compareto(currentdate) > 0 )
return not_start;
}
public int getactivitystate(activity activity,date currentdate)
if (activity.getendtime().compareto(currentdate) <= 0)
if (activity.getbegintime().compareto(currentdate) <= 0 && activity.getendtime().compareto(currentdate) > 0)
if (activity.getbegintime().compareto(currentdate) > 0 )
return not_start;
}
上面的這種做法我是比較推薦的，以前也都是這麼用的。
之前還見過另外一種做法，就是在資料庫裡使用乙個state欄位，它的列舉值也是：
活動未開始，活動已開始、活動已結束、活動已廢棄第一次看到這個表設計的時候，我很納悶。因為活動已開始和已結束，這個操作並不能從後台觸發，而是隨著時間的逝去，在將來某個時間點觸發。既然這樣，誰來維護這個欄位呢？？
後來請教了原來的表設計者，他說是利用延遲訊息來維護這個欄位的。當活動剛剛建立的時候，就發一條延遲訊息到佇列裡，根據活動開始時間和結束時間，計算延遲時間。時間一到，就觸發訊息。訊息接收者收到訊息後，更新資料庫字段。這樣使用方判斷活動狀態的時候，就只需要讀取這個字段，看看列舉值即可。
但是為了維護這個欄位而引入mq，代價太大了吧。另外活動狀態這麼關鍵的業務字段，需要完全依賴mq，風險實在太高了。真心不建議這麼幹。
記遇到過的HTTP狀態碼（Status Code
200 ok 請求成功，聯調時傳送引數符合介面想要接收的引數 302 move temporarity 重定向，後端介面更新時顯示，部署預發環境等情況，重定向是臨時的 請求的資源臨時從不同的 uri響應請求。由於這樣的重定向是臨時的，客戶端應當繼續向原有位址傳送以後的請求。只有在cache cont...
這兩年我遇到過的「奇葩程式設計師」
第乙個故事 於我的第一家實習公司。我在第一家公司實習的時候，我的前端負責人是乙個長相比我還年輕的 小夥子 事實上那時候我大三，而他已經過了而立之年。所謂師傅領進門，修行看個人。我從他身上聽過的最多的一句忠告就是 這個需求做不了 我不知道是他當時覺得我太菜還是怎樣，反正最終到我手裡的需求，經過他的高超...
工作流活動例項狀態轉換的兩種實現模式
今天和同事 chelsea 就活動例項狀態的實現思路上進行了討論。我們兩個站在了兩個不同的角度來看待，這兩個不同的角度也正好眼下最為常見到的兩種實現思路 chelsea 是從狀態角度 來看待，當然也完全是從 state pattern 的角度來思考 狀態在達到某個狀態的時候，會引起或必須引起活動例項...