其實用 vim 好久了, 可是從沒認真去研究一些外掛, 一直到去年年中看到 othree 寫了 Vundle, Bundler for Vim 這篇介紹了 vundle, 便稍微研究了一下, 不然每次換系統就要重新把外掛裝回來, 雖然說我外掛也都只有 pyflakes.vim 而已。
vundle 的好處就是, 你只需要維護好你的 .vimrc, 之後到哪都可以透過這份 .vimrc 用一個指令把所有外掛裝好, 所以把 .vimrc 丟上 gist 應該是個不錯的作法。
其實用 vim 好久了, 可是從沒認真去研究一些外掛, 一直到去年年中看到 othree 寫了 Vundle, Bundler for Vim 這篇介紹了 vundle, 便稍微研究了一下, 不然每次換系統就要重新把外掛裝回來, 雖然說我外掛也都只有 pyflakes.vim 而已。
vundle 的好處就是, 你只需要維護好你的 .vimrc, 之後到哪都可以透過這份 .vimrc 用一個指令把所有外掛裝好, 所以把 .vimrc 丟上 gist 應該是個不錯的作法。
因為先前 Open Foundry 電子報, 關於 Heroku 部屬的相關文章獨缺 Python,所以便找了我寫這部份, 想說順便借這次機會催促自己玩一下 Heroku,所以就生出了這篇 Python/Django on Heroku。
不過前一陣子又玩了很多 Heroku 上的東西,之後再寫篇文章來補充一下好了,下面就直接把文章直接放上來,存個備份,話說當然有修 typo :p
自從 Heroku 出現之後,挺羨慕 Rails 的開發者有這麼酷的服務可以使用。不過就在不久前 Heroku 也開始支援 Python 了,所以便趁著空閒玩了一下。基本上只要熟悉平常使用的 Python 相關工具,像是 virtualenv、pip 以及 git 的話,整個部屬流程可以說是非常簡單。
接下來,我會說明如何透過簡單的幾個步驟,把 Django 部屬到 Heroku,手腳快的話在十分鐘之內便可以看到網站在 Heroku 上跑起來了。

12 月初身體狀況不太好, 除了感冒之外, 幾處牙齦處於輪翻爆炸的狀態, 整個身體的狀況糟糕透頂, 簡直就是惡夢。
當時應該是為了改變心情, 所以就在 12/12 星期一, 跑去 sogo 的 nokia 專櫃買了 lumia 800 這支手機。 因為當時覺得這隻手機的外型很不錯, 沒想到這是惡夢的延續。
這是我第一次買 Nokia 的產品。
昨天把 MyAudioCast 搬出了 App Engine, 花了一些時間改寫程式跟 migrate 資料, 最後搬到了 Linode 上。 而原本在 App Engine 上用的是 Django 1.1, 順便也把 Django 升到 1.3。
在這次搬家的過程花最多時間的就是在處理資料的轉換了, 而最初我以為要把資料從 App Engine 倒出來非常麻煩, 不過後來找到倒出資料的文件, 就照著文件說明把資料倒出成 csv, 然後寫了幾支 Django command 讀取 csv 寫進資料庫。
首先第一步就是建立 mapping 的 config 檔, 只需要下面這個指令就可以產生 datastore mapping 的 yaml。
前天由於某單位的網站被判定為惡意網站, 被植入了惡意的程式碼。 這個網站其實不是放在我們自家的伺服器上, 當時的技術主管是決定放在 Lunar Pages。 禮拜三中午一到公司, 就接到電話打來說他們網站出現問題, 被當成惡意網站怎麼辦, 哈 (苦笑)
由於完全沒碰過這個網站, 當初程式也是外包, 現在只好硬著頭皮解決, 不過當天有 4 個會要開, 就先請原本負責的同事處理, 不過完全沒找出問題就是, 同事還直接上 google 網站管理員說回報說誤判了 XD
我只好趁開會之間的空檔開始找, 一開始先用 firebug 看, 看到多出了一個異常的 request, 馬上跟同事要了 FTP 帳號想說用 grep 去找一下, 可是從 php 裡面根本找不到任何跡象, 不過後來翻到一支 javascript 會直接被導走, 還有幾隻 javascript 看起來怪怪的, 這當初是外包出去的, 我也不知道他們會不會從國外幹奇怪的 javascript 回來用。
今天, 在一個月內看完了海賊王 1 ~ 520 集, 真是值得紀念的一刻。
使用 App Engine 的 MyAudioCast 已經一年多了, 雖然說前一陣子 App Engine 已經離開 preview beta 成為正式的服務了, 所以價格跟著提高, 雖然說有贈送 $50 可以用, 不過老實說我還真的沒有去研究價格到底是變成怎樣。
不過這一陣子 MyAudioCast 爆量, 開始被收錢, 而且還不算少, 突然間才覺得真的是爆貴的!
就從 MyAudioCast 的例子來說好了, 由於大部分的 requests 都是 iTunes 來下載檔案, 以 MyAudioCast 的作法, 是透過程式記錄存取次數, 然後再轉址到真正的檔案, 所以做的事情基本上就只是計數器而已。 (當然這個 counter 有做 sharding 並且有用 memcache 處理)
可是從下面這個 App Engine 提供的 Resource Usage 圖表看來, 一天跑下來 CPU Time 都已經快吃光了, 而 CPU Time 的 Budget 還是給了 $4/每天! (是美金阿!)
實際看一下 reqs/sec 的圖表, 最高也還不到 50 reqs/sec, 可是這樣下來, 每天給 5 塊的 bugdget 才不會 over quota, 所以每週會花上 35 塊美金, 這樣一個月下來需要花上 140 塊美金, 可是同樣 StickerAction 用的是 Linode 768, 做的事情 loading 比 MyAudioCast 重得多, 可是一個月也才 29.95 塊美金而已。
這樣的價格真的沒辦法接受, 難道這就是 scalable 的代價? 或是說新的價格根本不適合跑小網站? 總之, 得準備一下來搬離 App Engine 了。
我真懷疑是不是我搞錯的 App Engine 的計價方式阿?
今天準備出門上班時突然下起了傾盆大雨, 索性就不去上班, 在家趕工作的 deadline 好了, 這樣一來也不會被打擾 (最近上班時 context switch 真的是非常嚴重), 畢竟目前手上的某個專案的規劃一直到昨天都還改, 昨天甚至整個邏輯都翻轉了。
然而後來又收到 Pixnet 來的訊息 ( Pixnet 提供 MyAudioCast CDN 贊助), 因為目前 MyAudioCast 的流量真的太高, 這禮拜每天都超過了 1TB, 所以希望我可以處理一下 XD
而流量會這麼高的原因主要是因為有幾個中國的 Podcast 算是滿熱門的(?), 三個小時就可以有近兩萬次的下載。 另外就是有 Podcast 上了 iTunes Store 的 Podcast 的 Top Chart (我是有點懷疑是因為這個原因啦), 所以一天也是幾萬次的下載。
其實先前就被警告過了 XD 所以已經有研究了一些解決辦法, 只是因為最近工作太忙, 沒有時間處理。 而今天剛好沒去上班, 就先投入 MyAudioCast 的救援工作, 至於工作 deadline 的處理就只好留待週末兩天加班趕工了。

上面這個流量圖, 算是拯救的成果, 不過目前 queue 還在繼續跑, 所以流量還會持續降, 接下來就持續觀察吧! 其實還真該想個 business model, 可是沒什麼 page view, 連放廣告都嫌浪費力氣 XD
今天 iOS5 釋出了, 我這支用了兩年的 iPhone 3Gs 也還可以升級, 真是不錯。 升級後速度沒什麼差, 跟原本一樣慢, 哈!
不過我想除了 iCloud 之外, 其他沒什麼太大差異, 終於又可以像之前用 MobileMe 一樣同步資料了, 只是不用花錢就是了, 得趕快來把行事曆改用 iCloud 同步, 不然同步 Google Calendar 其實挺困擾的。
iPhone 4s 趕快來吧!
上個禮拜就開始在玩 octopress, 雖然一樣用 markdown 寫文, meta 也一樣是用 yaml, 不過比 blogofile 貼心太多了。
所以昨天就花了一些時間, 寫程式把 blogofile 的檔案轉成 octopress 的格式, 主要就 octopress 檔案名稱格式有固定, 至於文章內的 yaml 其實差不多, 多加上個 layout: post, comments: true 參數, 以及轉換 categories 就完成了。
相對於 blogofile, octopress 主要方便的地方是 deploy 這件事, 先前 blogofile 是 deploy 到 s3, 還是自己寫程式丟上去, 而 octopress 直接就提供了一個 rake command 就直接輸入設定, 之後直接打 rake deploy 就可以丟上 github 了。
不過, 我覺得一定有一些人一定換了這類的 blog 系統之後, 就減少了發文的動力, 像我就是 XD