作者: Hui-Hong YOU

而且連一罐水都沒帶，完全亂來，真的是臨時起意在從頭城回來的途中想爬上去看看蘭陽平原。

騎到這個地方，其實原先設定的目標是要騎到上新花園，再走跑馬古道回宜蘭的，就只差一小段路程而已，卻開始飄起雨來，不得不趁著雨勢還沒變得更大前趕快衝下山。

爬上來的途中還看到有人在玩飛行傘，也算特別的見歷。

如果 USB 隨身碟有 8GB 的話會很好用，不過就算只有 4GB 仍然很好用。這裡只要切出一塊約 1GB 大小的 ext2/3 檔案系統給 Fedora 用，其餘空間也就還剩 7GB 或 3GB 可用，因為想要避免使用 FAT 拿人手短、吃人嘴軟的爭議，所以把剩下這塊分割區弄成 UDF 檔案系統。

這裡預先假定 USB 隨身碟的裝置代號是 /dev/sdX，第一個分割區為 /dev/sdX1，第二個分割區為 /dev/sdX2，餘者類推。

因為 Windows 的行為是抓 USB 隨身碟第一個分割區來認，認不得的就要使用者格式化，所以必須把這 7GB 或 3GB 的空間 (= /dev/sdX1) 先用 fdisk, cfdisk 或 GParted 劃出來，剩下再劃一個約莫等於 1GB 的空間 (= /dev/sdX2) 做 ext2/3 檔案系統，並且記得給這個分割區設定 boot 旗標。

這些分割區劃好之後，先 unmount。

接下來把 /dev/sdX1 規劃為 UDF 檔案系統：

mkudffs –media-type=hd –blocksize=512 /dev/sdX1

然後跑 Fedora 12 或 13 Beta 光碟裡的 LiveOS/livecd-iso-to-disk 程式，把 Fedora Live 系統放入 /dev/sdX2：

./livecd-iso-to-disk $ISO_Image_Location/F13-Beta-x86_64-Live.iso /dev/sdX2

程式若正常跑完，將 USB 隨身碟正常卸除，之後可以用實機來測試，或者用 qemu, kvm 來測：

kvm -hda /dev/sdX -m 256 -vga std

於是可以得到一支兼具 UDF 儲存能力以及 Fedora Live 系統的雙用 USB 隨身碟，拿來在別人電腦上開機、登入一些需要打自己帳號、密碼的網站時會比較放心（在別人電腦沒有硬體 key-logger 等怪怪裝置的前提下…）；拷貝檔案到別人的 Windows 系統也很好用（如果 Windows 版本是 Vista 以上，不只可以讀，也可以寫，但是 XP 就唯讀了）。

自今年四月一日起，悠遊卡開放小額付款。

我在開放首日去超商買早餐，拿著悠遊卡付款，店員卻還不確定我是要加值還是付款，就這樣錯愕、打轉了一下。折騰下來，整體的交易速度並沒有 7-ELEVEn 本家的 icash 快，而且我覺得該次讀取悠遊卡的速度也遠遜 icash。

於是隔天我還是使用「舊」icash 付款。

因為友人提示零售的「icash 悠遊卡」已可購買（原先我誤以為只能和套卡一樣預購），中間我又去買了一張「icash 悠遊卡」，替換掉我原先的學生證整合卡。

而第一次使用這張 icash 悠遊卡，我等了約有八、九秒，中間氣氛凝結到我忍不住開口和店員攀談，問及為何交易速度似乎沒有比原先的 icash 快，店員也尷尬地賠笑表示，若當下交易量大，線路就會「塞車」。我那時候想，日後要是交易速度都這麼慢，我儲值在這張悠遊卡的額度大概會「很久很久」才會花完，因為我真的想回去用 icash，而我現在上、下班也不用搭公車或捷運了…。

但是接下來幾次在超商（除了 7-ELEVEn，也有在 OK 便利店消費過）使用悠遊卡付款，速度卻非常快，比 icash 快很多，自此對於悠遊卡小額付費，我也就寬心許多。

最後記個小插曲，上週五，拿著這張悠遊卡去搭國道客運返鄉，因為和全聯福利卡疊得太近，屢屢被機器拒絕扣款，也是像這篇〈搭捷運的人很少上全聯社買東西嗎 ?〉說的，把悠遊卡從皮夾抽出來讀卡才能交易成功。

羽球這項運動，我是從國小某次月考成績得到一組文具店「歡樂拍」為獎品開始接觸的。之所以稱為「歡樂拍」，是因為其鋼材骨架、易斷尼龍線的組成結構，再搭送一顆塑、橡膠材質球，就成人拿來打「稍微認真」的比賽都不見得舒適好打，遑論國小學童。彼時用到老師、同學、親戚比較好的球拍，當然是感覺得出明顯的差異，不過，向來也只停在「歡樂休閒輕鬆打」程度的我，一直到了大學要上羽球課、比大圖盃，才去分別買了兩支 PROKENNEX, VICTOR 的碳纖維拍。

羽球拍太久沒用，除了線的磅數會掉，最明顯的還是握把皮會「粉化」或生黴。昨天發現這兩支少用的球拍握把皮又再度嚴重「粉化」，除了想起某拍賣的故事而感嘆，還是想著要快點將握把皮換新，以免握把再有更糟糕的損害。

查到了 VICTOR 公司部落格給的經銷商列表，我就跑去神農路的冠軍採購料件。買了幾枚 KAWASAKI的薄皮（型號忘了…）和 VICTOR 的 GR-160 厚皮來混搭著用。頭一次自己換握把皮，發現其實蠻簡單的，除了網路上的相關教學文章，GR-160 紙板包裝上也有印刷簡單扼要的說明圖示。我不知道之前請店家代為更換時，使用電氣膠帶固定、而不使用握把皮本身附的膠帶，這樣是否另有用意？不過我還是寧可使用原廠給的材料來固定。

交互比較之後，覺得 GR-160 的握感真的很優，之前我都是用薄型的握把皮，往後我都會優先考慮使用 GR-160 這類的厚型握把皮。

最近因為 Web 2.0 站台資料儲存的 scaling 議題，以及霧雲端運算正夯的關係，很多地方開始用起了所謂非關聯式資料庫的資料倉儲軟體 (Non-relational Data Stores)，俗稱 NoSQL。因為這些東西真是夠噱頭，所以連我也忍不住拿了一些像是 Tokyo Cabinet, MongoDB, Cassandra 的 NoSQL 產品來玩。

要先說明的是，這些 NoSQL 產品跟既有的關聯式資料庫產品（如 MySQL, PostgreSQL, MS SQL Server, Oracle 等）並不是打對台、有你就沒有我的關係，而是必須相輔相成、互補不足、各有擅場的，而這些 NoSQL 產品也各有差異。所以想玩的人就看自己需求挑幾款適合的來玩、來學，並不需要有什麼選邊站的考量。

那麼，我又是根據什麼需求來評估、導入 NoSQL 產品？那是因為我在實務中遭遇到了暗黑圖資界、數位典藏界的 schemaless data, semi-structured data, hierarchical data structure，比如像是 XML 和 MARC，拿關聯式資料庫來處理，做起來會讓人血尿控訴的問題。當我看到了某些 NoSQL 產品可以較容易處理這類資料時，我的眼鏡突然閃過一道光芒（請參考名偵探柯南）。

我看過、用過、經手過的數位典藏系統環境，讀多於寫、數位物件佔用空間的問題比其後設資料要大，看起來很像是 flickr 這類相簿網站的架構，卻又因為每個單位自己做自己各自的系統，所以個體規模又沒大到需要擔心 scaling 的問題；倒是為了常要遷就關聯式資料庫，而讓原本就不太能打平的資料結構硬要打平，反倒丟失了原有結構所能呈現的較嚴謹的語意。又或者用了超級恐怖的方式去把這些半結構化資料放進去關聯式資料庫、再用非常可怕的方式讀出來，反而失去了關連、正規化的意義，又耗掉可觀的效能。

所以我才想要找這類 document store, native XML database 的解決方案。

或許有人看到這裡會跟我介紹有「某字母系統」這種東西，我只能說，我不是沒用過，使用過的觀感，實在是很無言。而且呢，「某字母系統」並不是可以自由取得的，遑論使用、修改、散佈。

所以我才想要找這類 document store, native XML database 的 Free Software or Open Source Software 解決方案，好重新發明輪子。

目前我看到、想到幾組有趣的組合是：

• JCR (Content repository API for Java): Jackrabbit + Sling + Rails, ref: [Sling’s RESTful API for Content Repositories « contentGoesHere]

• MongoDB + (XmlSimple | Cobra vs Mongoose) + Rails

我希望能夠提供一組 F/OSS 的「統整資源管理系統」，讓圖資機構原先設計還算不錯的後設資料結構，所產出的後設資料，就悉數存進去、讀出來啊（而且還要很好存、很好讀），何苦東減西扣的？

附註：標題為少年漫畫常見梗，純無厘頭，謝絕借題發揮。

自行車（腳踏車、單車）的前燈是給騎士照明前方路況用的，後燈才是用來警示他人的。所以前燈請勿開閃爍，並請調整以「照路」為用途的俯照角度，而不是用您超亮的車燈去妨礙對向行人、駕駛的視覺。