軟體主廚的程式料理廚房

「你如何預防 SQL Injection？」這個問題已經成為了一個顯學，現在我們寫程式如果沒有把解決 SQL Injection 的方式變成習慣，我們就絕對是個不及格的程式設計師，一個領域如果夠成熟，那這個領域會累積一定厚度的必學項目，像 SQL Injection 的問題就是累積來的，面試也常常會問。

之前有介紹過[料理佳餚] C# StackExchange.Redis 使用 Redis Message Broker 服務，StackExchange.Redis 稍嫌美中不足，以目前來講 Failover 要自己控制，當然自己控制是沒有什麼問題的，不過既然有其他工具可以幫我們 handle 這一切，當然就讓工具來協助我們。

曾經的一個需求，需要在 Client 端對位於檔案伺服器上的檔案進行操作時，切換到另一個具有權限的 Domain 身分，只用過這一次，分享給大家參考。

DES 加密演算法是一種對稱加密演算法，但是用來加解密的 Key 及 IV 需要固定長度，DES 的 Key 及 IV 長度大小都是固定 8 bytes，也就是說每次加解密的過程中都需要湊足 8 bytes 的 Key 及 IV，多了或少了都不行。

我參考余小章的文章 - [C#.NET] 字串及檔案 利用 DES / AES 演算法加解密，實作如何使用不固定長度的 Key 及 IV 進行 DES 加解密。

NEST 的 Search 方法直接將搜尋結果轉換成強型別來提供給我們使用，可說是非常方便，那我們能不能將搜尋結果轉成另外一個強型別呢？答案是肯定的，不過如果直接將 Search 這個一般化方法指定的類別給換掉，會踩到一些雷，且看接下來的說明。

要在 Elasticsearch 下達搜尋指令找出一些東西來，可以透過像 kopf 這類的 Plugin 所提供的 GUI 來直接操作 Elasticsearch 的 RESTFUL Api，可是我們最終還是有需要自己寫程式來下搜尋指令的時候，除了用像 RestSharp 這類的套件，再自行轉換 JSON 結果之外，當然也可以透過 NEST 來輕鬆達成。

Hadoop HDFS 是透過 Block Size 的設定來決定對一個檔案切割的大小，HDFS 預設的 Block Size 是 128mb，意思就是說當一個檔案超過 128mb 時，就會被切成至少 2 個 Block 以上存放。

但是在海量圖檔的情況之下，一個圖檔通常不會超過 128mb，一個檔案還是佔用了一個 Block 個數，實際佔用的磁碟空間是依照檔案的實際大小沒錯，可是檔案的實際大小未達到 Block Size 的設定值時，還是硬生生地佔用了 1 個 Block 個數，當 Block 的數量太多的時候，對於 Hadoop Name Node 的記憶體空間就會有相當大程度的耗損。

同事架設了 Hadoop 用來測試 HDFS，公司有海量的圖檔需要做永久存放的需求，而且都要是 Online 的，在思考解決方案時先考慮到的就是分散式的儲存系統，Hadoop 正夯，所以就拿它來試試看，Hadoop 有很多功能可以使用，但是我們只需要 HDFS 就好了。

Elasticsearch 架設起來之後雖然已經有 RESTFUL Api 可以使用，GUI 方面也有像 kopf 之類的 Plugin 可以用，但是要寫程式來操作它除了自己接 RESTFUL Api 之外，其實我們還有其它套件可以選擇，像是連 Stack Overflow 都使用的 NEST。

Redis 除了可以用來當 Cache 之外，還可以用來當做 Message Broker，簡單來說就是我訂閱了某個頻道，當這個頻道有訊息被發佈出來之後，我會即時收到帶有訊息的通知，光想到這個我就覺得 Message Broker 可以用來做好多事情，Chating、Notification…etc。