影像紀錄區 紀錄一下這段時間發生的一些事情與未來的方向

五月份幾乎都在建構影像紀錄區功能，雖然主要上傳照片的功能在網站上線之後就沒什麼變更了，但整個網站的效能與使用者操作一直不斷的調整、測試。所以紀錄一下這段時間發生的一些事情與未來的方向，當作五月最後的結尾！

MongoDB

這次影像紀錄區用的資料庫是 MongoDB，也是我第一次實際應用在網站上，因為影像紀錄區 2008 年版本有使用過 MySQL 的經驗，所以這次在檢視 MongoDB 時，有特別注意看是否能把需要的資料庫資料檢索出來。MongoDB 有一張 MySQL 對照表，基本上都可以對映過去。而且比較喜歡像 MongoDB 這類 NoSQL Free-schema 的特性，這樣隨意擴充的彈性有時真的對於初期開發還滿快速的。像影像紀錄區的例子，只要關注 postid 與 userid 這唯一（key）的辨識資料，其他就可以隨意的擴充出新的資料內容。

MongoDB Master-Slaves

通常會用到 Master-Slaves 是因為網站上可能需要大量的讀寫，所以才需要建構 Slaves（只能讀） 分擔 Master（寫/讀） 的讀取。不過影像紀錄區目前還沒有這樣的需求，即使一台 Master 就可以應付了，但是 Master-Slaves 除了分擔 Master 以外，還可以當作備份來使用。所以我想說還是要做備份的話，那就實作看看 MongoDB 的 Master-Slaves。網站上有教學，也有範例在 Master 死掉如何用 Slaves 恢復，所以我就建構了兩個 Slaves 來當作分擔與備份。老實說就回應的速度有提升。

不過剛上線的時候遇到了 Data inconsistency 的問題，不確定是我設計的問題還是如何，像是 MongoDB 沒有 auto increment 的功能，所以必須額外儲存 value，透過 +1、取得、存入的方式手動，這中間一定會發生問題，所以在後端程式在寫的時候我儘量把所有要寫入的資料備齊之後，才呼叫這流程。另外之前也忘記 Slaves 也會有 sync delay 的問題，所以在執行這個流程時指定只向 Master 取值，要不然會出事。但目前我還是覺得用 increment value 是個錯誤，因為就直接用 uuid 來產生 uni key，再要不然就是直接用 MongoDB 的 _id 就好了。感覺有點多此一舉。只因為產生一段亂數字串看起來有點噁心！

MongoDB Index

目前也產生一些 Index，不過文件是寫說 32MB 以下的資料是感覺不出來的，也就是說目前這資料量我還感覺不太出來，但我還是先產生了。

Celery

Tasks 服務我是用 Celery，不過這裡我真的踩到一個地雷，但還好也平安移除這地雷。由於 Celery 目前沒有辦法多帳號共存，一台機器只能有一個服務，在網路上找到很多人都說沒有辦法解決。之前還想說把 Celery 執行檔切割成兩份，但這方法失敗，會互相覆蓋，也試過 python 跨資料夾存取模組的方式，但也是失敗。不過我試了一天之後想到一個架構，由於一台機器只認一個 Celery，那我就乾脆以這個點出發。

以 Celery 為最頂端（C1），因為我主機裡面有兩個網站，分別為 W1、W2。我就將 W1、W2 的 celery_task 都複製一份到 C1，因為 Celery 的啟動的時候會載入自訂的 Task class，所以我要先讓 Celery 知道有哪些 class，之後我在 W1 或 W2 import 的時候，只要 task class name 一樣，就可以騙過 Celery，但這樣唯一個缺點就是 C1 裡都要與 W1、W2 一樣的 class 與相關的 class。目前就是這樣解決這問題，網路上完全沒有看到相關的建議，那時候真的快瘋掉。因為像是照片 EXIF 解析有點耗時的功能丟給 Celery 排程處理最好的，總不能讓使用者等完上傳後還要等處理吧！

wookmark

我記得我在 twitter 看到有人分享 wookmark 的 jQuery plugin，所以影像紀錄區是套用這樣板當作網站風格的，雖然每個人都說是 Pinterest 風格，但無庸置疑的 wookmark 也是這一類的服務網站。只是當初我單純的覺得這樣的瀏覽方式，對於大量的影像來說還不錯。之後 WM 建議我改用 jQuery Masonry 來呈現，我試用之後也覺得其實這套比較好用，作者也比較有在維護，只是目前還要大規模的更改，所以還沒那麼快換過去，但某些頁面有小部份的套用 Masonry，例如所有使用者頁面。

申請加入

影像紀錄區目前提供填單申請，然後審閱後寄送邀請函加入，會這樣做還是因為目前沒有人可以管理 XD，稍微還是挑一下使用者加入，減少管理的成本。不過還是希望使用者真的有攝影作品產量，因為審閱時會簡單的查詢是否真的有攝影作品，所以如果使用者在網路上找不到作品的話，會比較慢拿到邀請函。感覺好現實喔，真是抱歉，人員不夠，（暫時）一切從簡！

Amazon

截至今天為止，五月在 Amazon 上的花費是 0.55 美金，這費用包含 S3、SES 服務與檔案傳輸：

• S3：$0.16，（114K/10K + 5K/1K requests） * $0.01
• SES：$0.09（$0.01 per 100 mail）
• AWS Data Transfer：$0.3，15G 的免費傳輸用完了，所以超出部份以 $0.201 per GB 計費（東京）

以目前這樣的費用好像還好，檔案傳輸的費用負擔比較重，但暫時也用不到 CloudFront，不過這個月也一直在看其他相關網站怎樣用 Amazon 的服務，像是最近被 Facebook 買下來的 Instagram，就有分享他們是怎樣建構在 Amazon 上。所以弄的我也好想把影像紀錄區的架構調整一下放到 EC2 上面。前幾天活動遇到 Ernest，也請教他很多關於 Amazon 實際應用的例子，收穫良多，超感謝！但接下來如何調整、搬移到 Amazon 我可能要來評估一下未來影像紀錄區的走向…

影像紀錄區未來的方向

其實打從一開始只是想用影像紀錄區把以前的社員找回來，所以還是用 isuphoto.org 這網址建構，一方面它曾經存在過，和攝影社一起成長…不過眼尖的人可能會發現好像網站上 "義守大學"、"攝影社" 的關鍵字都不見了，其實我是有一點耍脾氣啦。有一天開發一個功能出來，結果我本來服務的對象竟然說出這樣的話，我不是很喜歡這樣的玩笑，一氣之下就決定開放給大家吧！讓喜愛攝影的也喜愛這平台的人繼續用影像切戳技能！

還有 3 個人給我按讚 XD

所以突然一個大轉彎是從這裡開始的，當然也讓我想到 "服務還是要經過市場的考驗"，那就不如早點開放給大家吧！來自不同地方的意見可能會更好玩、更有挑戰性吧！影像紀錄區當初就是希望以紀錄生活影像的概念，希望大家（社員）能夠動手多拍照，再透過分享的方式看到其他人的拍攝技巧與風格的一個平台誕生。即使到現在這樣的概念還是不變，只是不再只是校園而已，畢竟大家都畢業了！攝影社也該畢業面對社會了！（好沉重…）

所以未來就是繼續找到更多攝影同好進駐，紀錄更多攝影作品，讓攝影同好拍完照片之後會急著想要上傳到影像紀錄區分享！

Firefox x Ubuntu 12(.04) Release Party

5/27 參加 Party 有上去講閃電秀，不過在輪到閃電秀之前，突然看著大家也做那麼多好玩的事情，感覺自己好渺小喔！坐在底下突然感慨了起來，因為今年好像沒幫到 MozTW 什麼忙，看 Irvin 好辛苦。本來想說不要上去講了，但大老遠跑來台中，也印了一盒名片準備要發，這樣縮頭有點鳥！不過站到台上之後又有很多東西想說出來，所以搞到最後後面都用跳的，講不完。

我記得 Bob 說過：「為一個團體無私的奉獻，每個人心中一定都有其目的。」有的是名、有的是利，但不要利用別人就好了（善意），反過來看著自己，至少此刻是微笑著！

最後

現在到 9 月會變得很忙，中間還有 PyCon、COSCUP，今年 COSCUP 接行政工作。可能影像紀錄區就不會花太多時間在上面，但還是會利用這兩個研討會宣傳。所有的事情就等 9 月之後再說吧！