在 Windows 初次安裝、使用 MongoDB

這篇是簡易記錄文～記錄一下在 Windows 上安裝和小小測試 MongoDB 的過程。

MongoDB 的安裝和使用方法，在官方網站的文件上其實有說蠻多的，可以參考 [1-2]。

在 Windows 上安裝 MongoDB

在下載好 MongoDB 之後，它會是個壓縮檔，解壓縮之後放在某個自己想放的位置
以官網的教學建議是放在 C:\mongodb，不過放在哪都無所謂～自己方便就好。

PS. 為了方便起見，後面都會以 C:\mongodb 當做是 MongoDB 的所在路徑。

接著要先建立 MongoDB 放資料庫的位置，預設會放在 C:\data\db 這個目錄
因此要用檔案總管或其他方式，把這個目錄建立起來，否則啟動 MongoDB 時它會告知找不到路徑而自行關閉。
如果不想要放在這個目錄，要用以下指令去更改路徑，這裡直接用官網的範例，即要改到 D:\test\mongodb\data：

C:\mongodb\bin\mongod.exe --dbpath d:\test\mongodb\data

如果路徑包含空白，例如路徑是「D:\test\mongo db data」的話，可以用雙引號把完整路徑包起來，例如：

C:\mongodb\bin\mongod.exe --dbpath "d:\test\mongo db data"

基本上這樣就完成 MongoDB 的安裝了（咦？！）
嚴格來說它根本也沒什麼好安裝的，就是壓縮檔抓下來解壓縮就好 XD。

MongoDB Concurrency

MongoDB 的 concurrency 的資料，感覺好像比較難查....

Global Write Lock / Yield Lock (Locking-With-Yield)

首先是關於在 MongoDB v2.0 以前（含 2.0）的版本，MongoDB 具有兩個特性：global write lock 和 yielding lock。
詳情可以參考看看 [2-4]，以下說明大略是出自 [2] 的說法～。

用 Java 產生高品質縮圖的方法

使用原生的 Graphic2D 的函式庫要改變圖片大小不難，不過要產生高品質的縮圖就稍微複雜一點，原因在 [2] 中有描述。
[2] 提到在做圖片的放大縮小時，選擇 RenderingHints 是一件很重要的事情（這是必然的 XD）
當目的是要放大圖時，選項比較簡單：

• 求快：RenderingHints.VALUE_INTERPOLATION_NEAREST_NEIGHBOR
• 求高品質：RenderingHints.VALUE_INTERPOLATION_BILINEAR
• 求更高品質：RenderingHints.VALUE_INTERPOLATION_BICUBIC

但如果是縮小圖片時，狀況就稍微複雜一點～

在 Java 中讀取圖片和寫入圖片

稍微看了一下 Java 的圖片相關的資料，在 Java 中是以 java.awt.Image 這個 abstract class 來表達圖片
實際實作圖片的包括 BufferedImage 和 VolatileImage。
一般要把圖片讀取到記憶體中，或者是要把記憶體中的圖片寫入到檔案，都可以透過 ImageIO 來進行。

SQLite Concurrency

SQLite 本身自稱在 concurrency 方面只有有限度的支援
有關 SQLite 如何處理 Lock 和 Concurrency，可以參考 SQLite 官方文件 [1]。
大體上可以理解為 SQLite 的上鎖機制很像是 Java 的 ReadWriteLock
亦即對同一個 SQLite 資料庫而言，允許多個程序同時讀取，但最多只允許一個程序進行寫入
寫入期間就是使用一般的 exclusive lock 將整個資料庫鎖住。
這大概也就是為什麼 SQLite 官方說他們只支援 1 transaction 吧。

HashMap 的特徵

筆記一下 HashMap 的特徵，參考 [1] 的原理說明～
HashMap 會建立一個容器去存放 key 和 value，儲存時是利用 key 的 hashCode（繼承自 Object）去計算位置
在建立容器時，會設定一個指定的長度，長度是根據 HashMap 的 loadFactor 來決定的

字典：Exclusive Lock 與 Optimistic Concurrency Control

Exclusive Lock：當程序要存取某個資源時，先將資源上鎖（禁止除了自己以外的程序存取這個資源），等到自己處理完畢後，再將鎖釋放。

Optimistic Concurrency Control：當程序要存取某個資源時，先假設不會產生衝突，直接進行資料處理。等到資料處理完要寫回資源時，去檢查從讀取資源到現在，中間是否有其他程序曾經修改過這個資源，沒有的話就正常地寫入並結束，但若有的話就放棄所有處理的結果，全部從頭開始。

字典：volatile 關鍵字

原本想找一些比較正式的資料，不過目前還沒有在手邊的書上看到有關這個的資料～。
就 [1-2] 描述有關 volatile 關鍵字，主要是說一般變數宣告的狀況，會在 JVM 當中建立一個專用的 Register 暫存區
存取記憶體時，程序會去該暫存區取得變數資料、對其做修改等動作
但修改的過程對其他程序來說是個黑洞，它們無法「看到」動作的內容，甚至不知道該變數正在被修改。

目前用過最流暢的 Desire Z ROM：LightSense 1.2（Android 2.3.3 + Sense 1.9）

我家有兩支 Desire Z，雖然刷過了好幾種 Desire Z 用的 ROM
包含有原廠的 2.2.1、2.3 更新，還有前面的文章提到的 Runny v6.0、Andromadus beta 5 等等的
扣掉原廠的大概刷過五六種 ROM，Android 2.3.5、4.0.4，有 HTC Sense 或沒有的都用過
但儘管是有些 ROM 號稱有對 Desire Z 特別優化，用起來實際上還是相當地頓！
或許是我們都比較沒耐心吧，像是手機解鎖等個 0.5 秒，要打電話等個 2 秒，我們用了一段時間真的是會有火...
原本是打算等約滿之後直接換手機～但畢竟還有幾個月的時間
正好遇到同事要刷機，心血來潮就去查了 XDA 的 ROM，這次目標是舊版的 Android
最後很幸運地找到了 LightSense 1.2 這個 ROM！（LightSense 1.2 最後更新是 2012 年 5 月）

字典：Atomic

在看 Java 的 concurrent 的教學文章時，看到 Atomic 這個關鍵字
因此稍微查了一下，Atomic 這個字在英文中是「原子」的意思，即在大自然中原子被視為是組成物體的最小單位
在 Java 中，定義一個 Atomic 表示的是這個行為是最小單位，亦即不可被切割，要嘛全部完成、要嘛全部失敗。
Atomic 是一個 package 的名稱 [1]，同時也代表著具有 thread-safe 的變數
當一個變數要被修改時，一定包含著三個動作：讀取變數值、修改數值、將修改後的數值存回變數
Atomic 這個詞在 Java 中即表示一系列的動作是可以保證一起被完成而不會被中斷（其實就像是資料庫的交易的概念）
因此能夠確保在 Atomic 的環境之下，不會發生修改時資料不一致的問題。

synchronized、wait() 和 notify() 的觀念與用法 (待續)

在多執行緒的環境中，有時會產生需要造就出類似資料庫的交易環境
也就是某個一系列的動作正在執行時，必須確保執行期間的資料不會被別的執行緒修改。
例如有某個變數 a 的當前數值是 0，然後同時有兩個執行緒 T#1、T#2 進來要存取 a
T#1 進行 a++ 的動作，接著把 a++ 的結果寫回 a
但寫回去之前，T#2 已經讀取了當前的 a（即讀取到 a=0），並且同樣嘗試要做 a++
T#1 寫回去以後，a=1，接著 T#2 又寫回去，a 仍然等於 1
這時就造成資料不一致，亦即 Race condition [1] 的問題發生了
因為理想上 T#1、T#2 個別對 a 做了 a++，應該要產生 a=2 的結果。

在 Linux 中透過 egrep 篩選文字

記錄一下～在使用 cat、tail 等指令時，當遇到想要只顯示包含某些關鍵字的文字行時
可以使用 egrep 來協助篩選，例如：

cat /usr/local/tomcat/logs/catalina.out | egrep "error|ERROR"

上述指令可以篩選出包含 error 或者 ERROR 的文字行。

The serializable class does not declare a static final serialVersionUID field of type long

在 Class 有宣告 implements Serializable 時，eclispe 可能會有 WARNING 跑出來
原理可以參考 [1] 的說明～
實務上想要自動產生某個 long 的 serialVersionUID 時，可以參考 [2] 的回應
在 eclipse 介面上選："Source" -> "Cleanup..." -> "Custome Profile" -> "Missing Code" -> "Add serial version ID"

在 Java 中計算檔案的 MD5/SHA1 hash

MD5 hash 常用在判斷兩個檔案的內容是否完全相同
一般用來判斷某個檔案是否上傳或下載完整～當然也可以用在檔案複製貼上等等的動作。
之前在做這種需求時，都是直接用 Runtime 呼叫 Linux 的 md5sum
不過總是覺得一直依賴底層 OS 的指令，好像不是個非常完美的作法！
尤其考慮到程式未來可能需要移植到別的平台時，大量使用 Runtime 會導致移植時要花費的功夫暴增。

今天稍微查了一下，原來 Java 原生就有可以計算 MD5/SHA1 hash 的方法！
雖然不清楚 Java 算出來的 hash 值是否跟用其他方式算出來的 hash 值相同，但老實說那並不是很重要 XD
畢竟 MD5 hash 這種東西只要能確認同一個檔案，每次算出來都一樣；不同檔案算出來都不一樣，能達到這個目的就好了！

(暫存) 檔案系統的目錄結構

參考資料：
1、B-tree在外部存储和数据库索引中的应用
2、第九章 檔案系統
3、Design and Implementation of the Second Extended Filesystem
4、鳥哥的 Linix 私房菜：inode
5、理解inode
6、inode 的觀念
7、Btrfs design
8、Btrfs超级块磁盘结构
9、BTRFS设计（一）
10、Btrfs design
11、NTFS recovery — New Technology File System

判斷捲軸位置的 jQuery plugin：waypoint

參考資料：
1、jQuery waypoint

概念上蠻簡單的，waypoint 就是指定某個標籤
當指定標籤出現在瀏覽器的可視範圍內時，該標籤的 waypoint 事件就會觸發～
如果要像 Facebook 一樣讀新資料時，就可以在這個時候送 ajax call 去讀新資料
然後 append 到顯示資料的標籤上～。

B+-tree implementation：JDBM3（2012-10-15 修正）

上一篇文章 B+-tree implementation：JDBM 用了初代（XD）的 JDBM 來實作 B⁺-tree
不過在追蹤原始碼之後，因為 JDBM3 有特別對 serialization 做調校，因此還是想用看看 JDBM3！

B+-tree implementation：JDBM

在前篇文章當中，找了一些有關 B⁺-tree 的實作函式庫
其中有一些連結提到 JDBM 這個函式庫，因此就來嘗試看看了。

JDBM 本質上其實並不是實作資料結構的函式庫，而是要做一個 Java 版的資料庫系統
具有 B⁺-tree 只不過是因為他的資料庫系統會用到的關係。
JDBM 目前看起來有分 JDBM 到 JDBM4 總共四個版本，從原始碼的註記來看，JDBM2、JDBM3 似乎換作者了。
而 JDBM [1]、JDBM2 [2] 和 JDBM3 [3] 的差異在哪裡我也不是很確定～
光看專案的描述來說，JDBM2 有做一些效能調校，但調校的部份不知道在哪～
而 JDBM3 看起來好像多了不少 feature，像是它有特別提出它的 serialization 有客製化，可以提昇讀寫的效率

Access restriction on class due to restriction on required library rt.jar?

有時在開發時會遇到這個奇怪的訊息，依照 [1] 的回應中 Nels Beckman 的解釋
是因為某個 Class 名稱可能同時出現在多個 jar 檔裡，因此會讓 JVM 產生混淆
他的解決方法就是在 eclipse 專案的 Build Path 屬性中，把 JRE System Library 刪除掉再重新加回來
這時就會把讀取 JRE 的順序調整成正確的順序了。
而最乾淨完整的解法自然是確保引用的所有 JRE 都是沒有重複的 Class。

參考資料：
1、Access restriction on class due to restriction on required library rt.jar?

分散式系統的架構

根據 [3] 的描述，在分散式系統中，主要分成三種架構：Shared Memory、Shared Disk、和 Shared Nothing