2012年12月31日 星期一

2012 年末換了 Canon 6D

2012 年快結束了,年底影像紀錄區程式的部份也將到一段落,這幾個月以來,影像紀錄區意外的讓我接到朋友明年結婚拍攝的委託,而且還不少對。年初退伍到現在幫朋友的朋友拍過幾場迎娶、婚禮,也拍到不少的好作品,本來是想說等到 10 萬張再來換相機,但覺得如果大家委託給你來幫忙拍攝,也應該要有一定的影像品質,所以還是將我那台從大學用到現在快8年的 Canon 350D 退下來,換一台比較好一點的相機。

這一跳就直接跳上全幅機,本來要買 5D 系列,但看到價格倒吸了好多口氣,剛好 Canon 6D 在 12 月上市,價格也還算 OK,雖然網路上很多人講說對焦點給的很少,但老實說我用 350D 也是少少的對焦點,對我來說好像沒差,會不會拍才是重點 XD,12/24 購得 6D 不過到了 12/26 我才開箱使用,翻完說明書就背著相機出門試拍

將 Canon 6D 所附的 kit 鏡,換成 Sigma 24-70mm F2.8,會換這顆主要是恆定大光圈,因為本來還要買 Sigma 35mm F1.4,但缺貨要排隊等到 2013/1 中才可能有貨,評估一下焦段和恆定大光圈,對於要強快卡位推到望遠端拍攝或是大場面推回到廣角端都還不錯,所以才換掉 Kit。不過 Sigma 35mm F1.4 這顆還在思考要不要購入,因為焦段有點重疊到,只是不知道畫質好不好,值不值得購入。

另外還有一個很吸引我的功能,這8年來 DSLR 也朝向欲取代 DV 的方向發展,所以錄影功能幾乎變成基本配備,有些美國影集也都是用 DSLR 來拍攝,況且之前也借過別人的相機試拍過,所以錄影功能是我最期待的。現在出門拍照都會稍微錄一些影像回來研究看效果如何。

接下來我就要從電腦前面移到麻豆相機前面,把影像紀錄區帶向下一個階段,所以如果覺得我的作品還不錯,歡迎內洽~



Update 2012-01-29
購入後也拍了不少影片,之後 Sigma 35mm F1.4 也到手了,推薦觀賞此短片。或是訂閱我的頻道

2012年11月30日 星期五

11 月份飛逝…

這個月過的很快,到最後一天都還不敢相信。影像紀錄區月初發佈尋找攝影師功能後,持續開發攝影活動的功能,本來預計要以一個禮拜一新功能的快速推進方式,但實在是遇到我這龜毛的個性,到今天才順利上線。接下來 12 月份影像紀錄區要規劃 Model 的區塊,模式與攝影履歷類似,補齊攝影的一些元素。

另外這禮拜也與幾位前輩分享影像紀錄區,不過普遍得到的問題都類似,如果輕鬆面對,老實來說影像紀錄區可能就只是單純的圖像分享網站,想到就上傳圖片。但如果要認真當一回事,目前還有很大的努力空間。不過老實說,影像紀錄區算是我第一個很認真去思考他的未來…

11 月真的過的很快,好像沒唸到什麼新東西,只記得有調整一下 nginx Gzip 的設定,也在影像紀錄區的 response header 放一個彩蛋,也準備轉移 DNS 到 Amazon Route53,其他的好像也沒有什麼…

對了,還有一件事 11/29 我家的咪咪突然死掉了…

2012年10月31日 星期三

MOPCON 閃電秀 用照片說故事 - 影像紀錄區

嚴格來說影像紀錄區目前都還沒有在台灣主要的 conf. 曝光過,通常我都會報名閃電秀來趁機宣傳一下我的作品,但今年除了 OSDC 外,PyConTW 是抱著學習的心態去參加、COSCUP 是因為當工作人員所以沒時間準備內容,直到 10/27 在高雄舉辦的 MOPCON 我才在閃電秀上面分享影像紀錄區

覺得閃電秀才是我的舞台,太長的分享時間有點不是我的 style。雖然 MOPCON 我也是有當工作人員,但偷偷看著閃電秀那張填寫報名海報,手又好癢、好心動,所以最後還是報了,大概花一小時完成五分鐘的簡報。

閃電秀簡報的流程之前就有在腦子裡排過,因為這幾個月來一直在分享影像紀錄區技術的部份,講到我都累了,聽的人應該也膩了,所以應該換個方式來宣傳影像紀錄區,那當然就是帶大家看圖,然後聽我說故事…

簡報中的作品都可以在影像紀錄區我的個人頁找到,以下就是閃電秀的簡報:

2012年10月8日 星期一

KSDG Python and MongoDB for web

這是 10/4KSDG 分享的主題, 內容主要是分享影像紀錄區如何利用 PythonMongoDB。簡報分兩部份:上半部談技術,下半部談網站未來的經營(56 頁開始)。線上簡報如果難以閱讀,也可以下載 PDF 檔


原本預定在 8 月份分享,但遇到颱風,移到 10 月份分享。不過還好移到 10 月,要不然我覺得在 8 月份的時候可能沒有像現在有那麼多東西可以講。在簡報 56 頁開始是我比較想與大家分享的,是關於影像紀錄區《現況與未來》,有興趣的請看簡報,在這裡就不再重覆敘述!

2012年9月28日 星期五

Twitter Cards

Twitter cards 是 Twitter 目前測試在 tweets 裡嵌入媒體內容的功能,之前只有類似 Youtube、instagram 或 Twitter 認可的上傳圖片服務才能在 tweets 內顯示出內容。一開始 Twitter cards 的文件出來時,我就有把影像紀錄區加入需要的 header,直到前陣子 Twitter 開始開放申請登記,趕緊幫影像紀錄區填表申請。就在今天(9/27)凌晨收到審核通過的通知,現在可以在 Twitter 中直接展現作品圖片。


Twitter cards 和 Facebook Open Graph 一樣,只要在 header 裡面加入相關的屬性。Twitter cards 有三種類型: "summary"、"photo"、"player",影像紀錄區在各作品頁面設定 "photo" 的類型。例如這個作品 #622tweet 範例
<meta name="twitter:card" content="photo">
<meta name="twitter:title" content="Toomore (toomore) #622 作品">
<meta name="twitter:description" content="這條巷子可以看到 85 大樓… By toomore">
<meta name="twitter:image" content="http://pic.isuphoto.org/622_m_img7967.jpg">
<meta name="twitter:url" content="http://pi.isuphoto.org/post/622">
<meta name="twitter:creator" content="@toomore">
<meta name="twitter:site" content="@pi_isuphoto_org">
也可以使用 Twitter 提供的預覽工具測試,觀察所設定的值是否正確。最後如果都沒有問題,就可以填表申請 Twitter cards,然後再等個幾天審核通過。

另外如果頁面本身就有使用 Facebook 的 Open Graph header 設定,Twitter 也會直接套用 Facebook 的參數值,如果找不到 Twitter cards 時。當然要讓 Twitter 辨識的出來就還是要填寫申請單。

Update 2012/09/28 04:35
補一張透過 Twitter app 看到的畫面

2012年9月5日 星期三

MongoDB 2.2 新功能 存活時間 TTL 用法

MongoDB 在 8/29/2012 發佈 2.2 版本,其中有一項功能我很期待,就是存活時間 (TTL, Time to live),以下整理文件的內容:


基本運作
MongoDB 透過 mongod 背景處理過期的資料,頻率為一分鐘一次。在建立索引時(ensureIndex)加入 expireAfterSeconds 選項與秒數就可以完成 TTL 設定。

限制
  • 索引欄位必須為 BSON 的時間格式,如果不是時間格式,TTL 就無效。
  • _id 欄位不能設定為 TTL 的時間索引欄位。(這有點可惜,ObjectID 本身既有時間紀錄在裡面,還需要再指定一個時間欄位有點多餘…)
  • 如果時間欄位是陣列(array)包含多個時間值,則以最近的時間為基準設定。
  • 不可以在 Capped Collections 設定 TTL,因為 Capped Collections 格式的資料本身就無法刪除。
  • 在某些情況下,過期的資料還會存在,直到下一個 mongod 定期的刪除循環止。

設定
假設有一 Collection 名稱為 "forgetpwd",存活時間為 1800 秒,建立 TTL 索引時可以用以下設定:
db.forgetpwd.ensureIndex({'date': 1}, {expireAfterSeconds: 1800})
建立資料:
db.forgetpwd.save({'user': 'toomore', 'date': New Date()})
建立資料後,該筆資料就會以 date 欄位的時間 + 1800 秒後刪除。以上的範例可以實作在使用者忘記密碼的流程裡:使用者使用忘記密碼時,請求一個有時效的重新設定密碼連結,在限定時間內設定新密碼,否則取消請求連結

以上為 MongoDB TTL 的用法。

2012年8月27日 星期一

COSCUP2012 行政組 感想與心得

把今年參與 COSCUP 2012 活動紀錄起來。

最早參與 COSCUP 是在 2008 年,那時候是幫忙 MozTW 擺攤位,不過事後想一想,應該是以 MozTW 幫 Mozilla 擺攤位,因為那時候是沒有社群攤位的。隔年 2009 年擔任紀錄組組員,創下一人拍全場的紀錄,那時候還在台大,還增加為兩個議程軌,其實是錯估情勢才會創下這紀錄,而現在的紀錄組已經壯大到很專業了。2011 年去當兵,所以沒有參與到 COSCUP。

退伍後想說沒什麼事,找 2011 年行政組長小菲(她說還會再接一年),詢問 2012 年有沒有行政組員可以加入。只是沒想到小菲竟然說她臨時有事情,希望我接下組長的職位,她說她會協助我,所以在2月份的時候交接,我就接下組長的職位。

招募
行政組在 2011 年的編制是1組長 + 2組員,主要的工作任務是講者晚宴、慶功宴、工作人員住宿、交通費補助、總召秘書。2012 年新增了2個任務:人事登錄、網站上稿。編制的部份調整為1組長 + 1副組長 + 2組員。而 2011 年的組員 AnnaBryan 分別出國唸書與轉戰會眾組的關係,2012 年的組員就必須重新招募,而我也與小菲決定以公開方式進行招募,令人驚訝的是還挺多人提出申請。

大約2月中就確定組員了,保留去年的精神,所以今年招募的組員也是一女一男,而申請人數的比例為 6:1(男:女)。不過接下來這裡我就要自我檢討一下,當初招募的時候只審大家的自我介紹,而小菲是希望可以用 skype 與他們聊過,這樣的評估方式會比較好,但我實在是太懶惰,我只就自我介紹與 Blog 文章來判斷。最後挑選了 SammyMaxine。不過我是到了4月 OSDC 才見到他們本人,所以……

工作人員登錄
在 6 月份之前,大部份都是處理其他組別工作人員登錄事宜,由行政組統一登錄或登出人員,但是不影響各組組長的人事決議權。為什麼要統一在行政組這裡處理,因為人員登入之後還要設定相關的 mailling list、Redmine。即使到最後場務的人員招募,還是要統一在行政組這裡填登錄表單,統一建檔紀錄。

說到場務組人員登錄,在這之前的人員登錄都是少量的,所以可以手動慢慢來處理,但場務組確定人數之後是會提交一份約 50 人的名單,這時候在慢慢處理可能會瘋掉,所以只好用 python + Amazon SES 來寫大量傳送郵件的小腳本,處理這部份的狀況。之後在講者晚宴發給講者的通知信、工作人員交通費申請說明也用到相同的腳本處理。(其實是 copy 之前影像紀錄區發電子報的…)

工作人員住宿
在一開始的時候工作人員住宿面臨到一個很大的問題,中研院沒有房間可以住,7月初有上台北一趟去看西門町民宿的環境,不過台北日租套房好像抓的很嚴重,打電話給套房的人希望可以看內部的狀況,但他們防衛心很強,況且一定要先付款才算訂房完成,所以非常的不保險!

不管住中研院外面的哪裡,一定都會很麻煩,對工作人員來說往返會場的時間愈少愈好,這樣睡覺時間就會比較多,要不然兩天的活動其實很耗體力… 在陷入找不到合適的房間給工作人員住時,中研院傳來好消息,有房間可以讓我們訂,才把這件事情處理完。

網站上稿
網站上稿今年交由行政組處理,老實說當初接到以為要動到原始碼,還好去年 timdream魏藥把網站寫的很棒,只要簡單改的設定就可以新增頁面,甚至後端接到 Google Docs 填空補滿就可以完成議程表與贊助商資訊,真是厲害!

不過我還是希望明年會有網站組,因為遇到技術的問題,還是交給專業的來處理會比較好。

講者晚宴與慶功宴
6月份開始找餐廳,將講者晚宴與慶功宴的部份分配給組員找,有無適合的餐廳可以容納 80~120 人左右的場地。之前有聽說過 OSDC 的慶功宴把一家店給癱瘓了!所以特別注意餐點供應速度的問題,人太多,店家也會怕!不過在這裡一位組員退出…之後小菲找了三秒來幫忙,三秒果然老練!提供了很多做事的經驗,又與 Sammy 把講者晚宴與慶功宴的部份都處理好了!場勘許多家餐聽後,還是華漾比較能夠符合我們的需求,而且他們也都知道我們活動的模式,所以最後還是在華漾舉辦兩場的晚宴。也感謝 Bryan 當天陪我場勘,提醒一些細節。

講者晚宴的名單到晚宴當天早上還有變動,理論上晚宴報名是有截止時間,但是在一次開會時,我們還是認為講者晚宴是為講者舉辦的,既然講者都願意出席了,在訂位的緩衝裡面就儘量讓講者參加,最後講者晚宴就近 85 位參加(講者、講者攜伴、議程主持人、工作人員…),雖然最後有些講者沒到,這我們會另外處理,留給後面的人參考 XD

開會
在活動前一個月以前,行政組大致上是兩個禮拜開一次,到了最後一個月才改為一個禮拜開一次,而開會時間是在禮拜四晚上 22:00(約到 24:00 結束),有些人看到這時間會傻眼,挑這麼晚的時間開會,但好像也沒人反應太晚,所以就都定在那時間用 skype 開會。到最後大家都會習慣帶零食邊吃邊開會,不知道為什麼,開會特別容易肚子餓,是因為有動腦嗎?

副組長
其實在 COSCUP 的組織架構裡面是沒有副組長的定義,組長外通通都是組員,反正大家都要一起幫忙做事情。但由於沒參與過去年的工作人員(事實上 2009 之後就沒當過 COSCUP 工作人員),所以還是希望有個參與過活動的人可以諮詢意見,才把小菲設定在副組長的位置。在我心裡行政組的架構是副組長(許小菲)高於組長(我) XD(情勢所逼)。

狐狸耳朵
恩,在活動前一個禮拜突然想到還是來縫些狐狸耳朵給 MozTW,因為材料有剩(是還剩多少阿!)又改良一下舊版的耳朵,加入一直沒用到的白色絨毛布,也設計成內耳,讓今年狐狸耳朵比較有立體感

結論
其實我都希望可以很淡定的解決問題,可能是當兵時的觀念,接到任務就想辦法解決。小菲也是說組長要有「一肩扛起」的心理準備。老實說行政組是沒什麼大問題(還好問題都在一開始就發生),最多就是行政流程還需要改進,然後把檢討資料寫詳細一點,留給後面的人參考。所以有時候遇到分歧的時候,都希望可以把情緒調整好,放太多情緒進來思考一定會變得很不理智,偏偏我本人公歸公、私歸私,任務沒有達成就真的快抽離,不要再和我說太多情緒理由,因為我就真的不會安慰人。

組員 Sammy 也讓我很意外,有一陣子我在研究 Amazon 的服務,上網找資料都會發現 Sammy 寫的文章,一開始我還以為是同名同姓,原來我的組員都深藏不露!做事也很讓人放心。小菲三秒其實我都是當諮詢顧問來虛心請教,還好他們也都不吝指正我的缺失,感謝他們啦!

大致上就這樣,短短的六個月,在行政組的感想與心得。

2012年7月29日 星期日

長的很像影像紀錄區的 fandora.tw


前幾天在看一篇文章的時候發現一個網站和我做的影像紀錄區很像,甚至也有更新紀錄這一類的頁面。老實說當下看到是覺得好像有滿多的東西很相似,有的人認為他們抄襲,點右鍵看一下原始碼也發現用到的套件幾乎影像紀錄區也有用到。但如開頭提到的文章一樣,作品本來就抄來抄去,或許我們剛好都找到相同類似較佳的呈現方式

但以上都不是我想要知道的,本來今年是要報名 AppWorks,但因為某些原因不報了,而在決定不報的同時剛好開始製作影像紀錄區。直到前幾天才發現原來有和影像紀錄區類似的作品正在 AppWorks 孵育,所以我比較好奇他們的營運模式,我想要知道他們如何導出獲利模式!雖然他們是畫作(也很好奇為什麼是畫作) + 攝影,而我們比較偏向專注在攝影的部份,但一樣都是想要迎造出一個同興趣的社群平台。

當然也不可否認我的靈感絕對不是原創的,我是參考 wookmark 的樣板與 instagram 後端架構而誕生的,詳細的介紹可以參考「影像紀錄區 紀錄一下這段時間發生的一些事情與未來的方向」。

或許像是現實生活中的撞衫吧!最後我想我們應該也要來 Pivots 一下 ;)

2012年5月30日 星期三

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

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

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 美金,這費用包含 S3SES 服務與檔案傳輸:
  • 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 月會變得很忙,中間還有 PyConCOSCUP,今年 COSCUP 接行政工作。可能影像紀錄區就不會花太多時間在上面,但還是會利用這兩個研討會宣傳。所有的事情就等 9 月之後再說吧!

2012年5月21日 星期一

MongoDB Master/Slave with pymongo

前幾天把影像紀錄區的 MongoDB 加入 Master/Slave 機制,目前是 Master + 2 x Slaves,但我非常的白痴,以為這樣設定建立好之後就沒事了,也以為網站效能會提升之類的,當我在看系統資源監控的時候發現兩個 Slaves 的使用率好低好低,低到好像沒有在運作一般。

沒錯,在 MongoDB 設定完之後,Python 驅動 MongoDB 的 pymongo 要使用 MasterSlaveConnection 指定誰是 Master、Slaves,這樣才真的可以讓這機制產生效用。

就這麼簡單設定完成!影像紀錄區有明顯的感覺到資料讀取速度有比較快了!MongoDB 的文件提到如果發生意外,怎樣對調 Master 與 Slave,只是看著看著笑出來了,因為寫的好詳細 XD

至於 MongoDB 另外一個與資料庫分佈有關的 sharding,我想目前應該是實作不到,一方面影像紀錄區的資料量沒這麼多,另一方面是我也沒多的機器來操作,不過我倒是有想到 grs 要不要來建一個各股歷史資料庫,把證交所的資料倒進來,好像也可以齁!

2012年5月7日 星期一

義守大學攝影社影像紀錄區 重新開張

大約在4月底的時候與學長聊天,聊到以前攝影社的影像紀錄區,可以讓社員上傳作品的平台,那時候我們就是以這項強大的網站服務來吸收社員,所以只要入社就有帳號可以使用。 距離事件發生也過了3年了,2009 年莫拉克颱風的關係,把原本架在財金系的攝影社網站給摧毀掉了,之後也找不到合適的主機架站,就這樣一直延盪到最近。

前陣子作完 grs 的網站後,發現一些東西在做網站的時候可以迅速建立,所以就乾脆以現在比較拿手的 Python 來重寫一個影像紀錄區。大約花了一個禮拜的時間,網站就上線了!基本的架構用到:Python + Flask + uWSGI + nginx + MongoDB,另外社員上傳後的圖片是丟到 amazon S3 服務,現在大家都愛談雲端,那就來實作這部份,圖片都丟到雲上面去!

另外就是 MongoDB 的部份,之前 grs 都沒有使用到資料庫,而我又不是很想用 MySQL,所以就決定來實作 NoSQL 資料庫的應用,於是就選擇 MongoDB 當作底層的資料庫系統。雖然剛開始用的時候還是會有之前用 MySQL 影響在,但後來使用 MongoDB 就會發現 NoSQL 資料庫的優點,很適合這小小的網站來使用。

這幾天也加入 Facebook、twitter 的連結,當社員發佈作品的時候,也會同步到這兩個社群服務,希望這樣可以增加曝光率,讓更多人來看我們分享的作品。現在網站是上線了,但有些功能還沒有寫完,只能慢慢調整、慢慢補,反正功能寫的差不多就上線,看大家使用的怎樣在調整修改,這樣比較好,要不然會有盲點。

不過我在思考一件事情,之後要開放給大家使用嗎?或許可以變成一個攝影同好交流的平台也不錯!

2012年4月26日 星期四

用 Nexmo 發送簡訊,台灣 USD 0.013

老實說 Nexmo 價格真的便宜傳到台灣只要 USD $0.0145(*29.662 = TWD $0.43),而且又提供 RESTfulAPI 使用,台灣的部份支援:中華電信、遠傳電信、威寶電信、台灣大哥大(疑,亞太電信勒!)

不過 sender 的地方因為可以自行設定,有些電信商會當作 spam 過慮掉,官網是說用完整的國際電話格式避開,但好像還是有些問題。不過還不錯用,比 PChome 的一元簡訊便宜。

附上簡單的 Python 發送程式:

2012年3月31日 星期六

搬出 GAE 的 3 月在 Heroku 玩瘋!

自從 2 月底北上參加 GTUG 辦的,小海大大講的關於如何將應用程式搬出 Google AppEngine 後,整個 3 月就在測試另一個 PaaS - Heroku

去年 Google AppEngine(簡稱 GAE) 調整價格之後,可以免費使用的資源變得相當稀少,對於需要大量運算的服務就會變得綁手綁腳,況且 GAE 的開發環境有點詭異,無法使用豐富的 Python 套件庫 PyPI,所有需要的功能不是使用 GAE 提供的 API 就是要自己重新打造,我不是什麼大大阿,雖然動手寫程式可以提升功力,但這樣動不動就要自己打造所需的功能,最後削減的是開發的熱情。

我只能說,短短的一個月,整個開發速度似乎飛了起來,原來不用 GAE 就好像打通了任督二脈一樣,原來除了 GAE 以外,還有這麼好玩又這麼自由的平台,即使也是需要動手建造,但手邊的工具、零件變多了,愈玩愈起勁!就這樣,我把改寫的 grs 包成蛇蛋,在 Heroku 上建立一個 Demo 網站(實作才知道還缺什麼功能)用 Flask 輕量的框架,學會完成前端瀏覽器的 cache 設定,也找到 Flask 用的 gzip 來壓縮內容傳輸。也試用 NoSQL 的 Redis,發現好用的 requests,找到可以取代 GAE Task 的 celery。也搞懂 virtualenv 環境區隔對開發來說很重要,懶惰還可以丟給 Travis CI 幫忙檢測在不同版本下安裝狀況。以上種種,每每的發現都能帶來不可思議的喜悅,這就是開發過程、好玩的地方!

Heroku 上面有滿多 Add-ons 可以使用,一個禮拜去看一次會發現又有很多新的 Add-ons 冒出來。這裡有個偷吃步的方式,雖然每個 add-ons 安裝後都會專屬的帳戶設定值,但這設定值沒有綁定在 app 上,所以其實多開幾個 app 互相使用。例如 A 是上線網站(web.1),可以用 B 跑 worker.1 幫忙 A 建立 memcache 或是 Task 服務。每個 app 有 750 hrs 免費使用,而唯一的計算單位就只有使用小時,沒有什麼傳輸量計算之類的,有限制大概就是每個 Dyno 的記憶體限定吧!

2 月不知道是怎樣,約每七天我的筆電 SSD 就死掉一次!但很神奇的整整 3 月份的沒出事,直到 3/31 才掛掉,雖然之前參考設定 SSD 的寫入次數,不過這次參考重新掃描一次,希望這次可以凍再久一點!

3 月北上參加 Mozilla Taiwan 入厝活動,和好多人交換意見,最後還是打算要去台北闖闖,要不就是多停留在台北一陣子,手指頭故障的國瑋學長聽說會住到年底,他那裡風景好,又能俯瞰得到大台北真棒!所以我應該會跪求他出租沙發給我睡吧!反正吃、網路都他包(誤)!

2012年2月21日 星期二

這幾天看到的文章 Python Git YouTube

這幾天看到幾篇還不錯的文章,在這裡做個筆記。

如標題,如何做一個、接受一個 patch,用到 git-format-patch、git-apply、git-am。其實  git-format-patch 有 -o 的參數,後面接要輸出的資料夾就可以把 patch 產生到指定的資料夾。

這一篇酷了!主要是討論前陣子很流行的 git-flow,一個專案開發流程。這篇作者在 github 工作,也到處講授 git,常常遇到有人問他關於 git-flow 的看法,不過作者點出一些 git-flow 的問題,然後很好奇 github 內部的 work flow 是如何?也做了一番的介紹,提出了五大點。有興趣的可以閱讀!(中文整理文章:練習是不會騙人的 • 在 GitHub 當中使用的 work flow

這篇看標題就知道了,和感情有關的,只是用很科學的方式來解釋這感性的問題,文章有點長,但建議花點時間看完。另外作者有提醒:[12]本文為書寫方便故,大多以男性觀點寫成;但是過去研究顯示男女在戀愛或關係維持的變項上相似處比相異處還多(APA, 2005),故暫且可feel free置換描述觀點為女性,結果大致相仿。

至於我看完的心得,當然想通了很多事情,對最近發生的事情也比較能夠釋懷,畢竟我相信科學的解釋!

這是去年 Dropbox 在 PyCon 上簡報 Python 如何解決一些問題,Dropbox 應該算是目前最受歡迎的檔案同步軟體,尤其像在好幾台電腦上工作的人,或是小團隊要取得最新的專案文件時,Dropbox 真是好用又無負擔的小工具。跨平台的部份都是用 Python 去完成,當然講者也提到除了 Android、iPhone 不是用 Python ,因為記憶體與效能的問題。

最後

這影片實在太酷了,影片的女主角很兇,可是很正!當然也是要神一下這女主角是誰,底下有演員名單:宋芸樺。當然也有 Facebook!另外要提一下 StreetVoice,這是一個讓創作人發表作品的平台,感覺還不錯,也聚集滿多的創作者,公司最近也在徵人,說可以和正妹一起工作?

2012年2月12日 星期日

麥片不好吃,所以人類在夜晚睡覺


不知道有多少個夜晚是麥片配電腦,自從家裡多了一台熱水壺之後,吃泡麵、喝麥片就變得很方便(疑,還有押韻!)

在夜裡做事情有個好處,就是什麼都很安靜,可以專心在事情上,但是就是太安靜了,有時也會陷入恐懼寂寞、回憶過去的黑洞裡!這時候就要趕快把自己再從黑洞裡拉出來,再把思緒回到事情上。

但是黑夜到底害怕什麼,人類演化過程是因為害怕寂寞,所以才會在黑夜睡覺嗎?還是因為麥片不好吃,索性就去睡覺了 ......

2012年2月5日 星期日

一起等地球爆炸吧

這首歌好好聽,一開始不確定歌詞內容,唱了一遍之後才發現好像在哪裡聽過,想起來了!在《他們在畢業的前一天爆炸》第二集裡,阿丁做一首歌要送給浩遠當生日禮物,唱的就是這首俏皮的歌。所以有此可證,通常都是拿自己最擅長的技能,親手為喜歡的人做禮物!

我知道棉花糖負責《爆炸》的音樂,但一直都沒聽過這首歌完整的呈現,但在 2011 年年底棉花糖就發了這首歌的 EP


一起等地球爆炸吧
詞:莊鵑瑛 曲:沈聖哲

握你的手‭ ‬那天的風好溫柔‭ ‬想這樣一直走
多吃蔬菜多做運動 讓自己活得更久

我會努力 完成自己的生活‭ ‬不再任性揮霍
計劃著我們的世界環遊 告別孤單的稀薄

等晴天 等雨天 等不及和你見面
等每一個大冒險

登不上 太空船 那就等地球爆炸
死在同一個地方 反正你就在身旁

2012年2月1日 星期三

文庫本筆記本


買了一本 MUJI 文庫本的筆記本,之前有買過一本筆記本,不過我覺得有點太大本了,不太好使用,因為主要是紀錄一些隨手的東西,太大本的筆記本不好攜帶!

這本筆記本是故意仿文庫本的樣式設計,所以尺寸為 A6 大小,紙張是用再生紙,表面光滑還滿好書寫的,不過我發現封面的部份有點脆弱,容易受到污漬的影響,用久可能會像之前那本一樣,破舊不堪,所以可能要找找有沒有書套可以使用保護一下筆記本。


通常筆記本我都不會從第一頁開始紀錄,我都會亂翻到某一頁就紀錄,不知道為什麼,感覺第一頁就會被別人發現紀錄的規則,所以才會有這樣隨機找頁面紀錄的習慣。至於說日後會不會很難找到想要找的頁面,目前是覺得沒有太大的影響。

MUJI 也有出單行本版本的筆記本,拿起來份量很夠,感覺可以把筆記本偽裝起來當一本小說。

2012年1月29日 星期日

父與子的300日戰爭 宮崎駿X宮崎吾朗

在 Facebook 看到一則不錯的分享,是日前 NHK 採訪紀錄宮崎駿與其子宮崎吾朗在製作《來自紅花坂》的互動過程,可以花點時間來看看宮崎駿的創作理念和宮崎吾朗對於動畫的堅持。
由NHK拍攝幕後製作特輯,紀錄了活在巨人父親宮崎駿影子下,兒子宮崎吾朗如何戰戰兢兢完成《紅花坂上的海》,比電影更好看,不容錯過!

NHK 『父與子的300日戰爭 宮崎駿X宮崎吾朗』 繁中字幕 (1)
http://www.youtube.com/watch?v=hPt7zxPG9g0

NHK 『父與子的300日戰爭 宮崎駿X宮崎吾朗』 繁中字幕 (2)
http://www.youtube.com/watch?v=sqbosenKYsA

NHK 『父與子的300日戰爭 宮崎駿X宮崎吾朗』 繁中字幕 (3)
http://www.youtube.com/watch?v=95ZCnOe9umA

NHK 『父與子的300日戰爭 宮崎駿X宮崎吾朗』 繁中字幕 (4)
http://www.youtube.com/watch?v=qcJ4imcHbFc

NHK 『父與子的300日戰爭 宮崎駿X宮崎吾朗』 繁中字幕 (5)
http://www.youtube.com/watch?v=k2iHojnAqq4

2012年1月24日 星期二

過年還在營業的店家,不要賠上過年後的生意


一個小小的攤位,兩個爐,就可以做一個炒飯的生意。不知道是新開的,還是之前沒有注意到店家!很特別!

過年期間還有在營業的店家不多,可是會發現一個很特別的現象,就是會發現平常沒有注意到的店家。在平時,每家店都有開的時候,很少會一一注意有那些新開的店家,或是平時就習慣到某些店家消費之後,就很少去注意到周圍其他類似的店家。所以現在過年期間,很多店家都休息過年,但人總是嘴饞,會在路上一直找吃的!所以這些沒有休息的店家,剛好就在這時候被發現。

不過這時候營業會遇到兩種狀況,因為周圍店家沒有營業,所以生意一定會比平常好,人潮也會比較多,這時候就要注意人手、材料是否充足,要不然有可能會變成悲劇,餐點出不來或是什麼東西都賣完了!另外還有一個備受考驗的,就是東西好不好吃的問題,東西如果好吃,過年後一定會有新的顧客再回來光顧,但如果東西不好吃,過年後一定會變得更悽慘!

所以過年營業的店家,可以間接刷新顧客對既有的店家印象,但相對的還是要小心應付、備足食材才能在過年賺錢,而不會賠上過年後的生意!

2012年1月22日 星期日

不要對我說想太多,我會害羞!


不要對我說想太多,我會害羞!

因為我叫 Toomore,中文翻譯是「太多」,所以不要對著我說「想太多」,我真的會會錯意!尤其對方是女生,我更會會錯意!

還有如果有一天,妳很幸運的 Callin 到電台點歌,也記得不要點這首,要不然我又會以為:妳在想我!真害羞!


以上,都是我想太多了 ......

賀年卡寄了沒!偷聊一下後端!



來寄賀年卡片吧!今年 MozTW電腦君畫了一張可愛的賀年卡,可以經由這個線上電子卡片系統,寄給親友、情人、朋友們,所以趕快來寄卡片吧!把想要說的話、想要感謝的人都說個明明白白吧!

前端的部份由 Irvin 設計,不過還是來談一下後端吧!因為這次後端由小弟我負責,是用 Google AppEngine(GAE) 來控制郵件發送,主要的流程是前端郵件資料(form data)→reCAPTCHA 驗證碼,確認是否為人類→驗證寄件人、收件人郵件地址是否有效→放入 Task 等待發送→Mail API 發送郵件。

因為 GAE 免費郵件容量一天 100 封,怕超出使用量,所以用 Task 去控制一天的總發送量,但好心的 Irvin 也刷了預算下去,因此就算超出容量也沒關係!

取消一人只能寄一張的限制,想說大家的親朋好友很多,只寄一張太可惜了!小莎又這麼可愛,怎不叫大家趕快亂寄勒!所以大家就快來寄賀年卡吧!恭喜大家新年快樂阿!

至於原始碼勒!哈,等我整理一下再另行公佈!

2012年1月20日 星期五

當兵時用的筆記本


當兵時候用的筆記本,現在已經變成這個樣子了,扭曲、破破舊舊、封面頁與內頁分離,放在口袋,被汗水、不知名的髒水浸溼,所以才變成最後這個樣子!

大概是新訓之後,二階段銜訓開始紀錄的,那時候在筆記本後面幾頁畫上退伍倒數日,每天畫一個圈圈數日子,或是有什麼可以紀念的日子,就會把它標記起來。數到最後也就這樣數到退伍!


有電腦之後,感覺什麼事情都習慣直接打在電腦裡很方便,但有些時候動筆寫出來的東西就是會有不一樣的結果,我總覺得透過書寫方式寫出來的內容會比較縝密一點,但也有可能會因人而異!

但無論如何,在軍中養成隨身攜帶一本自己專用的筆記本紀錄事情,退伍之後應該也要繼續保持這樣的習慣!只不過現在要換一本新的筆記本就是了!至於這本筆記本,就功成身退啦,我會把它好好的收藏保存起來,等到我老的時候可以拿出來回味!

2012年1月15日 星期日

拿到退伍令,一切才是真的!


真的啦,雖然是薄薄的一張,但,誰不愛拿阿!我也拿到了,順利退伍啦!

話說走回營部的路還真有點遠,讓我一路上一直有當兵的走馬燈跑過去!該不會是前輩長官們用心設計的,讓退伍人員走最後一段路,好好回憶為國家貢獻什麼吧!不過我拿到退伍令之後,按捺不住興奮的心情,一路跑下山,跑到哨口出去。

起跑時還有學長提醒我:記得,不要回頭!

好啦!退伍了!就這樣!

貓咪吃巧克力自殺之類的


有一些話找不到出口可以訴說,有一些人是該忘記不再掛念的,有一些事情或許就是這樣的結果,也不能改變什麼!

本來這故事只有一篇而已,只是單純的想表達我的想法,可是似乎在那短短的70字說也說不完,才有接下來的幾篇出現。本來只有寫到第3篇,但聽到沮喪又失望的聲音後,改寫一下,把結局帶到新的地方,所以一共寫了7篇70字的創作。

也就是7篇的簡訊內容!

回頭看看這7篇內容,有男孩、女孩、我和一隻貓,每個人背後都還有很多發展故事的可能,或許應該就把這7篇再寫長一點吧!至於故事的內容要如何發展,其實我也沒什麼打算,或許就讓他們自由的發揮,免得我還有乙一的餘毒,讓故事轉變成恐怖的推理小說!

故事中死幾個人好像也不錯,或是貓咪吃巧克力自殺之類的,或是一開始他們就 ......

走吧!帶著微笑走台灣!


花一年的時間應該可以走完吧!我想要來挑戰走完台灣 319 個鄉鎮,只是目前還不錯確定要如何走。

有人向我推薦蔣勳這篇《人需要出走》,鼓勵大家要身體力行走出去看看外面的世界!不過我沒有太多的預算出國,所以還是先從生活的這塊土地開始認識吧!

趁退伍之後體能狀況還算良好的階段,來下鄉走走吧!