跳到主要內容

發表文章

目前顯示的是 2012的文章

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 也到手了,推薦觀賞 此短片 。或是訂閱 我的頻道 。

11 月份飛逝…

這個月過的很快,到最後一天都還不敢相信。 影像紀錄區 月初發佈 尋找攝影師 功能後,持續開發 攝影活動 的功能,本來預計要以一個禮拜一新功能的快速推進方式,但實在是遇到我這龜毛的個性,到今天才順利上線。接下來 12 月份影像紀錄區要規劃 Model 的區塊,模式與攝影履歷類似,補齊攝影的一些元素。 另外這禮拜也與幾位前輩分享 影像紀錄區 ,不過普遍得到的問題都類似,如果輕鬆面對,老實來說 影像紀錄區 可能就只是單純的圖像分享網站,想到就上傳圖片。但如果要認真當一回事,目前還有很大的努力空間。不過老實說,影像紀錄區算是我第一個很認真去思考他的未來… 11 月真的過的很快,好像沒唸到什麼新東西,只記得有調整一下 nginx Gzip 的設定,也在 影像紀錄區 的 response header 放一個彩蛋,也準備轉移 DNS 到 Amazon Route53 ,其他的好像也沒有什麼… 對了,還有一件事 11/29 我家的 咪咪 突然死掉了…

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

嚴格來說 影像紀錄區 目前都還沒有在 台灣 主要的 conf. 曝光過, 通常我都會 報名 閃電秀 來趁機宣傳一下我的作品,但今年除了 OSDC 外, PyConTW 是抱著 學習 的心態去參加、 COSCUP 是因為當工作人員所以沒時間準備內容,直到 10/27 在高雄舉辦的 MOPCON 我才在閃電秀上面分享 影像紀錄區 。 覺得閃電秀才是我的舞台,太長的分享時間有點不是我的 style。雖然 MOPCON 我也是有當工作人員,但偷偷看著閃電秀那張填寫報名海報,手又好癢、好心動,所以最後還是報了,大概花一小時完成五分鐘的簡報。 閃電秀簡報的流程之前就有在腦子裡排過,因為這幾個月來一直在分享影像紀錄區 技術 的部份,講到我都累了,聽的人應該也膩了,所以應該換個方式來宣傳 影像紀錄區 ,那當然就是帶大家看圖,然後聽我說故事… 簡報中的作品都可以在影像紀錄區 我的個人頁 找到,以下就是閃電秀的簡報: MOPCON Lightning Talk 閃電秀 用照片說故事 - 影像紀錄區 from Toomore

KSDG Python and MongoDB for web

這是 10/4 在 KSDG 分享的主題, 內容主要是分享 影像紀錄區 如何利用 Python 與 MongoDB 。簡報分兩部份:上半部談技術,下半部談網站未來的經營(56 頁開始)。線上簡報如果難以閱讀,也可以 下載 PDF 檔 。 KSDG Python and MongoDB for web from Toomore 原本預定在 8 月份分享,但遇到颱風,移到 10 月份分享。不過還好移到 10 月,要不然我覺得在 8 月份的時候可能沒有像現在有那麼多東西可以講。在簡報 56 頁開始是我比較想與大家分享的,是關於影像紀錄區《現況與未來》,有興趣的請看簡報,在這裡就不再重覆敘述!

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" 的類型。例如這個作品 #622 與 tweet 範例 : <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"> &l

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 的用法。

COSCUP2012 行政組 感想與心得

把今年參與 COSCUP 2012 活動紀錄起來。 最早 參與 COSCUP 是在 2008 年 ,那時候是幫忙 MozTW 擺攤位,不過事後想一想,應該是以 MozTW 幫 Mozilla 擺攤位,因為那時候是沒有社群攤位的。隔年 2009 年擔任紀錄組組員, 創下一人拍全場的紀錄 ,那時候還在台大,還增加為兩個議程軌,其實是錯估情勢才會創下這紀錄,而現在的紀錄組已經壯大到很專業了。2011 年去當兵,所以沒有參與到 COSCUP。 退伍後想說沒什麼事,找 2011 年行政組長 小菲 (她說還會再接一年),詢問 2012 年有沒有行政組員可以加入。只是沒想到 小菲 竟然說她臨時有事情,希望我接下組長的職位,她說她會協助我,所以在2月份的時候交接,我就接下組長的職位。 招募 行政組在 2011 年的編制是1組長 + 2組員,主要的工作任務是講者晚宴、慶功宴、工作人員住宿、交通費補助、總召秘書。2012 年新增了2個任務:人事登錄、網站上稿。編制的部份調整為1組長 + 1副組長 + 2組員。而 2011 年的組員 Anna 、 Bryan 分別出國唸書與轉戰會眾組的關係,2012 年的組員就必須重新招募,而我也與 小菲 決定以 公開方式 進行招募,令人驚訝的是還挺多人提出申請。 大約2月中就確定組員了,保留去年的精神,所以今年招募的組員也是一女一男,而申請人數的比例為 6:1(男:女)。不過接下來這裡我就要自我檢討一下,當初招募的時候只審大家的自我介紹,而 小菲 是希望可以用 skype 與他們聊過,這樣的評估方式會比較好,但我實在是太懶惰,我只就自我介紹與 Blog 文章來判斷。最後挑選了 Sammy 、 Maxine 。不過我是到了4月 OSDC 才見到他們本人,所以…… 工作人員登錄 在 6 月份之前,大部份都是處理其他組別工作人員登錄事宜,由行政組統一登錄或登出人員,但是不影響各組組長的人事決議權。為什麼要統一在行政組這裡處理,因為人員登入之後還要設定相關的 mailling list、Redmine。即使到最後場務的人員招募,還是要統一在行政組這裡填登錄表單,統一建檔紀錄。 說到場務組人員登錄,在這之前的人員登錄都是少量的,所以可以手動慢慢來處理,但場務組確定人數之後是會提交一份約 50 人的名單

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

前幾天在看 一篇文章 的時候發現一個網站和我做的 影像紀錄區 很像,甚至也有 更新紀錄 這一類的頁面。老實說當下看到是覺得好像有滿多的東西很相似, 有的人 認為他們抄襲,點右鍵看一下原始碼也發現用到的套件幾乎影像紀錄區也有用到。但如開頭提到的文章一樣,作品本來就抄來抄去,或許 我們剛好都找到相同類似較佳的呈現方式 。 但以上都不是我想要知道的,本來今年是要報名 AppWorks ,但因為某些原因不報了,而在決定不報的同時剛好 開始製作 影像紀錄區。直到前幾天才發現原來有和影像紀錄區類似的作品正在 AppWorks 孵育,所以我比較好奇他們的營運模式,我想要知道他們如何導出獲利模式!雖然他們是畫作(也很好奇為什麼是畫作) + 攝影,而我們比較偏向專注在 攝影 的部份,但一樣都是想要迎造出一個 同興趣 的社群平台。 當然也不可否認我的靈感絕對不是原創的,我是參考 wookmark 的樣板與 instagram 後端架構而誕生的,詳細的介紹可以參考「 影像紀錄區 紀錄一下這段時間發生的一些事情與未來的方向 」。 或許像是現實生活中的 撞衫 吧!最後我想我們應該也要來 Pivots 一下 ;)

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

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

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 要不要來建一個各股歷史資料庫,把證交所的資料倒進來,好像也可以齁!

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

大約在4月底的時候與學長聊天,聊到以前攝影社的影像紀錄區,可以讓社員上傳作品的平台,那時候我們就是以這項強大的網站服務來吸收社員,所以只要入社就有帳號可以使用。 距離事件發生也過了3年了,2009 年 莫拉克颱風 的關係,把原本架在財金系的攝影社網站給摧毀掉了,之後也找不到合適的 主機 架站,就這樣一直延盪到最近。 前陣子作完 grs 的網站後,發現一些東西在做網站的時候可以迅速建立,所以就乾脆以現在比較拿手的 Python 來重寫一個 影像紀錄區 。大約花了一個禮拜的時間,網站就上線了!基本的架構用到:Python + Flask + uWSGI + nginx + MongoDB,另外社員上傳後的圖片是丟到 amazon S3 服務,現在大家都愛談雲端,那就來實作這部份,圖片都丟到雲上面去! 另外就是 MongoDB 的部份,之前 grs 都沒有使用到資料庫,而我又不是很想用 MySQL ,所以就決定來實作 NoSQL 資料庫的應用,於是就選擇 MongoDB 當作底層的資料庫系統。雖然剛開始用的時候還是會有之前用 MySQL 影響在,但後來使用 MongoDB 就會發現 NoSQL 資料庫的優點,很適合這小小的網站來使用。 這幾天也加入 Facebook、twitter 的連結,當社員發佈作品的時候,也會同步到這兩個社群服務,希望這樣可以增加曝光率,讓更多人來看我們分享的作品。現在網站是上線了,但有些功能還沒有寫完,只能慢慢調整、慢慢補,反正功能寫的差不多就上線,看大家使用的怎樣在調整修改,這樣比較好,要不然會有盲點。 不過我在思考一件事情,之後要開放給大家使用嗎?或許可以變成一個攝影同好交流的平台也不錯!

用 Nexmo 發送簡訊,台灣 USD 0.013

老實說 Nexmo 價格真的便宜傳到台灣只要 USD $0.0145(* 29.662 = TWD $0.43),而且又提供 RESTful 的 API 使用,台灣的部份 支援 :中華電信、遠傳電信、威寶電信、台灣大哥大(疑,亞太電信勒!) 不過 sender 的地方因為可以自行設定,有些電信商會當作 spam 過慮掉,官網 是說 用完整的 國際電話格式 避開,但好像還是有些問題。不過還不錯用,比 PChome 的 一元簡訊 便宜。 附上簡單的 Python 發送程式:

OSDC.tw 2012 閃電秀:又一個誤聽 GAE 的悲劇

在 OSDC.tw 2012 閃電秀發表的簡報。 又一個誤聽 GAE 的悲劇 View more presentations from Toomore

搬出 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 就死掉一

這幾天看到的文章 Python Git YouTube

這幾天看到幾篇還不錯的文章,在這裡做個筆記。 How to create and apply a patch with Git - Ariejan.net 如標題,如何做一個、接受一個 patch,用到 git-format-patch、git-apply、git-am。其實  git-format-patch 有 -o 的參數,後面接要輸出的資料夾就可以把 patch 產生到指定的資料夾。 GitHub Flow - Scott Chacon on the Interwebs 這一篇酷了!主要是討論前陣子很流行的 git-flow ,一個專案開發流程。這篇作者在 github 工作,也到處講授 git,常常遇到有人問他關於 git-flow 的看法,不過作者點出一些 git-flow 的問題,然後很好奇 github 內部的 work flow 是如何?也做了一番的介紹,提出了五大點。有興趣的可以閱讀!(中文整理文章: 練習是不會騙人的 • 在 GitHub 當中使用的 work flow ) PanSci 泛科學 | Blog | 該走或該留?逐漸消失的依賴感 這篇看標題就知道了,和感情有關的,只是用很科學的方式來解釋這感性的問題,文章有點長,但建議花點時間看完。另外作者有提醒: [12]本文為書寫方便故,大多以男性觀點寫成;但是過去研究顯示男女在戀愛或關係維持的變項上相似處比相異處還多(APA, 2005),故暫且可feel free置換描述觀點為女性,結果大致相仿。 至於我看完的心得,當然想通了很多事情,對最近發生的事情也比較能夠釋懷,畢竟我相信科學的解釋! PyCon 2011: How Dropbox Did It and How Python Helped 這是去年 Dropbox 在 PyCon 上簡報 Python 如何解決一些問題,Dropbox 應該算是目前最受歡迎的檔案同步軟體,尤其像在好幾台電腦上工作的人,或是小團隊要取得最新的專案文件時,Dropbox 真是好用又無負擔的小工具。跨平台的部份都是用 Python 去完成,當然講者也提到除了 Android、iPhone 不是用 Python ,因為記憶體與效能的問題。 最後 那我懂你意思了 - 所以我停下來

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

不知道有多少個夜晚是麥片配電腦,自從家裡多了一台熱水壺之後,吃泡麵、喝麥片就變得很方便(疑,還有押韻!) 在夜裡做事情有個好處,就是什麼都很安靜,可以專心在事情上,但是就是太安靜了,有時也會陷入恐懼寂寞、回憶過去的黑洞裡!這時候就要趕快把自己再從黑洞裡拉出來,再把思緒回到事情上。 但是黑夜到底害怕什麼,人類演化過程是因為害怕寂寞,所以才會在黑夜睡覺嗎?還是因為麥片不好吃,索性就去睡覺了 ......

一起等地球爆炸吧

這首歌好好聽,一開始不確定歌詞內容,唱了一遍之後才發現好像在哪裡聽過,想起來了!在《 他們在畢業的前一天爆炸 》第二集裡,阿丁做一首歌要送給浩遠當生日禮物, 唱的就是 這首俏皮的歌。所以有此可證,通常都是拿自己最擅長的技能,親手為喜歡的人做禮物! 我知道 棉花糖 負責《爆炸》的 音樂 ,但一直都沒聽過這首歌完整的呈現,但在 2011 年年底棉花糖就發了這首歌的 EP 。 一起等地球爆炸吧 詞:莊鵑瑛 曲:沈聖哲 握你的手‭ ‬那天的風好溫柔‭ ‬想這樣一直走 多吃蔬菜多做運動 讓自己活得更久 我會努力 完成自己的生活‭ ‬不再任性揮霍 計劃著我們的世界環遊 告別孤單的稀薄 等晴天 等雨天 等不及和你見面 等每一個大冒險 登不上 太空船 那就等地球爆炸 死在同一個地方 反正你就在身旁

文庫本筆記本

買了一本 MUJI 文庫本的筆記本 ,之前有買過 一本筆記本 ,不過我覺得有點太大本了,不太好使用,因為主要是紀錄一些隨手的東西,太大本的筆記本不好攜帶! 這本筆記本是故意仿 文庫本 的樣式設計,所以尺寸為 A6 大小,紙張是用再生紙,表面光滑還滿好書寫的,不過我發現封面的部份有點脆弱,容易受到污漬的影響,用久可能會像 之前那本 一樣,破舊不堪,所以可能要找找有沒有書套可以使用保護一下筆記本。 通常筆記本我都不會從第一頁開始紀錄,我都會亂翻到某一頁就紀錄,不知道為什麼,感覺第一頁就會被別人發現紀錄的規則,所以才會有這樣隨機找頁面紀錄的習慣。至於說日後會不會很難找到想要找的頁面,目前是覺得沒有太大的影響。 MUJI 也有出 單行本版本的筆記本 ,拿起來份量很夠,感覺可以把筆記本偽裝起來當一本小說。

父與子的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

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

一個小小的攤位,兩個爐,就可以做一個炒飯的生意。不知道是新開的,還是之前沒有注意到店家!很特別! 過年期間還有在營業的店家不多,可是會發現一個很特別的現象,就是會發現平常沒有注意到的店家。在平時,每家店都有開的時候,很少會一一注意有那些新開的店家,或是平時就習慣到某些店家消費之後,就很少去注意到周圍其他類似的店家。所以現在過年期間,很多店家都休息過年, 但人總是嘴饞 ,會在路上一直找吃的!所以這些 沒有休息的店家 ,剛好就在這時候被發現。 不過這時候營業會遇到兩種狀況,因為周圍店家沒有營業,所以生意一定會 比平常好 ,人潮也會比較多,這時候就要注意人手、材料是否充足,要不然有可能會變成 悲劇 ,餐點出不來或是什麼東西都賣完了!另外還有一個備受考驗的,就是東西好不好吃的問題,東西如果好吃, 過年後 一定會有新的顧客再回來光顧,但如果東西不好吃,過年後一定會變得更悽慘! 所以過年營業的店家,可以間接刷新顧客對既有的店家印象,但相對的還是要小心應付、備足食材才能在過年賺錢,而不會賠上過年後的生意!

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

不要對我說想太多,我會害羞! 因為我叫 Toomore ,中文翻譯是「 太多 」,所以不要對著我說「 想太多 」,我真的會會錯意! 尤其對方是女生,我更會會錯意! 還有如果有一天,妳很幸運的 Callin 到電台點歌,也記得不要點這首,要不然我又會以為:妳在想我!真害羞! 以上,都是我想太多了 ......

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

來寄賀年卡片吧!今年 MozTW 請 電腦君 畫了一張可愛的賀年卡,可以經由這個 線上電子卡片系統 ,寄給親友、情人、朋友們,所以趕快來寄卡片吧!把想要說的話、想要感謝的人都說個明明白白吧! 前端的部份由 Irvin 設計,不過還是來談一下後端吧!因為這次後端由小弟我負責,是用 Google AppEngine(GAE) 來控制郵件發送,主要的流程是前端郵件資料(form data)→ reCAPTCHA 驗證碼,確認是否為人類→驗證寄件人、收件人郵件地址 是否有效 →放入 Task 等待發送→ Mail API 發送 郵件。 因為 GAE 免費郵件 容量 一天 100 封,怕超出使用量,所以用 Task 去控制一天的總發送量,但好心的 Irvin 也刷了 預算 下去,因此就算超出容量也沒關係! 取消一人只能寄一張的限制,想說大家的親朋好友很多,只寄一張太可惜了! 小莎 又這麼可愛,怎不叫大家 趕快亂 寄勒!所以大家就快來寄賀年卡吧!恭喜大家新年快樂阿! 至於原始碼勒!哈,等我整理一下再另行公佈!

當兵時用的筆記本

當兵時候用的筆記本,現在已經變成這個樣子了,扭曲、破破舊舊、封面頁與內頁分離,放在口袋,被汗水、不知名的髒水浸溼,所以才變成最後這個樣子! 大概是新訓之後,二階段銜訓開始紀錄的,那時候在 筆記本後面幾頁 畫上退伍倒數日,每天畫一個圈圈數日子,或是有什麼可以紀念的日子,就會把它標記起來。數到最後也就這樣數到退伍! 有電腦之後,感覺什麼事情都習慣直接打在電腦裡很方便,但有些時候動筆寫出來的東西就是會有不一樣的結果,我總覺得透過書寫方式寫出來的內容會比較縝密一點,但也有可能會因人而異! 但無論如何,在軍中養成隨身攜帶一本自己專用的筆記本紀錄事情,退伍之後應該也要繼續保持這樣的習慣!只不過現在要換一本新的筆記本就是了!至於這本筆記本,就功成身退啦,我會把它好好的收藏保存起來,等到我老的時候可以拿出來回味!

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

真的啦,雖然是薄薄的一張,但,誰不愛拿阿!我也拿到了,順利退伍啦! 話說走回營部的路還真有點遠,讓我一路上一直有當兵的走馬燈跑過去!該不會是前輩長官們用心設計的,讓退伍人員走最後一段路,好好回憶為國家貢獻什麼吧!不過我拿到退伍令之後,按捺不住興奮的心情,一路跑下山,跑到哨口出去。 起跑時還有學長提醒我: 記得,不要回頭! 好啦!退伍了!就這樣!

貓咪吃巧克力自殺之類的

有一些話找不到出口可以訴說,有一些人是該忘記不再掛念的,有一些事情或許就是這樣的結果,也不能改變什麼! 本來這故事只有一篇而已,只是單純的想表達我的想法,可是似乎在那短短的70字說也說不完,才有接下來的幾篇出現。本來只有寫到第3篇,但聽到沮喪又失望的聲音後,改寫一下,把結局帶到新的地方,所以一共寫了7篇70字的創作。 也就是7篇的 簡訊 內容! 回頭看看這7篇內容,有男孩、女孩、我和一隻貓,每個人背後都還有很多發展故事的可能,或許應該就把這7篇再寫長一點吧!至於故事的內容要如何發展,其實我也沒什麼打算,或許就讓他們自由的發揮,免得我還有 乙一 的餘毒,讓故事轉變成恐怖的推理小說! 故事中死幾個人好像也不錯,或是 貓咪吃巧克力 自殺之類的,或是一開始他們就 ......

走吧!帶著微笑走台灣!

花一年的時間應該可以走完吧!我想要來挑戰走完 台灣 319 個鄉鎮 ,只是目前還不錯確定要如何走。 有人 向我推薦蔣勳這篇《 人需要出走 》,鼓勵大家要身體力行走出去看看外面的世界!不過我沒有太多的預算出國,所以還是先從生活的這塊土地開始認識吧! 趁退伍之後體能狀況還算良好的階段,來下鄉走走吧!

show