top

側寫 PyCon Taiwan 2013

PyCon Taiwan 2013 在 5/26 結束了,今年 PyCon Taiwan 印象最深的 slogan 是 Value-first,將如何專注發揚核心價值優先。對應 Conference 的主軸無疑是向人展現 Python 的價值,以及每個人貢獻自身的力量共同創造出這場盛會。這是一次值得寫下來的經驗,由於參與的不深,側寫成了最適當的觀察角度。


「你覺得 PyCon Taiwan 是由何時開始籌備的呢?」由會場回家在路上一直在想這個問題,如此規劃詳盡的研討會要花多久的時間籌備?回頭翻翻討論區的舊文章,我想大概是一整年吧。當然這不是一個連續的時間,但過去的一年 Python 社群在台灣確實著較大的變化。


由現在往回頭看,PyHUG 的成立開始聚集起在新竹的 Python 開發者,隨著 Taipei.py 在展開了台北開發者社群活動,聚會的頻率約在每週或隔週都有 talk 分享。隨著這些 talk 的講題累積,成為這次 PyCon Taiwan 的主要養份。聚集人群,同時能吸引潛在的使用者,像今年有些講題的講者有提到,他們是因為參與了社群的活動開始使用 Python,獲得鼓勵成為分享題目的主角。這樣的運作模式與對開拓新題材的野心讓今年的 PyCon Taiwan 成為同時有二至三軌的海量講題研討會。


創造多元講題對 Python 來說並不是難題,重點在找出哪些人可以來分享!經過每回的社群參與,人與人之間的實際互動交流可以挖掘出這些重要的候選者。Python 是泛用的語言,並且可讀好寫。在「探索」講題的過程中,社群的聚會試著鎖定一些主軸,或是在較少在台灣被提到的應用領域。相互比對,這些範圍很符合今年 PyCon Taiwan 的選題,除了當前潮流的 Big Data、Cloud Computing 與虛擬化技術,還有硬體開發與控制相關應用,而每年都會有人分享的 Web 主題自然不在話下,特別今年還選上了 Web 安全議題,這與過去幾年單純談論簡單、快速,速食化的網頁開發導向相較是一種省思,有些基本的安全線是應該緊握在手心之中。除此之外,少不了 Python 本色的主題(我個人的想法,不代表其他 Python 開發者),對 Python 本身語言的探討與科學運用、計算,若你也試著觀察其他國家的 Python User Group 在玩些什麼,他們的 PyConf 在談些什麼,不少是以教育、科學為主題的。


對於內容豐富的研討會,可是苦了聽眾。實在太多看起來有趣的題目,使人分身乏術。今年我試著改變選擇聆聽演講策略,與其到處跑堂聽一個覺得自己有興趣的內容,不如找個最舒適的座位迎接每一回的驚喜。我並不預設想要特別聽到什麼工作上直接相關的應用,也沒有特別想要舉手發問的問題,這看似預謀的隨機反而讓我覺得比過去參與不同研討會要來得舒適。二天我都坐在國際會議聽裡,所以接下來對議題的心得也會以這一間的內容為主。


在整體的演講中,覺得講得最易懂的,反而是對我來說聽力有困難的 Keynote Speak。雖不敢說聽得懂一半以上,但在分享內容的鋪陳上只能說「薑還是老的辣」。在他們的投影片或範例幾乎都是一次針對一個概念階層安排,這讓我聯想到「The Pyramid Principle: Logic in Writing and Thinking / 金字塔原理:思考、寫作、解決問題的邏輯方法」內舉出的正反例子,說明什麼樣的表達方式讓人易懂,什麼樣的表達方式讓人混淆。由於講者對表現方式安排的不同,最直接的是對每一個題目的收穫程度有著不同的感受。


不過,這並不表示對於每一個講者都必需要求他們做有邏輯的安排。有些講題其實聽起來比較像勵志小品,或新奇趣聞,能激勵群眾或開拓視野。聽者的心中往往會有這樣的 OS:「原來可以這麼做啊!」或是「原來有人這麼做啊!」也可能是「原來有人跟我想的一樣」,這大概就是 Python + NoSQL in the Animations 給我的感受,而同場加映的 懶人と Python と Animation Studio 內容,其實跟講者本身的工作比較有關係,但事後實在回想不太出來跟 Python 有什麼關聯,印象比較深的是有許多聽不懂的梗(聽得出來是動漫梗,但不知道發生什麼事情,也許有些聽眾也一樣一頭霧水),這樣的情況就比較難以辨別講者是想要帶給聽眾知識、經驗或是開拓眼界,思緒卡在那些「梗」上,私心建議,這些梗可能造成思緒上的不連續現象,還是在開頭、結尾出現一下比較適當,既不影響表達的流暢,也能滿足講者本身的願望。


「StreetVoice 如何將一個 Windows/ASP 的公司改造為」提到了如何改變不同習性的 Programmer 的甘苦談,比起技術的內涵,它無疑的是一種激勵人心的故事。(OS:公司是能被改造的,大家別灰心)


「超級比一比:比字、比價、比商品」講到 Machine Learning 的主題,讓人聽了意猶未盡好像回到了唸書的時光(雖然,東西都還給老師了,我都不好意思說以前待過資料探勘實驗室),但似乎受限於時間講者只好稍為展示一下他在做些什麼,眼前閃過一些數據,還有圖形化的結果是一大亮點,比起單純的數據,它更 human readable 是相當值得參考的呈現手法。


另外有些題目太「硬」到難以入手的情況。以 Extend your legacy application with Python 為例,雖然主持人有提醒過 是個相當硬的主題,但由於呈現方式直接進入了 hacker 等級的以「碼」會友,看看左鄰又舍似乎開始出神了起來。午餐時還聽到附近的會眾在討論是不是聽得懂,有平常似乎也沒在寫 C 或 C++ 完全無法進入狀態的對話。若是要比喻大概就是,第一次爬山就要登玉山的感覺唄?這樣的題目也許需要更多的時間來鋪陳,或是同系統依序由淺至深的幾個講題漸漸進入才容易開啟聽眾的接受度。畢竟站在台上的無疑都是具有多年經驗的開發者,他們的功力是大家都明白的,礙於時間與篇幅的限制,也許籌辦單位要稍為建議一下,試著讓內容控制在一個可接受的範圍,像是將範例偽裝成如 Hello World 般簡單。個人是覺得平常有在寫 interoperability 相關的程式應該不至於那麼難懂,這東西確實不是聽幾十分鐘就能「略懂」的,還是得真的做下去,有問題了才知道該去弄懂些什麼。這麼想吧!它反而是個值得做為黑客松的範圍。


在這個 Track 的講題中,剛好有近年比較有興趣的主題。 Scale Out 的問題,從 Keynote Speark 的 Building to Scale 到後續的 Building a Render Cloud。大致抓住一個簡單的感覺,Scale 問題在於如何適當地分配 Loading,而如何分配 Loading 在架構中動手腳是最快的,像是 Sharding 或 Queueing。會後回想了一下,還俏皮地寫下了這樣的比喻:「關於 scale out 的相關 talk 發現一個重要的 key point。已知用火讓人類進入熟食時代,已知用 Queue 讓架構進入雲端運算的時代。」 分散或排隊並不是通解,只是針對現有講題的內容抓出重點分享。會有興趣主要是自身工作的項目也跟這有關,架構與 Building a Render Cloud 相似,只是由於工作的關係,我們公司是以 Java 實作罷了。


在 Building a Render Cloud 分享完之後,我也提問了一個問題:「要將機器 Scale Out 是容易的,但是對於使用 After Effects(一套商用軟體)的部分它的 License 要如何 Scale Out」,講者分享了由於這個問題,他們只能建立符合 License 數量的機器來使用。自己想了一下,如果有人的公司也需要相似的應用時,看來 License 也會是 Scale Out 的自然限制。繼續 Queuing 吧!另外,講者的心得有提到 AWS 其實蠻貴的,依他目前的架構,看起來 Job 掉了是可以重做的,我想可以試著使用 Spot Instance 會明顯看到費用的下降。以我們公司的經驗,每個月大概會用掉 micro type 的 Linux Server 二萬七千小時左右,用 Spot Instance 與一般 Instance 的錢是天差地遠的,並且我們仍持續試圖在做「成本最佳化」的修改。另外,也許可以試著像客戶服務專員提出 After Effects 使用的需求,他們就像許願池一點,雖然不會立刻有結果,但可以期待某一天能有附加 License 的選項。


以上是趁著昨日記憶猶新時,快快寫下的參與心得。期待其他 Track 的 Video 上線能再多聽一些別人的分享。


From:


側寫 PyCon Taiwan 2013