2012年12月5日 星期三

心得:Taipei.py 2012 11 月聚會

這是我第一次到 創立方 參加活動
交通指南講得很清楚:「從東門站3號出口左轉直走到金華街,只要3分鐘即可到達政大公企中心」
結果我還是迷路了 …
真的!不要懷疑,3 號出口一走出來就直接左轉,往小巷子那邊一直走過去吧!
不要傻傻的先右轉走到大馬路再左轉 …

對於這次聚會地點的印象就是:
  • 雙投影幕耶!椅子弧形排列圍繞講者,效果似乎還不錯!
  • 可能天氣太冷、地點較遠 、沒有正妹店員、然後很多人跟我一樣傻傻的迷路 等等因素,出席的人數較少
  • 會議室空間較大,人數雖然也不少了,可是因為填不滿,所以看起來略為冷清

這次的演講由 Pinkoi 的創辦人/技術長 Mike 開場
演講內容提到了該平台現況(7k+ 的設計師)
以及使用的一些技術:
  • 圖片放在 amazon、有使用到 ec2
  • git 版本控管
  • Nginx + Gunicorn
  • Django -> 僅使用到 url routing 功能
  • Memcache
  • CouchDB
  • RabbitMQ (用來協助處理低優先權的工作,如:與ibon溝通、寄送 email)
  • 自行開發匯款給設計師、列印發票的自動化架構

我認同 Mike 大大提出來的的三個觀點:
  • User first
  • Tech. (用技術解決人力問題)
  • Done is better than perfect
受限於時間,我認為 Mike 大大的演講屬於點到為止
有些細節還是不太清楚,可惜演講後結束我又到處閒聊
沒有辦法請教一些問題 Orz



第二場演講是由 marr 大大向大家介紹 Plone
我有找到大大分享的投影片:
(所以可以不用節錄重點了 XDDD)
Plone 提供的 solution 很乾脆,也很專業
感謝 marr 大大開拓了我的視野 Orz







微。演講是由正。妹 mosky 分享她撰寫的新工具: enhancedyaml
其實我對 YAML 並不熟悉,記得都是在套件的 config 檔案會見到這種格式
有空再來研究研究!
畢竟我都用 markdown 在寫部落格了 … 認真理解一下 YAML 應該不為過 …



本月的聚會結束得較早一點點,或許是沒有用餐的關係?
不過我還是努力的湊熱鬧、當跟屁蟲、聽八卦

回家的路上緊跟著一群大大們回家
受到精神感招後,看來我該去報名 pyconf 2013 的志工了!

補充:
1. marr 大大有針對 Plone 的 scalibility 在 python.tw簡要的說明
2. Pinkoi 其實辦公室就在創立方內!(而且正在徵人)
3. 其實這次 Taipei.py 跟團隊的行程是衝到的 … 我當然是選擇參加 python 了!(握拳!)
(狀態顯示為一個月沒寫 python)
4. 我如果再一直寫不出文章,這裡就要變成 Taipei.py 心得文部落格了 Orz
(上一篇還被 keith 大大抓包~)
        5. 原來這裡有 Taipei.py 的 聚會歷史 可以直接找到講者的投影片跟資料
        (糟糕,下次不能用講者的投影片充心得文的版面了 Orz)

2012年11月8日 星期四

心得:AppWorks Demo Day #5

圖片來自 AppWorks,可以點此觀看 出場團隊簡介



前天我參與了 AppWorks 第五屆的 Demo Day,老實講,我很感動很佩服
我先在簡單此整理我所找到的資源:



加入一間新創公司 剛好滿一年左右
我參與過了三次的 AppWork Demo Day,心境卻有著非常大的差異:
  • 第一次,可以說是創業前期,抱持的想法是要來找有趣的東西,思考尖銳,自以為看得很清楚
  • 第二次,自身牽涉其中,嚴格來講,DEMO Day 前就是一直寫程式跟 DEBUG,這件事情一直做到當天清晨
  • 第三次,我好像看得懂比較多東西了,我知道他們的努力,他們面臨的情況,另外一方面也能夠明顯看出他們哪裡做不好或是做得很好

我想要從另一個觀點來聊聊 DEMO Day,他能帶來的效應有:
  • 「推」團隊趕快想出、做出東西
  • 訓練團隊表達、行銷能力
  • 提供團隊與其他人(創業者、專業使用者、創投、)社交、互動、甚至媒合的機會
  • 整場 DEMO Day 就是一個大型的行銷活動,宣傳團隊跟 AppWorks 本身
    老實講,是否能藉由單一活動博得很多主流媒體的版面,我認為這不是那麼重要
    好的東西,透過日積月累的動腦筋行銷,自然而然就能夠推廣出去,時間早晚的問題罷了!

就我的觀點,「創意」這一件事情並不是觀看 Demo Day 最需要考量的地方
創業不是僅只是創意競賽,他其實最大的成分叫做執行力競賽
我甚至認為 Demo Day 上面呈現的「產品」本身也可以不是最大的重點
台上的講者所呈現出來的熱情、團隊的向心力跟合作能力才是最重要的
如同 Jamie 所提,需要 5-10 年網路公司才會逐漸成熟
對 Demo Day 的團隊們不宜太苛刻

這次的 Demo Day 中,各團隊的的商業模式較為穩固,甚至有很多人已經算是創業的小鳥或是老鳥了
就 presentation 這一件事情,我個人認為:
  • 1/4 表現方式不佳或是根本內容上就不恰當,很可惜
  • 1/2 能夠講出自己想要表達的東西,不過表達方式如果想要說服我,仍然小有進步空間
  • 1/4 表現佳!
抱歉,其實我自己很也毒蛇、苛刻啦…
但是就是曾經參與其中,我才會知道「把產品做好」以及「上台講清楚」這兩件事情其實並不容易做好
舉例來講,我的團隊講的其實也是屬於還不行的那一群(上台的版本算是可以了,練習的時候,我聽得想切腹)
(可以參考這篇文章:心得:PIPOSEA @ Appworks Demo Day #4)

取其優點學習,注意其缺失叮嚀自己
隨時問自己「如果是我的話,我會怎麼做這一個產品?我會怎麼 present 我的東西?」
這是我希望自己能夠做到的
新創團隊需要鼓勵,可以批評,因為這也是讓大家成長的好方法
如果只是無建設性的謾罵,就可以省下來了


備註:
最近團隊在進行腦力激盪思考下一個 Project
提 idea 時,總是會有讓大家大笑,覺得很蝦的東西
但是靜下心來仔細想想,卻又往往有其可行性
如果只是一直負面的打槍別人,那麼團隊大概也想不出、或是能夠理性的思考出比較有趣的東西了
創業的夥伴們,共勉之!YO! (直銷?

2012年10月30日 星期二

心得:Taipei.py 2012 10 月聚會


這是我第一次到 果子咖啡 參加活動
對於此地的印象就是對
宅宅工程師的聚會非常友善:
  • 要吃晚餐的話,有兩杯飲料、一份果凍、一份主餐,對於腦力消耗大需要吃粗飽的人有所滿足
  • 宅宅 工程師的襯托下,女性店員氣質佳,看了心情就好 >///<
  • 提供了場地跟器材的協助(其實這一點才是重點啦!)
儘管我上個月沒有參加到 Taipei.py September Meeting
不過我剛剛找到「覺得用 Python 的都是好人」的講者 Tim Hsu 的 投影片 及另一位大大的 筆記
(同感啊~
用 Python 的男生都是好人,女生都是正妹

對於本月有關 ML 的演講,老實講,我聽不懂
儘管如此,其實我認為能夠在活動中跟同樣是 Python 的愛好者聊聊,才是最大的收穫
在這一篇紀錄性質文章的結尾,感謝本月講者 c3h3 、感謝活動舉辦人,並且附上投影片 Orz



2012年10月16日 星期二

心得:使用 Vim 編輯器的第一年

Photo from: Jesse Huey. Mountain Madness photo


記得當年大一剛學寫程式時,曾經被老師強迫要遠端登入助教的電腦用 Vi 寫作業
那個時候根本不懂怎麼使用他,就只記得 yy dd p :wq …,大概十支手指頭內數得完的指令
我對 Vi 的印象就是難用
雖然看起來比較帥 …
之後陸陸續續在:
  • Windows 用 Visual Studio 或是 Notepad++
  • Linux 用 Eclipse, Gedit 或是其他替代品
多年以來在 linux 終端機環境下,我就算只要編輯某個檔案一兩個字
絕對也是輸入 gedit filename 來開啟編輯器
只要能夠躲開 Vim ,就竭盡所能的逃開他 …
一年前我也還是這樣想
只是我大概沒有想到一年以後,情況卻相反
對於撰寫後端程式這一件事情,我現在認為 Vim 是最能讓我發揮高效率的編輯器
因此我試著撰文閒聊 Vim 這一個編輯器
這篇文章,不是教學,比較像是 Vim 嫩咖的經驗分享
文章的技術含量不高,不過可能會出現奇奇怪怪、有趣
(或不有趣)的東西 :p




開端是因為不得不使用 Vim

Photo Source


大約一年前,我 加入一間新創公司,當我聽到要寫 Web 時
腦中一瞬間浮現了唸書時的 100% 微軟完美解決方案:
  • Visual Studio
  • ASP.NET
  • C#
  • MS-SQL (但是新創公司哪來的錢買這些工具!)
很遺憾的,現在不是單純作學術,成本跟效能都得慎重考量
以 Linux 為主的解決方案才是大多數人選擇做 Web 的方式
很幸運的,我們團隊搭上了 AWS 的列車,我也被迫必須開始跟 Linux 做好朋友
而在必須遠端連線到工作環境的情形下,我不得不使用 Vim 來編輯設定檔、程式碼
初使用時,早已習慣 Visual Studio 的我只覺得超級不方便 (
上下左右移動時手指頭敲得好累)
但是隨著 .vimrc 的調整、plugins 的安裝
卻越來越習慣這樣的開發環境,我想 Vim 有幾個決定性的優點:
  • 少了滑鼠的干擾,Vim 讓我雙手不用離開鍵盤,可專注於打字以完成眼前的工作
  • 便捷的文字處理功能,非常適合撰寫及修改程式碼
    舉例來講,撰寫一般的文章時大都想好後循序打出即可
    但是寫程式卻常常要塗塗改改或是重複使用剛剛命名的變數…
    Vim 的文字處理功能從低粒度的修改到全域的修改都能支援,使得撰寫程式這一件事情是有效率的!
  • 可以依照自己的使用習慣客製化出自己喜愛的 Key Bindings
  • 可以安裝 Plugins 來補足想要的文字處理或是 IDE 功能
  • 內建於非微軟的大多數環境,到處都可以使用到 Vim

當然,Vim 也有著「學習曲線長」、「使用者需要載入比較多記憶體以記憶快捷鍵」 … 的缺點
我認為 Vim 無法成為短時間內好上手,且高效率幫助開發的工具
但是如果一個編輯器要用十年,那麼具有高度成長可能性的 Vim 會是很好的選擇




跟著比自己好學的人學 Vim 比較快

Photo from: saxon. Follow my lead


事實上,使用 Vim 的前兩三個月,我還是處於不太會使用 Vim 的狀態
我覺得自己「真的」開始學 Vim 的時間點其實是在今年初
而學習 Vim 的方式很簡單,就是每天定時看噗浪
剛退伍時由於整個人腦殘,為了恢復腦袋,我會在噗浪上面「搜尋」特定關鍵字(如:Vim 或 Python …)
以訂閱各領域大大的噗來吸收經驗值
我很幸運的剛學 Vim 沒有多久,就遇到噗浪上的 某大大 也在學 Vim
因此我的學習方式為:
  • 每天看大大們分享的連結或文章學 Vim
  • 一看就懂得就馬上學起來
  • 要花時間吸收或練習的,就擺著慢慢吸收(有時候一篇文章會擺一兩個禮拜)
  • 真的看不懂或覺得 Level 超過自己太多就自動忽略 (反正重要或好用的東西會一直出現!)
學習的過程中我發現越是大大越好學
而自己找資料學習的能力太弱,倒不如先跟著學,然後再偷看大大都到哪裡學 …
截至目前為止,Vim 對我而言已經是一個高效率的編輯器
我相信持續學下去,總有一天使用 Vim 寫程式的速率應該可以達到大大們的 1/3 吧!?
其實我認為 Git 的流行對於 Vim 的推廣跟使用是有所幫助的
使用 google 趨勢搜尋「github vim」整體來講熱門度不斷上升
現在只要稍微找一下,就可以看到國內外神人們所分享出來的 Vim 相關 Source code
而每個人使用的小技巧,也很容易可以分享給他人知道




Vim 是一把可變形、可升級的武器


Source



透過修改 .vimrc 及安裝 plugins,Vim 能夠變得很不一樣
我在此分享一些我常用的
瘋狂設定:
  • 在 Normal Mode,我喜歡使用 ',' 鍵 當作 leader key
    • let mapleader = ","   
  • 建立開啟 .vimrc 的快捷鍵
    • map <leader>v :e ~/.vimrc
  • 建立快捷鍵以使用 source 來重新讀取當前的 .vimrc
    • map <leader>R :source ~/.vimrc
  • 如果與同事共用主機帳號,怕自己的 .vimrc 會干擾對方 讓對方吐血而亡,那麼可以在 .vimrc 放上這兩行
    • let mapleader = ","
      map <leader>vv :so ~/.real_vimrc
    • .real_vimrc 才是你真正的設定檔,而你的設定檔只在你使用快捷鍵 ,vv 的組合之後才會讀取進來
  • 在分頁之間切換時,我喜歡對分頁 1~9 用下列方式設定快捷鍵
    • map <leader>1 :b1
  • 鍵盤上的「上下左右」方向鍵不用白不用,我拿來將上下改為翻頁且置中、左右改為前後分頁切換且置中
    • nnoremap <up> <C-U>zz
      nnoremap <down> <C-D>zz
      nnoremap <left> :N<CR><Esc>zz
      nnoremap <right> :n<CR><Esc>zz
  • 我是瘋子請大家不要學 我從小打電動上下左右移動都是 wsad,常用的方向鍵也是倒 T 字型 …
    • 所以我認為使用 hjkl 移動 不如使用 ijkl 倒 T 字型移動
    • 對!我用 h 取代了 i,大家天天打 i,我卻天天打 h …
    • (太瘋狂了,相關設定不附上)
  • 另外我認為從 Insert Mode 回到 Normal Mode 需要按 Esc 鍵,我的指法適應不過來,因此我選擇使用 ;; 代替 Esc
    • inoremap ;; <Esc>
    • 事實上 ; 符號成為了我在 Insert Mode 下的 leader key,例如以下用法可以切換到 Normal Mode 並選取當前字:
    • inoremap ;v <Esc>viw 
    • 在 Insert Mode 下單鍵存檔
    • inoremap <F6> <Esc>:w<CR>
    • 輸入單一個 ; 符號時會發現速度較慢,可以透過 ; + <Space> 來輸入 ;
    • inoremap ;<space> ;
  • 如果需要直接以 Python 執行此檔案,可以使用以下的設定:
    • autocmd BufRead,BufNewFile *.py map <leader>r :% w !python<CR>
  • 個人奇怪的 Key Binding 還蠻多的 畢竟連 i 都敢改掉了,有興趣者請告知,我整理後再釋出!




Vim 仍然需要維護、需要管理

Source


對於 .vimrc 的內容我一直很隨便,看到有趣的語法就隨便找空位插進去
Vim 的 plugins 也是看到感覺不錯就安裝一下
結果這樣子胡搞到後面,我根本不知道我自己裝了哪些 plugins 跟設定哪些快捷鍵
除了快捷鍵之間可能有所衝突以外,更糟糕的是 Vim 的速度也被拖累 …

前一陣子我總算痛定思痛,乖乖把 .vimrc 整理一下並且打上給自己看的簡單註解
Vim 的 plugin 管理工具,也從 Pathogen 換到更強大的 Vundle

此後只要帶著 .vimrc 走就可以在不同環境自動把 plugins 給安裝好,一切變得便捷許多
對於 .vimrc 及 plugins 的使用,我目前傾向「真的要用到再加入、安裝」
盡可能使其保持乾淨狀態或說讓其為可掌握的




對於 Vim 的看法

Photo Source


Vim 的進入門檻跟學習曲線其實還是頗高
我也認為他還不夠友善,印象中 Linus 大大大大…
好像在某訪談中有提到,他手邊有一個編輯器能夠讓 Vim 看起來像記事本 …
或許改天釋出後會八掉 Vim!?

我認為 Vim 的優點是 Normal Mode 與 Insert Mode 的區分
缺點卻也是這兩個模式的轉換成本
客觀來講,的確是有可能讓這兩個模式相處得更好
(事實上,許多人會從設定 Insert Mode 下的快捷鍵開始著手改善)

對我而言,使用 Vim 後的確讓我仔細的思考過自己的打字習慣及弱點
例如我發現原來我只會打注音符號跟 abcd ,有許多標點符號跟數字並不在我的反射神經之內…
在這種情況下,使用 Vim 的效率就降低啦 Orz

我相信,無論使用任何編輯器
只要願意用心分析自己的使用情況及思考編輯器實際上能夠提供的幫助
就一定能夠找到最佳化自己工作效率的方法

總之,寫程式還是要靠大腦,編輯器升級人也要跟著升級,才不會發生悲劇
在接下來的一年內,希望我可以學跟寫一下 Vim Script,期許自己能夠更加掌握這一個能夠用十年的神器!
各位再見啦~明年 Emacs 的心得文見!


備註:
1
如果有人還沒玩過 Vim, NCTU CS 有對 Vim 做很好的介紹
現在在成大教書的 Jserv 大大… 很久以前也做了一張 Vim 的 好用小抄
另外到 google 搜尋 「Jserv 自幹」,點選第一部影片,就可以看到 Vim 的火力展示
2
本文風格可能有點詭異,不像技術文章,不是專家見解,但也不是那麼純粹的喃喃自語
我也不知道這種文章怎麼歸類,但是大致上是整理過後的心得文
無論如何,我也還在試著學習怎麼寫出有自己風格的部落格文章
如果您有任何看法或建議,請告訴我一下,以幫助我升級 Orz
3
這是我寫於四年後的另一篇 Vim 心得文:閒聊:使用 Vim 編輯器的第五年

2012年9月13日 星期四

活動:Facebook World Hack Taipei 2012


會場在 101 對面,風景好的很,還有真實的憤怒鳥彈弓可以玩

開發人員目測應該有 150 ~ 200 人,雖然活動很低調,可是來的人還是很多啊!


這是我第一次參加 Hack Day 類型的活動
活動的場地實在很不錯,風景好且放嗨歌寫 Code 真的頗熱血
我還記得我把憤怒鳥玩偶用真的彈弓射出界且又高又遠
旁邊的工作人員一直偷笑 XD
整個 Hack Day 的規格確有國際水準

為了這次的 Hack Day, 我從現有 全民電視 的專案
整理出了一個基本版的 Facebook Login/Logout API Framework
只要套上申請好的 Facebook Key/Secret 等等設定,就可以提供 client 端基本的登入登出等等 API 功能
這套 framework 當然是 open source 的!
不過現在沒有什麼價值,運作方式只會讓人覺得很詭異
因為專案中夾雜著剛學 Python 時所寫的 Child Code 以及許多我們平台綁定的格式及 Code
此 framework 目前 不推薦使用也不推薦觀看
希望接下來幾個月,能夠有時間整理出一個乾淨且泛用的 API Framework, 甚至提供 Long-Polling Class 的 Support …


此次的 Facebook Hack Day 活動,在活動開始前我們團隊發現幾件事情:
  • 這次的活動異常的低調,似乎知道的人很少,有相關討論的人也很少
  • 整個 Hack Time 只有六個小時
  • 獎項很不明,只知道最大的獎項是可以去跟 Facebook Team 見面
  • 之前其他地區舉辦的 Facebook Hack Day 系列相關活動的得獎作品,大都概念很簡單,如:製作生日快樂罐頭訊息的 APP …

仔細想想整個 Hack Day 對於 Facebook 而言,目的可能是:
  • 推廣自己 (Open Graph, Mobile SDK … )
  • 看到許多人開發 Facebook 相關的 App, 而且此 App 是對 Facebook 有所幫助的
  • 找到他們所感興趣的團隊
  • 有關讓 Developers 之間互動等等的目的就不再贅述 …

Hack Time 只有六個小時很明顯是不太夠的,從認識朋友、組隊、討論、實作、準備 DEMO …
這些程序恐怕就要花上一整天才有辦法產生比較完整的東西
所以 Facebook 不想要收到完整的東西?
我認為他們要的就只是一個對他們而言有創意的 Idea, 一個善用他們提供的資源所做出的產品
(且此產品要對其核心價值有所幫助)
Idea 是不是事先想好,甚至事先偷跑了都不是他們最 Care 的事情!
當然,如果只是把整個早就弄好的產品也不修改就拿來參賽,那就會完全失去了 Hack Day 的樂趣 …
這一切都取決於參賽者的心態跟目的


我們考量到既然要參賽,那就乾脆做一個自己覺得有趣,且 Facebook 一定也感興趣的 App
於是比賽前幾天,我們做了以下準備(偷跑):
  • 每天真的都在 Hack Facebook 的怪咖 CEO 負責系統設計,撰寫文件跟設計 DB 格式
  • 我開始整理 API Framework
  • 負責前端有時候還要跨後端的強者我同事則是開始玩 twitter bootstrap, angularjs …
  • 手邊有國際等級 APP 的 iOS 工程師,因為家裡有事情,臨時無法參加
簡單講,我們的 Hack Day 很不要臉的從週末就提早開始了!
由於萬事具備,比賽當天我們能夠當場申請新的 Facebook App, 即時調整 Serer 的設定
然後 Oauth Login 的功能,花幾分鐘改個設定就會動
要存取 Graph API 的 Function 早就寫好了,連要使用 Graph API Batch 功能的 Function 也都包裝好,可以馬上使用
(很遺憾我們沒時間申請網域跟處理 SSL 憑證,所以只有直接的 IP Adress … 造成了後來的一些問題)
當天 Hack Day 下午,我就看著文件拼命寫 Code !(事實上,前一天我還先寫了兩支 API)
最後我爆氣大概寫了 300 ~ 400 行 Python Code ,對我這種 Coding 嫩咖,已經算是突破自我了

Demo List


輪到我們團隊做 Presentation 時,遇到了很囧的事情:
  • 電腦被 似乎沒用過 windows 8 的 工作人員重開機,事先準備好的頁面都沒了 …
  • 遇到解析度跑掉的問題,整個頁面都看不完整
其實當下應該要拒絕馬上開始,堅持把環境處理好以後再開始 present
不過我們本身隨機應變的能力還不夠 … ,且就算扣掉上述問題,我們的整個 presentation 本身也處理不好
因此最後我們家的老闆跟怪咖 CEO Terry 拖了大家很多時間
Presentaion 過後,大家其實頗為沮喪,一個有趣的 Social Game 被 present 得很不有趣 Orz
仔細想想,其實整個 Hack Day 最大的重點是 presentation 是否能夠:
  • 表達出自己的 Idea
  • 說出此產品哪些特點符合 Facebook 的需求
  • 給大家看到產品完成的樣貌(但是不用全部沒關係)
亦即,很多產品非關緊要的細節其實不用實作 只要能夠完成基本要求(例如使用 Open Graph)得到分數即可
重要的還是想辦法在時間內讓大家印象深刻、理解我們想要作什麼!



遊戲首頁



進去後的個人畫面


遊戲畫面(先跟當事人抱歉,我幫你們做了馬賽克 XD)



最後的最後,很幸運的評審們應該知道我們在做什麼
我們得到了 最佳遊戲獎
禮物有: iPad, shuffle*2, $250 Facebook 廣告費用 …
最重要的是得到了 Facebook 的肯定
我們能夠在短時間內原創、設計,並且手工打造出了一個 Social Game: Memory Millionaire !
(雖然內含許多 BUGS)
這樣快速開發一個產品的過程(發散、收斂、衝突、妥協、爭論、配合),才是我們團隊所得到的最珍貴經驗!


之後我們會討論如何推廣並且讓大家都能夠玩到 BUG 比較少的這一款遊戲!
Cheers!


2012年9月3日 星期一

心得:稍微加強一下 Python 的 logging module

Python 的 logging module 是一個非常好用、方便的工具
關於他的介紹除了官方文件外
這裡有一篇雖然是英文可是淺顯易懂的文章 Good logging pratice in Python 推薦參考

我發現我個人使用 logging 時,特別是使用 logger.error 來紀錄一些例外狀況時
  • 會想要隨手塞幾個 object 當作參數
  • 使用 logger.error 後,常伴隨著的是 return False 的語句
因此我嘗試寫個 wrapper 來把 logger.error 給包裝一下
但是這樣會有個小缺點,實際執行 logger.error 的 function 會變成是 wrapper function
這樣的行為,對於想要紀錄是哪一行程式碼呼叫 logger.error 時
會抓錯位置而導致跑到定義 wrapper function 的地方
或許還有辦法解決,不過我還是忍不住直接使用 PDB++ 來瞧瞧 logger.error 的 source code
意外發現相當容易修改

我的小修改如下:
  • 寫一個 error_hack 直接取代 error,當然是 based on 原本的程式碼作一點點小修改
  • 加上一個將所有 args 參數轉成字串的小功能
  • 在函數的最後加上一個回傳值 False

程式碼及範例如下:
(其實也沒什麼特別的,就是一個小修改,讓我以後方便使用及少寫一點程式碼)


# Modified by joe.dev 
import logging

FORMAT = '%(asctime)-15s %(message)s'
logging.basicConfig(format=FORMAT)
logger = logging.getLogger()
def error_hack(*args, **kwargs):
    if len(args) > 1:                   
        log_str = ""
        for a in args: 
            log_str += str(a) + "  "
    else:
        log_str = str(args)
    logger._log(40, log_str, None, **kwargs)# 40 -> error level
    return False
logger.error = error_hack

def do_some_task():
    return logger.error("Orz 1", "Orz 2", ["Orz 3"], {"Orz 4": "Orz 5"})

if do_some_task() is False:
    print "My task failed"

2012年8月8日 星期三

介紹:Munin - 安裝 Plugins 以及 Python 化 Plugin 的撰寫



Munin 支援加入 plugins 以監控更多的系統或特定應用程序項目,而且方法非常簡單
首先我們先透過執行 munin-node-configure | less 來閱讀 plugins 的使用情況
事實上我們也可以到直接放 plugins 的資料夾
觀看目前 munin 可用的 plugins 以及正在用的 plugins

#正在用的
ls -al /etc/munin/plugins
#可用的
ls /usr/share/munin/plugins/

我們發現到了放在 /etc/munin/plugins 內的檔案為連結檔
而且是連結到 /usr/share/munin/plugins/ 內對應的檔案
沒錯!若要新增或是移除目前使用的 plugins
只需透過新增、移除放在 /etc/munin/plugins 內的連結檔即可


有關 plugins 的安裝、撰寫可以參考 官網 或是 上一篇文章 推薦過的 Tutorial
在此則是推薦安裝這一個 Python Framework: python-munin
可透過撰寫 Python 來開發 plugins 也可以直接使用許多已經寫好的 plugins
安裝方式如下:

git clone git://github.com/samuel/python-munin.git
cd python-munin
sudo python setup.py install

安裝完成後就可以參考 教學文件 使用 Python 開發 plugins
或是直接到 plugins 資料夾內看看有哪些 plugins 可以使用

我們發現 plugins 竟然已經支援了下列這些常見的應用程序、系統:
* AWS ELB
* AWS SQS
* Cassandra
* DD-WRT Wireless Rate & Signal
* Memcached
* MongoDB
* MySQL
* Nginx
* RabbitMQ
* Redis
* Riak
* … …

要啟動 plugins 就直接把相關的 plugin files 複製或製作連結檔案放到 /etc/munin/plugins 內即可
如此一來,就可以輕鬆的監控自己的系統狀態了!



備註:
有些 plugin 是 rely on 特定的環境的,例如如果要監控 nginx 的狀態
可能需要開啟 nginx_http_status_module
這裡附上大神 Tsung 的 啟用 Nginx Status 的設定 一文



介紹:Munin - 容易上手且支援網路傳輸的圖形化系統監控工具

使用 Munin 監控網路狀態的系統畫面

標題雖有點冗長,其實 Munin 對於大多數的終端使用者而言
就是一個可以透過 Web 介面觀看自己系統狀態的工具
詳細介紹請參考: 官網 Wiki
有關 Munin 的教學,此篇 Tutorial 寫的很好、值得一觀
本文只簡單的介紹部分內容

我們可以透過類似 sudo yum install munin-node 的指令安裝 munin-node 在特定 Server
以及在欲蒐集監控內容並且產生報表的 Server 安裝 munin 透過 sudo yum install munin 的指令
安裝完成之後,我們需要編輯兩者的 config 檔案:
(如果兩者都安裝在同一台 Server,那麼 config 檔案可以不用修改)

#首先編輯 munin-node.conf
sudo vim /etc/munin/munin-node.conf
#找到下列這一行,以修改成可查詢者的 IP (預設只允許本機做查詢)(系統若有防火牆,記得修改,預設使用的 port 為 4949)
allow ^127\.0\.0\.1$ 

#執行 munin-node
sudo /etc/init.d/munin-node start
#再來編輯 munin.conf
sudo vim /etc/munin/munin.conf

#找到被註解起來的這一行,此資料夾為最後圖形化報表的輸出目錄,可以自訂
# htmldir /var/www/html/munin/

#找到帶有 a simple host tree 的註解,下方會有一個 sample,填入被監控的 node 的資訊
[node_domain_name]
    address 127.0.0.1
    use_node_name yes
    
#不用主動執行 munin,他已經被設為 5 分鐘執行一次,如果想要更改頻率可以透過修改以下檔案達成:
sudo vim /etc/cron.d/munin


最後一步,就是將 munin 所生成出來的監控結果放到 Web Server 上面
然後使用瀏覽器觀看監測結果
如果想要直接放到 nginx 上面,可以修改以下 script:
location /SOME_FOLDER_NAME/ { 
    alias /var/www/html/;
}
如果想要先隨手架一個 light-weight 的 Web Sever 來試試看,Bottle 是我推薦的首選:
#save as test.py
from bottle import route, run, static_file
@route('/')
def return_static_file(filename):
    return static_file(filename, root='/var/www/html/munin/')
run(host='localhost', port=80, debug=True)
Run Web Server: python test.py
請打開 Browser 輸入: http://your_domain/index.html
這樣就可以見到預設的監控首頁了!

備註:
1.
如果出現 404 訊息
可以檢查 /var/www/html/munin/ 內是否已經有 munin 自動生成出的 index.html
還沒生成出來的話,就請等待幾分鐘再看看
2.
監控的結果當然不應該是 Public 開放出來的
因此無論使用哪個 Web Server
都應該啟動基本的身分驗證功能
Munin 所輸出的 HTML 資料夾內包含了 .htaccess 可供某些 Server 設置
而 Bottle 的 HTTP BASIC Authentication 方式可能比較少人知道
所以我附上實作方法:
       ###關鍵在於使用 auth_basic function, 並且傳入一個用來檢查 username 及 password 的 function###
from bottle import route, run, static_file, auth_basic
@route(‘/<filename:path>’)
@auth_basic(lambda name, pwd: name==“username” and pwd==“password”)
def return_static_file(filename):
    return static_file(filename, root=‘/var/www/html/munin/’)
run(host=‘localhost’, port=80)
3.
如果 munin-node 與 munin 並非在同一台主機內
那麼兩者之數據傳輸應該啟用 TLS 功能,以確保資訊安全

2012年8月6日 星期一

筆記:利用 Python 將 Markdown 文件轉成 Mou Style HTML


近期手邊的 API Server 在規劃自動生成 Doc 的功能
而 Survey 許多標記格式以後,最後由極輕量化的 Markdown 勝出
雖然平常在 Mac 下使用 Mou 進行 Markdown 的撰寫是一件輕鬆愉快的事情
但是我希望自動生成出來的 Markdown Doc 轉換成 HTML Doc 的過程不要使用到 Mou
因此 Python 的 markdown module 派上了用場:
import markdown
html = markdown.markdown(your_text_string)


理論上,只要這樣子使用並且注意 your_text-string 的編碼
就可以解決問題了 …
不過很「恰巧」的是,由於 Mou 支援簡易表格對 HTML 的轉換
而我也不小心使用了如下的語法:
First Header | Second Header | Third Header
:----------- | :-----------: | -----------:
Left         | Center        | Right
Left         | Center        | Right
以產生這樣的 HTML:
First Header Second Header Third Header
Left Center Right
Left Center Right


markdown module 並不支援簡易表格的轉換
因此我只好去找看看是否有其他使用不同 engine 的 module
最後我找到 snudown module 可以支援簡易表格:
import snudown
output = snudown.markdown(input)
不過他的小問題是對於 <pre> <code> 的支援有點問題
(畢竟是 for reddit )
儘管如此,我們還是可以僅只是把有關簡易表格的部分交給 snudown module 來處理
其他部分由 markdown module 或是更加容易上手的 markdown2 module 來處理

最後,我希望使用 Python 轉換出來的 HTML 格式能夠盡可能的與 Mou 外觀一致
所以我去偷看了 Mou 所使用的 CSS file (可從 Preferences -> CSS -> Edit 開啟檔案)
我選擇了 github 的 Style 作為參考依據
如此一來就可以在遠端的主機全自動化的生成我想要使用的文件啦!

備註:本文即為由 markdown 撰寫而成

2012年7月15日 星期日

介紹: From Screen To Tmux

近日 coolshell 的 28神器文 引起了許多人的注意
(身為一個真的不會 linux 的人,只好加到書籤,慢慢研究)
其中神器 tmux 又因此被推薦啦!

由於這幾個月摸 linux 以來不斷的聽到有人說 tmux 比 screen 好用
而 screen 我僅僅只會一點皮毛(黏、不黏、新增、刪除、改名)就覺得很方便了
索性便藉此從 screen 換到 tmux
順便好好學一下此類的工具
以下為個人的筆記與心得,整理成問答的方式:



1. 為什麼要從 screen 轉換到 tmux ?


專業的回答 在此 ,而對我而言其實 screen 的功能已經算夠用
如果平常 screen 也只是開兩三個分頁,或者螢幕根本不大
那麼其實換到 tmux 在閱讀以及視窗轉換上,並沒有辦法得到多大的好處

但我轉換到 tmux 以後,花了好幾個小時思考及設定 .tmux.conf 的設置
因而能夠自動初始化我的工作環境,對於日後生產力的提升肯定是有的!


2. 如何從 screen 無痛轉換到 tmux ?

專業的無痛轉換 在此,說穿了就是把 tmux 的快捷建設定跟 screen 一樣
那基本上就不會痛了!另外建議將 .tmux.conf 也加入版控系統中吧!
我比較懶惰一點,因此 .screenrc .tmux.conf 都是塞在 vim 的 repository 裡面
然後再 ln -s 建立對應的連結,放在家目錄下


3. 如何設定 .tmux.conf 以提升效率?

第一位專家 在此
有兩行設定很值得參考:
bind-key r source-file ~/.tmux.conf 
bind-key S command-prompt -p ssh: "new-window -n %1 'ssh %1'"
前者使得 tmux 的 .tmux.conf 設定檔可以動態的更新
後者的 command-prompt 用法,則是利用快捷建開啟新視窗及啟動 ssh 程式

第二位專家 在此
相信很多人一看到 #!/bin/sh 眼睛就會亮了 ....
這邊是透過撰寫 shell script 來自動初始化工作環境

第三位專家們 在此
這是 stackoverflow 的討論串
有許多種初始化工作環境的方法
下面這一種在 .tmux.conf 中設定快捷鍵去讀取外部檔案以進行初始化的方法頗有趣:
bind S source-file ~/.tmux/session1
在 session1 此檔案中可以定義該如何初始化,如:
new -s hello -n world
就代表新增一個名為 hello 的 session 並且切出一個名為 world 的視窗



4. 如何更瘋狂的設定 .tmux.conf 以提升效率?

不專業的回答在此,請大家斟酌參考!
首先可以使用 bind -n F9 new-window 此類的方式讓鍵盤上的 Function Key 有事情做

如果大家真的很討厭按 ctrl + a 或是 ctr + b 這一種 prefix 的設定方式的話
其實也可以把 prefix 設定成單鍵,如某個 Function Key
小缺點是 Function Key 可能有點遠
因此我選擇將 prefix 設定成: `     <-- 就是跟 ~ 同一顆鍵盤按鍵的符號
為了讓 vim 裡面常用的快捷鍵 `` 以及 `. 可以正常運作
因此我加上了:
unbind '.'
bind '.' send-keys '`''.'
unbind '`'
bind '`' send-keys '`''`'

至於原本 vim 的前往書籤功能
我選擇改為使用 <leader> + m + 書籤字母
~/.vimrc 加上這一行:
nnoremap <silent> <leader>m `
所以最後就變成:
ma               -> 建立書籤a
<leader>ma  -> 前往書籤a
由於我不常用到自定義書籤功能,所以我是可以接受多敲一個鍵的!

這樣的小缺點是真的要打出 ` 符號的時候,必須連敲兩下才會一口氣出現兩個 ``
不過我真的不常打這一個符號!便利性遠大於不便利!
這樣子設定之後,tmux 應該已經沒有不好打的快捷鍵了
即便有,也可以透過修改 .tmux.conf 來簡化他!



希望大家使用 tmux 愉快!



備註:
.tmux.conf 的設定方式,可能因版本不同而略有小差異
如果嘗試使用專業或不專業的建議而出現錯誤訊息
煩請注意錯誤訊息上面所寫的正確用法或是詢問 google











2012年6月20日 星期三

心得:Python 中文入門書


在此分享自學 Python 半年多以來的中文入門書讀書心得


如果你已經有程式基礎且馬上要用 Python 寫些東西:
請不要看這些入門書,直接使用 google 查教學
一兩個晚上大概就可以學完語法、了解 Python 表面上的特性
然後找一個適合你用的 IDE ,直接寫點程式進步最快!


如果你是學生,放暑假時想自學個語言來玩玩
且你比較喜歡閱讀圖文並茂的「講義」
那麼 Head First 系列的 深入淺出 Python 應該很適合你
雖然這一本書我翻過後發現他其實只有「淺出」Python,並不深入
但是這樣活潑直覺的講義書,起碼可以讓你不會容易想睡覺
你若是有認真的去想或寫本書的習題
應該可以很快的上手 Python 這一門語言


如果你想要更深入點了解 Python 這一個語言
那麼老鼠書 Python 學習手冊 會是好一本好書
有關 Python 的語言特性,你所該知道的基本知識,這一本書都有具備
且書中的程式碼例子都專注在解釋語言特性,不會太複雜
我把本書定義成一本「標準教科書」
內容是可理解的,不會太困難的
如果你有三五天的空閒可以看書,這一本書很快就可以看完了


如果你曾經學過 Python 怎麼寫,或看過其他的入門書
那麼 精通 Python 3 程式設計 可以是一本不錯的學習兼工具書
本書要直接閱讀可能要有基本的程式底
書中除了講解 Python 的語言特性以外,更加著重在怎麼用
程式碼範例皆被設計成用來處理特定任務,具有實用性
這樣的缺點是程式碼除了表現語言特性以外還參雜著任務處理的邏輯
使得閱讀者需要想想他在幹什麼
但是好處卻是能讓使用者立即知道該語言特性的實際用處
本書內容較深,三五天內未必看的完



三本書的難度大概是:
深入淺出 Python < Python 學習手冊 < 精通 Python 3 程式設計
可以的話,後兩本書都值得收藏!


#備註 精通 Python 3 程式設計 介紹了許多 Python 3 的新特性
   對於想入門 Python 且沒有任何包袱的人而言
   可以直接考慮 Python 3 了,他的確變得更棒!
   另外本文是以目前找得到的中文書為主進行簡介
   若是也可以考慮原文書的話,fcamel's Blog 有更好的介紹


# 2013.12.17 更新:
今年 PyConTW 的 先修課程 中,邀請的講師良葛格有製作一份 Slide:

並於近期陸續與 CodeData 撰文介紹 Python:前往一看





2012年6月11日 星期一

活動: PyConf 2012

幾個月前看到正在學習的語言要辦 conference
於是二話不說便在早鳥訂票開放日訂票
事實上, 議程 在訂票前並沒有仔細看過
只是覺得身旁有一群會寫 python 的人,心情就很好了!
(事後得知公司決定全額補助諸如此類的進修費用,心情就更好了!)

怕自己學 python (<1year)還太嫩
聽不懂大神們在講什麼
除了收了一本實用導向的 精通Python 3程式設計
趕快看一下 python 3 有什麼東西以外
我稍微追 PycTW2011 的資訊
可惜的是我好像沒有找到錄影的紀錄?
總之,胡亂的看過上面的投影片 ...
(發現 魏老師 的 Python 2 vs 3,  50 行中文手寫辨識 好有趣啊!)



這是我第一次前往中研院參加研討會
雖然位置有點偏遠,進去後還必須走很遠
不過硬體設施真的頗高級
兩天都是在很舒適的狀況下聽演講、等便當跟點心
第一天的議程以科學運算上之應用為大宗
其中 Jimmy Lai 大神是我大學時的同學(他都已經在台上了,我在幹嘛啊)
他的演講沒安排什麼梗,就是很平實而邏輯清楚的介紹自己使用的工具及方法
(做人就是要這樣正直才有辦法連拿兩個大賽的冠軍啊!)
由於講者大都把主力放在 python 在科學上的應用
因此第一天講者的演講 style ,大都給人較重的學術感
老實講,我目前在做 web 開發,所以大多數的演講對我直接的幫助性不大
除了 Gage Tseng 大神的 Even Faster Django 以外 ...
他的標題有梗,演講的內容也有梗,整個演講很值得參考
可一提的是,他們的系統架構與我們頗類似
Django 也的確是我早期開發 web server 時使用的 framework
不過隨著分工成 api server,我就決定使用更 light-weight 的 bottle
(大概是以前寫 C 寫太多,我竟然曾經認真考慮不要用 bottle 直接自幹一個 WSGI app!)
我對 Gage Tseng 大神印象最深刻的是,他介紹自己的公司的時候
提到他們就是要做社交網路,那種氣魄讓我深感認同,真想拍手叫好!
(我們 PIPOSEA 也是想做社交網路(握手))
一整天的節目結束後,本來應該去參加最重要的 BOF
不過由於晚上我另有活動,所以只能含淚提早離去 ... ... Orz


第二天開場就是 Django 的開發者
就是一個大師在向我們娓娓道來 web 歷史的感覺
緊接著的 Rasiel Chang 以及 toki 大神們
Rasiel Chang 的表達非常條理分明,很明顯有所用心準備及練習
toki 則是題材有趣,頗吸引人!
講的都很精彩,Rasiel Chang 的 團隊 也在 appworks #4 內
不過由於我們團隊對外大都是由老闆出席,實在很不好意思去認親
(我果然有社交障礙!)
其後的演講,無論是用 Mac 的 ericsk 大神, 12 道家書的 lwshu 大神
或是讓人驚訝竟然已經用 python 十年的 Cyber link 講者 Honder Tsou 大神
這些大神的演講都使我獲益良多
最後一場 hychen 大神的演講則大概是這兩天最專注於語言特性的一場 talk
也是對我幫助最大的一場演講
在台下聽講時其實一直覺得很有趣
因為 hychen 講的頗快速且一下子就講到重點
這恐怕會使得某些比較不熟 python 語言特性的聽眾完全在狀況外
但對於正好需要 meta class 這樣特性的我而言
只能夠用「聽君一席話,勝讀十年書」來感謝他 Orz
(附上投影片)


整體來講,這兩天的演講學術味較重
但是對於探討 python 這一個語言特性的演講較少
很可能大家都是拿 python 來應用
所以演講的主題就集中在 科學運算、繪圖、web ... 等等地方
(我原本以為每個 talk 都是像 hychen 大神的 meta class 一樣深入!)
小可惜的地方是,有關 python 在 web 上面的應用我聽得還不夠過癮 Orz
總之,感謝主辦單位的辛勞付出及抽獎貪食蛇!
希望 python 這個好玩意,可以更為人所知,為人所用。
(希望某年我能夠熟 python 熟到能上台向大家介紹牠 ... Orz)




2012年5月5日 星期六

活動: Python 程式設計(上)(下)

之前在 Plurk 上面意外看到這一個教學 活動 ( 講者是 Mosky )
心想自己「用」了 Python 也已經一陣子
而事實上 我也只有在半年前看過 Python 學習手冊 (老鼠書!)
以及網路上零散的教學及文件
還蠻需要看看專業的 Python 推廣者是怎麼介紹這一個好東西的
於是我便報名參加了這一次的活動 ( 由 OSSF 舉辦,感謝 Rock 兩天來的努力跟冷笑話 )
上課投影片跟錄影之後應該會公布在活動網址


摘要描述一下這兩天的小心得:
1. 恆逸教育訓練中心真是有趣的地方
2. 吃了兩天的免費中餐便當(不難吃耶)
3. Mosky 是個熱血的 Python 正妹
4. 參與者有不少學生的樣子


由於我比較像是帶著「複習」、「開視野」的目的去上課
所以課程中就是一直翻著那本好久以前看過但是也忘光了的老鼠書
兩天的課程中, Mosky 教課的進度都緊咬著我看書的進度
非常快速而講重點,是很好的 Tutorial
小缺點是到了 Python OOP 的部分,速度就有點小暴走
不過 OOP 可探討的地方太多了,倒也難以在短時間說明完畢
Mosky 對於 Python 在數學及解決課業難題的應用,介紹的很好
我看到了以後,只能說對 Python 是相見恨晚 Orz
整體來講,講者講課時口齒清晰、思路清楚、課程內容及節奏大致OK
盡量讓大家多去打一點字玩 Python 是好的教學方式
雖有小瑕疵(如有時候會切換到一個人模式、 因為要拿麥克風只能一隻手打字...)
但是整體的教學是不錯的,尤其講者還只是大學生(Orz ... 拜)



兩天以來,頗有獲益
抓到了別人眼中 Python 的入門重點
重看老鼠書,也把以前看不懂或是不知道在幹嘛的內容都理解
(這本書值得看兩三次啊!)
最後,我也決定去訂購精通 Python 3 程式設計這一本書了!

2012年4月16日 星期一

引用:Meta Class In Python




利用這一次在追 OSDC 影片的時候 (講者:Hychen 大大,Blog)
順便來搞懂一下到底什麼是 Meta Class
之前在 這裡 看到 Meta Class 的介紹的時候
其實我因為當時功力太淺所以看的似懂非懂,帶過去後過一陣子就忘光了

而事實上,我們的好朋友已有提供 Meta Class 的最佳解答了:
What is a meta class in Python ?
不用懷疑,就直接閱讀有 855 (增加中)個正面評價的答案吧!


另外澄清一下
在 Django 當中確實也有使用到 Meta Class 的方式來達成一些目的
但是 Class Meta: ... 的使用方式 與 Meta Class 無直接關係就是了 (Ref.





# 順便講一下無關的東西
在 PIPOSEA的開發過程中
由於 API Server 的性質 + 對 Python 不熟
所以我目前採用的 Framework 是極 light-weight 且簡單的 bottle 而不是萬能的 Django
當然,外面有掛上其他東西 ( gevent )


2012年4月7日 星期六

活動:PIPOSEA @ Appworks Demo Day #4




Video streaming by Ustream


我們的團隊大約在 1:23:22 開始進行 Presentation
上台的是我們 Team 的 Leader 同時也是老闆
我認為他的表達大約有 75 分的水準
但是投影片的質量實在還是不及格



我們大約在今年過年前確定了要做的東西及方向 我所負責的部分為 API Server 的開發
過年後在討論之餘,開始一步一步刻出整個框架
以及逐漸解決要面對的技術問題
事實上,我們想要做的東西還是一直在改 ...
因此大約到了 Demo Day 前兩到三週
外包給美工的圖以及DB的設計才完全確定


整個具體的產品真的就是這兩三個禮拜生出來的
我大約在兩週的時間內寫了接近 2k 的 Python Code
( 順便附上計算 line number 的語法: find . -name '*.py' | xargs wc -l )
要是加上之前練功用的 FakeAPI Server 以及部分 Django + Piston code
我的 Python Code 總產量大約有 3k ,算是從 Very New 變成 New 了


這兩週三個開發者 ( Terry, Joe, Cirtis ) 過著相當「燃燒」的生活
但卻在逐漸看著自己的產品「具現化」的過程中得到無與倫比的成就感
那種做自己想做的事情的感覺,是很好的
也是這樣的熱情(以及 Demo Day 的壓力)
讓我們至少能夠順利的完成產品的 Prototype


Demo Day 的交流時間時,有許多有興趣的人來到攤位看我們DEMO
有大四的在學學生(其實看得出來是學生!)
比我們稍年長的學長
作硬體的外國人(馬上交給團隊中的擁有 USC 碩士的 lenny 應付)
對我們很有興趣,一直問問題的大叔(還問到雲端AWS去了~)
... ...
整體來講,大家都覺得有趣,覺得還有許多可能性
被肯定的感覺還挺好的
我們也得到了一些回饋


小評一下,雖然我們的表現很手忙腳亂,呈現的東西還缺東缺西
但是至少向大家說明了一件事情:「Hello world !! We are PIPOSEA !!」



About PIPOSEA:


現在的時間是 2012 年,Facebook 已經差一步就統一地球了
這個世界上卻還有人想要做 Social Network ???


一切的緣起就如同 Terry 在馬來西亞時的遭遇 --「無法與身旁的陌生人互動」
這是大多數既有的社交網路的弱項
因為他們專注的是強化朋友與朋友之間的連結
而現存的陌生社交網路,過於強調「愛情」,無法廣泛的被人們接受
而社交資料的重建,更是造成麻煩


而我們想做的,只是想要解決人與陌生人之間互動的問題
透過 自動化社交機制、虛擬(實際)位置介面、邀約互動設計以及其他有趣的元素
讓人與人可以達到架構於虛擬/真實世界之上的互動


Enjoy It !! 



2012年3月20日 星期二

筆記:Python: reload reload reload reload 大全

Python 提供了一個方便又惹人厭的 reload function
好處在於透過重新 reload 一個 module,可以進行程式碼更新
(不過在記憶體內的東西還是更新不到...)
惹人厭的地方則是 module 與 module 之間往往具有相依性
當 module A import module B ,且兩者同時有所更新的時候
reload(A); reload(B) 的結果不盡然與 reload(B); reload(A) 相同


關於這一方面的問題可以參考:
這篇中文介紹 英文原文 以及 一個解決此問題的專案
另外,使用此專案時要注意:


1. 由於 import 已經被暫時蓋掉,由 reload._import 執行
   所以是否真的要對所有的 modules 建立一個 graph
   取決於最後的目的
#我個人偏好,只對自己寫的 module 建立 graph
   因為我不會吃飽太閒去改別人的 module
2. 如果使用 reload._import 某些外部的 module 的時候造成問題
   那麼可以考慮"早點" import 這些 module
3. 對於 monitor.py ,記得補上應該要在 import reload 後面的 reload.enable()
   該 module 的使用方式如下:
   import 該 module 後,製造出monitor.Reloader() 的 instance
   並且使用 .poll() 來詢問是否檔案有所更新



另外如果不考慮相依性,只是希望達到更新 module 便 reload module 的功能
也可以參考 對岸朋友的文章 原理就只是檢查檔案是否更新過


stackoverflow 上面也有類似上述的問題,不過解法是使用pyinotify觀察檔案的更新:
detect if a python module changes and then reload: 原文  程式碼







2012年3月13日 星期二

筆記:[Gevent + Bottle] How to detect client disconnection

已使用了 bottle 這一個小巧輕便的 framework 一陣子
加上了 gevent 提供的 pywsgi server 功能之後
算是一定程度解決了想實作出的long-polling的功能
程式結構可以不用有太大的變更,也不用過度擔心 io-blocking 的問題


不過前一陣子卻苦於無法得知 client 與 server 之間的連線是否已經中斷
翻閱 api 文件,皆無法找到相關敘述
甚至還找到有人寫了一個 test-wsgi-disconnect 的專案
來說明gevent好像還不行 ... 囧rz


儘管如此
自己經過土法煉鋼還是發現其實只要直接送資料出去
就可以知道連線是否還存在
但是這樣的作法,實在有點小蠢
無奈之下,還是決定爬一下 bottle.py 以及 pywsgi.py 的 code 
了不起就乖乖從 socket 面解決問題
爬 code 過程中,意外發現了這個 solution




之後我 trace pywsgi.py 後發現有這麼一行:

514 env['wsgi.input'] = self.wsgi_input

因此一切就迎刃而解了:


solution here:

 58     import select
 59     socket = bottle.request["wsgi.input"].rfile._sock
 60     time.sleep(10)
 61     r, w, e = select.select([socket],[],[socket], 0)
 62     if r or w:
 63         print "detect disconnect"
 64     else:
 65         print "not detect"

     Done !!


#2012.09.03 補充:
如果在 59  行之前使用過 bottle.request.body.buf 類似的方法來讀取 HTTP POST 的資訊
那麼 59 行就有可能出現錯誤(無 rfile 此屬性)
原因我推測應該是因為 bottle 的 framework 順手拿掉了不必要的屬性