最近剛好在研究如何在 Line 的群組做到排程貼文的發布，目的不外乎經營群組想要排程推送內容，自己私人群組用作提醒記事用，便來研究了一下該如何能以最容易且低成本的方式來串起所需功能，謹以此篇文記錄自己的實作過程與該如何套用。

文中會分成實作與套用兩部分，可以直接搜尋關鍵字，看你想看的部分就好：

• 使用步驟
  > Line Notify 的部分
  > Go …

嘿！菜園裡洋薊已經長的到處都是了！這樣可會把你的菜園弄得一團糟，只剩下一個辦法了：丟棄所有的洋薊！透過收穫新鮮的蔬果來清理你的牌組，這些新鮮的水果能讓你交換，丟棄或堆肥卡牌，想要組成獲勝的一手，你需要一些的幸運、策略，也許綠手指也會很有幫助。

遊戲是個輕快的牌庫構築遊戲，規則簡單易懂，遊戲時長短短的，大概10分鐘內就可以結束一局，適合當穿插小品，一些帶有隨機性的效果也是會在出現意料之外的結果時讓人會心一笑。

遊玩人數 : 2–4人

遊玩時間 : 6–10分鐘

標籤 : #牌庫構築#沒有洋薊即獲勝#丟了那些洋薊

BGA網址：https://boardgamearena.com/gamepanel?game=abandonallartichokes

遊戲一開始會發給玩家10張洋薊構成牌庫，面朝下不用洗牌(因為十張都一樣的XD)直接抽五張，這時候會有五張是手牌，五張是牌庫。

一座獻給索貝克的寺廟正在如火如荼的建造著。相鄰的一座巨大的市場因此崛起，一旁尼羅河沿河的三桅帆船和獨木舟正好能提供相應的資源。你的商人工會和你的對手公會都決定來爭搶這個難得的商業機會，而索貝克神的恩惠，會落在最不浪費的公會來幫他們一把。能在這場競爭中脫穎而出的，就是最後的贏家。

雖然沒玩過索貝克本來的遊戲，但這款兩人版是個輕快的兩人遊戲，透過簡單的價值相乘概念，適時出貨發動獨木舟的驚喜，又或是控制生命之符的方向來限制對手走位，規則容易上手，適合兩人想動動腦的時候來上一局。筆者覺得比較浮動的大概是神的恩惠是捉摸不定的吧，獎勵板塊的分差有時候是很可怕的(苦笑)

遊玩人數 : 2人

遊玩時間 : 20分鐘

標籤 : #移動那個雕像 #成套蒐集 #腐壞乃必要之惡

BGA網址：https://boardgamearena.com/gamepanel?game=sobektwoplayers

Setup的部分麻煩參考說明書直接進行設置，BGA的部分它會幫你Setup好所以這個部份我們就不細說了。

遊戲結束的條件是任一方的回合中無法做任何行動，則遊戲立刻結束。

遊戲最後的目的是比較計分，計分的來源總共有：

1. 德本(Deban)標記，標記上會有數字，數字等同分數
2. 出貨： 出貨時的 甲蟲數量 * 上出貨卡片數

至於該透過甚麼管道獲取，我們後面一一敘述

起始每個玩家會有兩張手牌，都會是沒有甲蟲的貨物卡。

我們行不行？一定沒問題！雖然我們這次也是要扮演建築規劃的角色，但並不是規劃建築─我們要來蓋鐵路和公路啦！雖然你可能對建築有一套自己的想法，但天不從人願，你可能沒辦法拿到最好的鐵路，那你是否能夠在這個狀況下，仍然蓋出四通八達的道路規劃呢？這個輕快的遊戲，邀請你一起來築起一片交通網！

看到遊玩人數的時候應該第一個想到的是 Welcome To (笑)，實際上看完了規則也是類似的同步進行制的紙筆遊戲，讓我們來開始了解怎麼上手吧。

遊玩人數 : 1–12人

遊玩時間 : 20–30分鐘

標籤 : #紙筆遊戲#紙筆與骰#童年回憶水管工人

BGA網址：https://boardgamearena.com/gamepanel?game=railroadink (房主須為尊榮會員)

基本規則(遊戲時長：7個回合)

遊戲開始時每人會有一片圖板，這是你將要蓋起交通網的地方，我們先統一名詞：

紅色的箭頭⇧：出口

兩條線中間有線的Ξ ：公路

虛線┅：鐵路

黑色的方形■：車站

內縮符號〉〈：跨過，表示上下並無交會

規則中如果提到「道路」，表示鐵路或公路都包含在所指對象

遊戲總共會進行7個回合，每個回合會丟出四顆骰子，骰子有兩種：

純道路骰共會有三顆，丟出的圖示可能有以下這些：

村子上的籬笆每天都有好多的小鳥，但是到了該飛回家的時候，他們好像該如何成群結隊有些困難，你能夠幫這些方方正正的鳥兒們組成完完整整的隊伍，好好地飛回家嗎？

這款在BGA的熱門區出現了一陣子了，本來就有簡體中文的官方中文規則，不過昨天實際玩完後來寫一個比較清楚易懂的遊戲規則版本。玩起來是個輕快的成套蒐集遊戲，但是需要的鳥兒遲遲不出現的時候會想說鳥兒是迷路到哪裡去了(笑)。

遊玩人數 : 2–5人

遊玩時間 : 9分鐘

標籤 : #鳥兒在哪裡 #成套蒐集 #左邊右邊都有就夾起來

BGA網址：https://boardgamearena.com/gamepanel?game=cubirds

(簡略帶一下Set Up，這遊戲的設置很快)

遊戲牌組總共有110張牌，起始遊戲時

• 中間依序發好 3張 * 4列的鳥兒牌，正面朝上，同一種鳥如果在同一列出現多次，棄掉直到同一列沒有同種鳥為止
• 把所有棄牌跟剩下的牌洗混，每個人發八張手牌，與一張公開的鳥兒牌，代表起始蒐集的1隻鳥兒

好像很久沒寫桌遊規則相關的文章了，昨天玩了一款新的小品桌遊，一樣是在BGA上的，是款開心建築自己城市的遊戲，它的卡牌美術風格都蠻可愛的，圖片或建築也能讓你會心一笑，最重要的是不要只發展人口，也要兼顧城市的幸福度，這樣才能打造一座開心城市喔！

整體上市一款節奏輕快的小品遊戲，沒接觸過策略遊戲的朋友也很適合做簡單的收入購買的營運練習。

遊玩人數 : 2–5人

遊玩時間 : 9分鐘

標籤 : #建築師巴布 #簡易市場 #規則簡單

BGA網址：https://boardgamearena.com/gamepanel?game=happycity

(我預設會來看這篇的人是想快速知道怎麼在BGA玩，一樣會略過Set Up的部分喔，想參考Set Up的請移駕原本說明書，另外拉到底有原本說明書提供的懶人包中翻，幫助你快速了解/回想遊戲大概流程。)

遊戲主要只分兩個階段，收入階段與行動階段：

緣起於今天看到朋友在使用DateTime做Query的時候，發現兩邊同樣TimeRange的Data對不起來，用了DateTime欄位做Group By後才發現是意外撈到了非預期的值，讓我想研究一下官方文件，看看DateTime是不是還有什麼沒注意到的眉角。

讓我們來看看他的撈取區間的寫法：

Select theDataHeSelect
From targetTable
Where DateTimeParameter Between '2021-05-01 00:00:00.000' And '2021-05-07 23:59:59.999'

這樣撈出來的結果，實際上撈出來的數據其實是 ‘2021–05–01 00:00:00.000’ ~ ‘2021–05–08 00:00:00.000’，為什麼明明是寫999，但是系統卻把撈取範圍進位了呢？

這裡是MSDN中有關Sql Server DateTime精度描寫：

可以看到文件清楚寫到，在DateTime millisecond 的尾數位置精度只有三個數字，分別是.000, .003, .007，其他數字都會被逼近到這三個數字，其中最出乎使用者意料的應該又是.999，逼近後會導致時間點的進位，如範例所示，如果用23:59:59.999，進位後會變成00:00:00.000，在進行時間查詢的時候要特別注意，以免寫了個坑坑自己。

另外分享一個之前寫C#串Sql Server踩到的雷，DateTime型別在C#中的Min Date 是 0001/01/01，而Sql Server中的 Min Date是 1753/01/01，如果在串Api輸入的時候，C#中的DateTime沒有賦值的情況下直接傳入，Mapping到Sql Server的DateTime變數，就會拿到這個錯誤。

System.Data.SqlClient.SqlException: The conversion of a datetime2 data type to a datetime data type resulted in an out-of-range value.

那對應的簡單解法有兩個：

1. 在C#中給予該 DateTime 變數 Default值，且該預設值大於 1753/01/01
2. Sql Server對應欄位宣告為 DateTime2，DateTime2的支援範圍為 0001/01/01 ~ 9999/12/31，就可以避開這個問題

以上是今天帶來的兩個關於DateTime的雷，與大家分享，希望能讓踩到雷的人雷個清楚，沒踩到的也明白這裡有個坑。

寫Store Procedure的時候，我們常常會需要建立暫時的資料表來協助我們處理資料，一般而言我們會有兩種選項(以SQL Server2000後來說)：Temp Table與Table Variable。
而什麼時候要使用哪個，之前筆者其實一直想好好了解一下，這篇文章的內容來自就這個主題下去查詢後得到的內容，若有錯誤請協助指正，本篇內容更偏向個人統整筆記。

我們先來看這個表格，是我歸納各文章中的大多數的內容：

                               Temp Table | Table Variable
tempdb的交易紀錄檔               小         | 大
可否加Index與Default Constraint 可          | 否
Transaction Rollback           可         | 否

這個表是最基本的比較，然而在我看的另一篇文章中有指出不同的看法，上面這些敘述在基本面上是正確的，但是論到根本的實做的話可能又有些不同。

下列再逐一列出一些被提到的論點

• Temp Table是可以如一般Table一樣使用DDL語句
• SQL Server會幫Temp Table建立統計數據(Statistics)，意味著QO(Query Optimizer)可以選擇適合的計畫，相對來說SQL Server並不會對Table Variable建立統計數據，Recomplie次數會更少
• 兩者都會寫下交易日誌(Transcation Log)，
• 對大量資料的推薦，一般會建議使用Temp Table，可以吃到Index的好處，另外需要確認Tempdb中的分配空間，避免預設空間過小的問題
  (註：兩者的實例化都是在Tempdb，)
• 當Store Procedure A 建立了一個Temp Table後，若呼叫Store Procedure B，在B中是可以使用該Temp Table的

其中這篇文章表示(這篇文末也是我上面說有探討根本情況下的一些比較討論，有興趣可以看看)，根據作者的測試(內文有它的測試數據)，在100,000行以下的行數兩者的效能會差不多，然而隨著資料表的增大，Temp Table的表現會明顯的比Table Variable好。

這個結論跟我看的大多數文章是一致的，當資料集大的時候，會推薦使用Temp Table，小資料集的時候可以依據當下的實作狀況來評估兩者的使用，效能上十分小的話Table Variable甚至會小超一點執行效能，然而隨著資料集的增大，會慢慢的反超，所以在撰寫Store Procedure時應注意操作的資料集對象的量級來評估，若隨著資料源的成長，也要適時評估適合的寫法。