DrupalCamp Taipei 2011 已開放報名

2011 年 DrupalCamp 又來跟你碰面了！Drupal 是一個邁向第二個 10 年的 Open Source CMS 系統，將近萬種模組可以被直接安裝應用，全球共有 7000 個以上的開發者加入它的更新和修改，社群活絡程度足以媲美 Linux Kernel 的運作狀況，除此之外、它更連續兩年贏得了 Open Source CMS 平台大獎！

我們將在今年的 7/9、7/10 於台北的中國科技大學（近捷運萬芳醫院站）舉辦為期兩天的活動，預計可以容納 300 人到場共襄盛舉，今年除了一整天的多軌議程外，還有第二天的社群活動，歡迎有興趣參與的朋友可以立刻完成線上報名，以免向隅！

【研討會資訊】
◎ 時間：2011 年 7 月 9 日 ~ 10 日
◎ 地點：台北市文山區興隆路三段 56 號（中國科技大學 台北校區）
◎ 報名網址：http://registrano.com/events/drupalcamp-2011

CallGraphviz—依據 cscope、Graphviz 以及 xdot 實作的 call graph visualizer

Rex／文

開源工具現狀

許多開發者都有介入中大型專案的經驗，有時候也常常需要理解原始程式的設計，因此或多或少都有在程式碼迷宮中找路的經驗。有些專案，程式碼結構嚴謹，軟體設計時應用設計模式 ( Design Patterns)，往往只要見名稱、參數，即可推斷程式結構，閱讀上如沐春風。

但若碰到未經重構的成年老專案，程式邏輯因為年久失修，塞滿各個開發階段的臨時解決方案，常常已經複雜到難以一眼望穿理解。若是記憶力虛弱如我，常常追了後面幾千行、跳了三個檔，就忘了前面幾個檔案的函式名稱。於是常常以紙本畫流程圖輔助理解，但是手繪圖往往不敵跳來繞去的程式碼邏輯。還是得靠程式碼解析視覺化工具來協助理解。

繪製  call graph 的工具非常多，一般可以分作  dynamic analysis 與  static analysis 兩種作法。在臺灣，最知名的商業版本工具，大概是 Source Insight。不過我不用 Windows，對於缺乏原始碼的開發工具興趣也不大。

開源的 dynamic analysis 包含諸如 Jserv 介紹過的 CodeViz 或是 ncc。不過這類工具需要 patch GCC，不適合嵌入式系統專案。因爲原始碼常常只支援特定平臺，或是無法取得編譯工具原始碼。此外，不同版本的 compiler 偶爾會造成不同的問題，造成使用上的困難。

一種比較乾淨的作法是像 KCachegrind 利用 valgrind 來收集資料，或 Gprof2Dot 利用 gprof 的輸出資料。再者是利用 GCC 的除錯功能，把 internal representation (RTL) 倒出來，再用 egypt 或 Python-RTL 來判讀或繪圖。

至於開源的  static analysis，則包括 Fred Chien 介紹過的 cflow，或是 Doxygen 也有類似的繪圖功能。也有工具是配合 cscope 或 GLOBAL，例如有人幫 cscope 刻過 圖形界面，Vim 有個 CCTree 可用。

CallGraphviz

以上這些工具各有優缺點。最常見的問題是許多工具無法處理  function pointer／ dynamic dispatch，最終還是需要人力介入。另外一個使用上的困擾是，這些程式會一口氣畫出整個程式碼的結構圖。

太多資訊其實妨礙理解，因爲用途常常只是追一個臭蟲，程式開發者只想畫出特定路徑來釐清問題。而 context-sensitive 的 call graph 測試工具又耗費資源。

若用 CodeLite、Code::Blocks、Eclipse CDT 等開發工具，這些工具已經內建或者整合了 cscope／GLOBAL，提供 symbol lookup 功能。開發者很容易用滑鼠查閱函式定義或實做，也可以搭配 LXR 來瀏覽程式碼。已經不需要像是 cbrowser 這類專屬的程式碼瀏覽工具。

如果需要手動將目前程式情境視覺化的工具，也可以在網路上找到。網路上已經有其他開發者做了 Bash: C Call Trees and Graphs 或是 global-calltree。或是像 Yao-Po Wang 的方法，記錄函式進出點，再手動繪圖。

上述工具大多是整合 shell scripts，操作上有點不便。另外我也不喜歡 Call Tree 的圖式，因爲樹狀圖無法表現遞迴或交互關係。

於是查找一下，決定拿 cscope 加上 Graphviz 的 DOT 語法來用，改了一個 CallGraphviz。它的功能是以 Graphviz 做為前端，後端還是使用 cscope 查 symbols，為了可以即時瀏覽便取用 xdot 當作介面。xdot 是以 PyGtk 開發，非常容易更改，不到三百行就加入我需要的功能。

▲ 圖1 使用 CallGraphviz 自動畫出的程式邏輯流程圖

使用方法：

* 執行 python visualizer.py
* 按下【New】，選擇要分析 C/C++ 專案目錄。
* 於「Search symbol」鍵入要追蹤的函式名稱。
* 每次鍵入新名稱，他會自動對應圖中已輸入函式是否爲 caller or callee，並自動畫圖。

CallGraphviz 可以將繪圖結果存成 dot 格式檔案，然後再利用 dot 指令轉換格式。不過它只紀錄曾經查過的名稱，開啟時重新查 cscope 而已。若圖大時，每次開啟可能會十分緩慢。

CallGraphviz 原始碼可於 github 下載，授權採用 GNU Lesser General Public License。

延伸閱讀：Python Call Graph

作者簡介

蔡志展 (Rex Tsai) 或網名 chihchun，現為自由工作者，從事開源軟體顧問或開發服務。倡議並推廣自由軟體與開放源碼，早期 KaLUG 成員，現常出席 Tossug、Hacking Thursday 聚會，亦是開源人年會（COSCUP）籌備志工。長期 Debian、OpenWrt 使用者。關注議題甚廣，進一步資訊請參考 http://people.debian.org.tw/~chihchun/ 。

5 個使用 Drupal 作為架站平台的好理由！

對建置網站的朋友們，Drupal 或許是有點熟悉，又有點陌生的開放原始碼內容管理系統平台 (Content Management System)。雖然 Drupal 得獎無數，雖然 Drupal 在全球數一數二，雖然 Drupal 有超過 7000 個開發者參與其中，但就因為這種又近又遠的關係，往往各方都說好用的東西，到了手上卻又覺得不大順手，找不到這個 CMS 真正好用的理由。

今天就來以一個使用 Drupal 建置網站超過 5 年的開發者，跟各位分享 Drupal 這個 CMS 有什麼特別好用的地方，未來值得你作為公司主要的產品發展方向，甚至值得你一窺 Open Source 社群從事的各類活動。

1. Drupal 的社群既深且強

Drupal 模組很多，但仍沒有比 Wordpress 或是 Joomla 的模組數來的多，Drupal 使用者眾多，但卻沒有其他兩者多，但我個人認為，Open Source 的整體精神，比起使用量，更重要的是社群核心支持者的凝聚力和協同合作的力量。Drupal 社群有一種類似 Linux 原生社群的特質，有非常好的內聚力和包容力。社群的開發者之間充滿了公開交流的氣氛，分享出來的模組並不是單一開發者或單一公司的產物，往往是經過社群各種參與者不斷調整，彼此互相協調之後的成果，並且會隨著時間自然演進、接班、交替。

Drupal 的模組跟模組之間共生共榮，開發者跟開發者之間彼此交流熱絡，協同運作。可想而知，這也是為何每年 DrupalCon 這個世界盛會會有超過 3000 名參加者從世界各地專程前往參與，一同討論 Drupal 最新功能與最新訊息，其實，這些來源皆是因此特殊的文化習性而產生。

2. Drupal 功能無比彈性

Drupal 可以輕易地把各式各樣的內容放在同一個網站，討論區、Blog 和影音中心，甚至是會員機制、小群組機制的整合頁面，對了解 Drupal 的人都只是家常便飯。

但這些僅僅是功能的達成，真正厲害的地方並不在此，而是 Drupal 面對各種內容的核心概念。這樣把內容視為整體的核心概念，創造了 Drupal 無比彈性、歷久不衰的主因。

舉例來說，你曾經面臨過，討論區裡頭的人想要另外加入購物功能，卻沒辦法輕易達到的問題，需要 Hack 模組，大改一翻才能達成嗎？對於大多數的 Open Source CMS 平台來說，各功能間的發展，可能來自於不同的支持廠商、個人開發者，彼此技術知識並無互通，而少有 CMS 的核心，能夠扮演好模組和模組之間「接合的橋樑」。這也使得往往第三方支援的軟體孤軍奮戰作戰，想要 A 開發者的功能，又要 B 開發者的功能，就得慢慢等待少數開發者的支援或自己 Hack。

以 Drupal 打造的網站並無此困擾。熟悉 Drupal 的朋友，可以輕易製作一個商品頁面，囊括討論區的整合、地圖、影音、商品規格資料，甚至讓使用者互動的推噓功能，和社群平台 Facebook 整合，都可在彈指之間達成。

這種彈性，讓網站經營團隊免除了許多後顧之憂，網站經營者常常面臨到隨著業務發展，剛開始和半年後所需的功能不一，卻因為架構問題導致系統開發出現瓶頸，甚至原來使用的第三方延伸套件的開發廠商不再支援。Drupal 的彈性和內聚力將這種問題最小化，經營者只要有 Drupaller 協助，即可放心規劃與經營網站，不用擔心今年僅規劃商品資訊，在明年就無法加入購物車的功能了。

Drupal 的彈性若是搭配自定欄位的強大模組「CCK」，定義各種資料蒐集的欄位也輕鬆簡單，舉含活動報名資料填寫，到影音相簿、地理資訊的蒐集平台，理解 Drupal 彈性概念的朋友，立刻可從既有工具組出蒐集資料的表單。

不過，資料蒐集、資料結構僅是整個彈性網站的一環，還須搭配網頁呈現端的彈性配置。Drupal 的使用者不能不熟悉 Views 這個超級 SQL 產生器，有了 Views 才可以快速設定出表格、清單、Blog、相簿、圖表、新聞等各種形式的內容呈現頁面或區域。再搭配 Panel 這個頁面區域配置模組，做網站就像拼圖一樣簡單，一塊一塊擺到想要的位置。這些就是 Drupal 的彈性來源。

3. Drupal 與 Web 趨勢結合

很少有 CMS 能夠不斷往新的技術邁進，甚至成為引領技術的潮流，Drupal 的核心在每一個版本的演替，都隨著 Web 的潮流不斷行進。核心的演替，會有拉著第三方模組一起成長的力量。

舉例而言，Drupal 4 演進到 Drupal 5 時，做了個重大的決定，內建嵌入 Jquery 為官方支持的 Javascript Library。在 2006 年那個 Javascript Library 百家爭鳴的時代，Jquery 還只是 1.0 的階段，Drupal 就能夠精準的選擇重要的技術整併，凝聚開發者在 Jquery 力量。

而近期 Drupal 6 到 Drupal 7 的演替，又支持了 RDF 這個熱門的網路資料交換格式。可以想像，如果有百萬個支持 RDF 格式的網站，是否意味 RDF 格式交換資料的時代更有機會來臨？Drupal 便是努力扮演這種與 Web 發展趨勢結合的角色，不遺餘力。

核心的積極，表示也能夠聚集新穎技術的開發者一同共襄盛舉，舉凡各種大型網站應用，如 Memcache、Cassandra 資料庫等等的支持模組相繼出現，而近兩年熱門的 Mobile 支援，Drupal 也出現了將資料結構完整 JSON 化的 API 橋樑。

跟著 Drupal一同成長，就表示你與Web的技術不會脫節，不會落伍。

4. 高效能及可擴展性

有建置過中大型網站（月流量 1000 萬 pv 以上）的朋友，大概能夠想像一個兼具彈性、全功能，又維持極佳程式碼架構的系統，要撐起如此流量一定得有兩把刷子。自行用 Framework 開發，嚴肅的要求每一支程式碼記憶體用量、盡善盡美通常是大流量網站不錯的解決方案，但我相信身為與眾不同的工程師，各位看倌們你們的勞力值得有更好的工具，推薦擴展性強大的 Drupal 給你認識。

Drupal 的優秀案例不少，如 Economist.com（經濟學人雜誌）這個世界舉足輕重的媒體、如 Ubuntu.com 這個著名的 Open Source 作業系統官網，或是 Mtv.co.uk 等等，都是品牌、品質非常好的網站系統。觀看這些案例，並不是想看他精美的設計、多樣的功能，而是這些案例都代表 Drupal 在大流量網站中表現有多麼出色，通過了層層決策關卡，實際而廣泛的應用在商業領域中。舉例而言，經濟學人雜誌，就包含超過 300 萬註冊會員，3000 萬月瀏覽頁，每分鐘有留言和文章不斷出現的高流量。這個案例在在顯示出，Drupal 在擴展力和負載量有多高，不至於發展到一個階段，就面臨架構問題而必須打掉重來。

能夠應付這樣高流量的網站，其實因為 Drupal 本身具備良好的擴展性 (Scalibility)。從 Web 端支援多台網頁伺服器服務，到 Database 端支援多個資料庫 Master-Slave 的主從架構服務，達到基本伺服器的可擴展性，讓網站不受伺服器資源的限制，可分散服務資源到各伺服器中。除此之外，優秀的快取也支援暫存記憶體、靜態 HTML 網頁快取等等，以減少動態網頁消耗 CPU。最後，別忘了搭配 CDN (Content Delivery Network) 的架構支持，一個完整的大流量網站架構就此而生。

更進一步的利用，Drupal 還有多站系統支援，無論是 multi-site to multi-databse，還是 multi-site to 1 databse，都是 Drupal 核心支援的架構，讓你的服務在發展的途中，只需要少許的技術人員支持，幾乎可以不用擔心擴展性問題。這對一個經營者而言，不是天大的好消息嗎？

5. DrupalTaiwan.org 永續經營 ( http://drupaltaiwan.org )

經歷過 Open Source 社群起伏的朋友或許會知道，開放原始碼最怕力量分散，各奔東西，不相回饋，不聞不問。很幸運的，Drupal 在台灣的發展並沒有遇到這種情境。Drupal 台灣社群，從 2006 年至今超過 5 年的時間，進行了為數不少的支持行動，就我所認識參與 Drupal 社群的 Drupaller，大多無私奉獻，不求回饋，彼此互相成長。這些成果在哪裡？舉凡 Drupaltaiwan.org 的討論園地，或是 Drupal 現在的正體中文翻譯，到每月一次的小聚，都顯示 Drupal 在台灣已經有成熟的興趣社群、商業社群、Open Source 社群。

或許有人會問，一個在地社群會有多重要呢？資訊不是看國外的就好了嗎？永續經營跟我又有何關係？試想，今天你玩的系統沒人懂而只有你會，那市場怎麼會接受你「個人」的喜好呢？市場當然會朝向大家討論度較高的軟體，如果每個人都這麼想，就不會有現在的 Drupal 台灣，也不會有現在的 Drupal.org，我們也不會有好用的，同時也是大家一同貢獻心力而成的 Open Source 軟體。

Drupal 台灣發展至今，成功的讓少少 10 個在台灣的小玩具，發展成每年一次，超過 200 人的正式聚會、技術交流和產品發展討論。我們最喜歡為大家創造各種機會，交換心得、交換名片、交換勞力！唯有一起來創造開發的機會，Drupal 才能更加茁壯，而我們也期許自己能永續經營。

歡迎您立即加入 Drupaller 的行列，並且共同參與 7/9 舉辦的 DrupalCamp Taipei 2011，找到志同道合的朋友一起創造機會！

◎ DrupalCamp Taipei 2011 報名網址：http://registrano.com/events/drupalcamp-2011

作者簡介

Jimmy，Drupal Taiwan 創辦者、Android 中文資源站創辦者，曾任癮科技技術總監，現為社會企業 NETivism 的共同創辦人。對於串起非營利單位、開放原始碼以達到數位社會公益等冷門雜工為畢生志趣。 個人部落格：http://jimmyhub.net

用自由軟體 Plone 來架設網站 (6)－動態網頁

在前篇文章裡，我們已經建置了 Event Folder 和 Signup 兩個型別，接著，仍要依照專案需求，繼續調整功能及程式邏輯。展現網站功能的時候，我們總希望它能緊密結合視覺設計成果，另一方面，套用新的視覺設計時，會希望它不影響既有的程式邏輯。那麼 Plone 如何做到這個要求？控制視覺設計的檔案又放在哪裡呢？

Plone 系統預設的網頁呈現效果，著重在功能上，而且緊扣著內容管理的動線邏輯，這在 Intranet 的場合，可能已經足夠，但在對外服務的網站場合，通常需要調整頁面。在本文裡，我們將介紹佈景主題、視覺元件、動態網頁的相關技巧。

準備工作

之前介紹過 buildout.cfg 檔案，裡面有個 debug-mode 參數，記得要指定為 on，執行 bin/buildout 生效後，它會動態記錄在 parts/instance/etc/zope.conf 裡面，線上的 Plone 就會即時反應 HTML 和 CSS 的修改結果，在 ZMI 的 portal_css 或 portal_javascripts 裡，也看得到 Development mode 選項啟用中，如圖1 所示。

▲ 圖1 portal_css 的 Development mode 選項

瀏覽器通常會搭載輔助工具，協助存取 HTML、CSS、JavaScript 檔案資源，以 Firefox 為例，搭配安裝 Firebug 後，利用 inspect 選項檢視 layout 和網頁元件，或是離線編輯 HTML 和 CSS 內容，都能帶來事半功倍之效，如圖2 所示。

▲ 圖2 Firebug 操作畫面範例

以上只是最基本的選項及工具，想要調整更多項目，當然可以搭配其他工具，或是自行閱讀工具的細項說明。

佈景主題

我們把 Theme 稱為「佈景主題」，它是網站整體視覺設計的成果，包括 layout、color、icon 之類的設計元素，還有 page template、style sheet、image、javascript 資源檔案。

Plone 4.0.x 預設的佈景主題稱為 Sunburst，值得一提的是，部份功能使用 AJAX 效果，畫面外觀如圖3 所示。

▲ 圖3 Sunburst 佈景主題畫面

Sunburst 的 layout 概分為四個區塊，如圖4 所示。

1. 表頭區塊

2. 主要內容區塊

3. 資訊方框區塊

4. 表尾區塊

▲ 圖4 Sunburst 的 layout 示意

就既有的系統架構而言，佈景主題是 Plone 裡的一個模組，想換佈景主題，跟啟用新模組的步驟一樣，先在 buildout.cfg 加上模組名稱，下載安裝後，再到 Plone Setup 的 Theme settings 裡選定想要的佈景主題，如圖5 所示。

▲ 圖5 佈景主題設定畫面

在 Default theme 下拉選單裡，可以看到 Plone Classic Theme 選項，它是 Plone 4.0.x 以前的預設佈景主題。

視覺元件的處理

由於佈景主題模組裡的許多元件，也都適合獨立介紹和運作，因此，我們另外將它們統稱為視覺元件。目前 Plone 處理視覺元件的架構，整理如圖6 所示。

▲ 圖6 Plone 視覺元件架構

實作視覺元件時，具體的方式主要分成四類：

1．Skin Layer 方式－通常是透過 ZMI 的 portal_skins 目錄，編輯裡面的 Page Template、CSS、Python Script。這個機制屬於舊的方式，它的功能可以完整由下列的其他方式取代。

2．Browser View 方式－View 由 Python class 和 Page Template 組成，透過 configure.zcml 檔案註冊後，可以透過 http://localhost/mysite/@@my_view 的形式來執行。

3．Viewlet 方式－和 Browser View 類似，但需要搭配一個 Viewlet Manager 來註冊。

4．Portlet 方式－和 Viewlet 類似，但可以搭配設定檔，在特定的 Portlet Manager 裡顯示。它的顯示位置預設在 layout 的資訊方框區塊裡。

這麼多種方式，不如找一個簡單的切入點來示範，例如我們只想調整佈景主題裡的一部份，像是取消搜尋方框的顯示，該怎樣辦呢？

Viewlet 和 Viewlet Manager

以 Plone 網站首頁為例，諸如 logo、搜尋方框、導覽列，都是一個 Viewlet，數個 Viewlet 再由一個 Viewlet Manager 管理。管理者可以從 http://localhost:8080/mysite/@@manage-viewlets 之類的網址，進入 Viewlet 管理介面，如圖7 所示。

▲ 圖7 @@manage-viewlets 管理介面

每個 Viewlet 都有自己的名稱，像 logo 的名稱是 plone.logo，每個 Viewlet Manager 也有自己的名稱，像表頭區塊的名稱是 plone.portaltop。同時，Viewlet 可以被指定隱藏或顯示，以 plone.searchbox 為例，點擊 Hide 選項後，搜尋方框就被取消顯示，另外，也可以在同一個 Viewlet Manager 裡調整順序，如圖8 所示。

▲ 圖8 Viewlet 設定項目示範

透過 Viewlet 和 Viewlet Manager，可以輕鬆管理 Portlet 之外的視覺元件大項，但是，Viewlet Manager 的順序和顯示與否，又是如何被控制的呢？

main_template

在 ZMI 的 portal_skins 裡，點選 Properties 頁籤，在畫面下方可以看到 Default skin 設定為 Sunburst Theme，因此 Sunburst Theme 的 Skin Layer 清單項目，包括 custom、sunburst_images、sunburst_templates，會依序被讀取，如圖9 所示。

▲ 圖9 Sunburst Theme 的 Skin Layer 清單

回到 portal_skins 的 Contents 頁籤，從 sunburst_templates 可以找到一個 Filesystem Directory View 物件，名稱叫做 main_template，它就是控制 Viewlet manager 順序和顯示與否的檔案，如圖10 所示。

▲ 圖10 sunburst_templates 包含的 main_template

sunburst_templates 是一個 Skin Layer 目錄，main_template 是一個 Page Template 檔案，留意到程式碼的內容呈現灰色底，代表不能修改，要點選 Customize 按鈕後，才可以修改 main_template 的程式碼，如圖11 所示。

▲ 圖11 點選 Customize 按鈕可以修改 Page Template

上述動作會把 main_template 檔案，從 sunburst_templates 複製到 custom 目錄，留意到程式碼的內容呈現白色底，代表可以編輯，試著讓＜div tal:replace="structure provider:plone.portaltop" /＞失效，這代表取消 plone.portaltop 這個 Viewlet Manager 的顯示，如圖12 所示。

自由軟體鑄造場 誠徵網站程式開發工程師

作者是 OpenFoundry 開發團隊 我們在尋找 OpenFoundry 專案開發平台的軟體工程師，期盼有更多對自由軟體開發有興趣的夥伴踴躍加入我們的團隊，簡單說明如下：

【公司名稱】中央研究院、資訊創新研究中心、自由軟體鑄造場 (Open Source Software Foundry, OSSF)
【工作職務】網站程式開發工程師
【需求人數】1 名、履歷隨到即審。
【工作內容】設計與維護 OpenFoundry 專案開發平台
【工作地點】臺北市南港區研究院路 2 段 128 號 中央研究院 資訊科學研究所新館 402 室
【應徵資格】
◎ 專科以上：資訊工程，資訊管理，資訊科學等相關科系畢業生。
◎ 非資訊本科系畢業生，但具網站架設與程式撰寫方面的熟嫻技能並備作品可供參照者。

【必備條件】
◎ 伺服器管理經驗（UNIX-like OS，熟 FreeBSD 者尤佳）。
◎ Web-Based 相關的開發經驗
◎ 負責任的工作態度、細心認真、團體合作，正向態度的學習精神。

【加分條件】
◎ 熟悉關聯式資料庫設計與操作（熟 MySQL 者尤佳）
◎ 有業界多人共工專案的程式開發經歷，或在校內曾有相關經驗或作品者。
◎ 符合工作必備條件並領有直轄市、縣（市）主管機關核發證明之身心障礙者。

【工作待遇】依國科會標準敘薪，有工作經驗者另議。
【工作時間】日班　AM 9:00~PM 6:00
【應徵方式】
◎ 請檢附履歷、基本資料（學經歷、可安排之工作時間、聯絡方式等），寄予林誠夏，email: lucien AT citi.sinica.edu.tw
◎ 標題請註明：「應徵自由軟體鑄造場網站程式開發工程師-中文姓名」，履歷隨到即審，將於收到信後一週內擇優通知面試，不適任者恕不退件及函覆。
◎ 檔案請用 ODT 或 PDF 格式寄送。

報主的話

自由軟體鑄造場 誠徵活動企劃及業務推廣專員

【公司名稱】中央研究院 資訊科技創新研究中心 自由軟體鑄造場

【工作職務】專任研究助理 - 活動企劃及業務推廣專員。
【徵求期限】2011/06/13 前投遞履歷、2011/6/13-2011/6/30 安排面試、2011/7/1 到職辦公。
【職稱名稱】專任研究助理 - 活動企劃及業務推廣專員。
【需求人數】1 名、履歷隨到即審。
【工作內容】規劃自由軟體推廣活動並維運自由軟體鑄造場業務工作。

【應徵資格】

1. 學歷要求：專科以上。
2. 工作經驗：不拘，但以有專案管理方面經驗者為優。

【必備條件】

1. 對於自由軟體推廣具備高度熱忱與興趣。
2. 精準的言語溝通能力及面對公眾演講的膽識。
3. 負責任、積極吸收新知的工作態度及正向思考的個性。
4. 能於晚間及週末籌辦活動，並於一般工作時間進行補休。

【加分條件】

1. 對於自由軟體共工開發模式及專案管理具有基礎的了解。
2. 曾有自由軟體專案開發或是社群參與經驗。
3. 對網站應用及自由軟體程式撰寫具實作的能力。
4. 流暢的英文溝通能力並能現場口語詢答或是檢附相關英文檢定證照。
5. 符合工作必備條件並領有直轄市、縣（市）主管機關核發證明之身心障礙者。

【工作待遇】

把開發當興趣的開發者聚會－Hacking Thursday

你是否有參加過類似聚會的經驗，參與者為了共同興趣而相聚，聚會中笑鬧聲、交談聲不曾間斷，令人放鬆並且投入，往往等到即將散會，都還來不及瞄一眼牆上時鐘，才驚覺美好的時光飛逝得如此迅速。對於熱衷於寫程式的開放源碼開發者而言，Hacking Thursday（以下簡稱 H4）就是這樣的一個聚會。

每個星期四的晚上，都會有一群開發者在 101 迎風城咖啡主題美食館南西店（如遇店家整修，則可能改至民權西路 11 號之 101 咖啡主題美食館民權店）裡進行固定聚會。H4 聚會沒有事前安排固定主題，完全以隨性、自由的方式分享；無論是工作上遇到的難題亦或是最近習得的新技術，都是成員們口中談論的話題。有時討論狀況過於熱烈時，興致一來還會當場架起投影機及錄影設備開始進行實作分享。除此之外，成員們還會一起開發開源專案，從歷史來說，H4 聚會就是先從開發討論開始，漸漸演變成現在十幾個人的固定社群聚會。

起初 Mat 和 Thinker 兩個人於 Tossug 社群聚會中結識，大約從 2009 年 4 月開始，因為想要一起做專案，於是另外相約在星期四碰面討論，後來經由社群朋友的口耳相傳，漸漸有愈來愈多人來共同參與。而在 Mat 的努力奔走維繫之下，聚會的人數得以維持在一定的水準，其後，參與 H4 聚會也就成為國內開源專案的開發者，在星期四下班後的另一個選擇。

或許是因為對於寫程式有一股莫名的熱忱，H4 的成員往往會將程式融入到生活中，遇到無法決定的大小事都會想要用程式來解決。例如要決定每個人分享的順序或是遇到要抽籤的時候，就會有人主動開始寫程式，用程式亂數產生的結果來決定分享的順序或選出籤王是誰。還有一次因為聚會地點沒有定論，也是透過分析程式，將每個人住家的經緯度輸入去計算，找出對每個人來說最方便的最佳解。另外，對於重複的、不需動腦的例行公事，H4 成員也都交由機器人來代勞，寫了一支機器人程式，在論壇上固定發送聚會通知，以最省力且有效率的方式達成目的。

除了將程式帶進自己的實際生活外，對於技術面的公共事務 H4 的成員也展現出十足的熱情。不難發現他們經常在各大論壇上出沒，有人提出技術相關的疑惑時，他們就會跳出來幫這些疑難雜症找出解答，將程式的 source code 挖出來研究，找到問題所在，並將相關的 Bug 修改好。也因為看到 H4 成員對於開發的投入及寫程式的熱情，不乏國內廠商紛紛主動提供外包案或工作職缺的資訊到 H4 論壇上，不僅如此，H4 輕鬆自在又能提升實力的聚會模式也被社群朋友帶到香港，今年 5 月香港的開發者成立了 Hacking Thursday Hong Kong－駭能工程，並在其官方部落格上聲明舉辦開發者聚會的點子是源自台灣 Hacking Thursday 聚會，從這個範例看來，在許多方面 H4 聚會都已經受到各界的認同與肯定。

▲ H4 聚會平常歡樂討論的情形

其實有很多參與 H4 的社群朋友都不是資訊相關領域的本科生，H4 雖然是開發者的聚會，但是也有不少創投、自由工作者、藝術家等以寫程式為興趣的開發者共同參與。H4 的成員把寫程式當成一種興趣，有不少人是靠著自學的方式投入開發的行列。成員 FourDollars 說：「對寫程式有沒有熱忱看眼神就知道了，熱愛寫程式的開發者在談論技術時，眼睛會發亮，並且散發出專注、狂熱的感覺！」

撇去白天上班的緊繃壓力，晚上在 H4 與朋友研究、交流新技術與新發現，開玩笑時可以放肆大笑，研究技術時可以認真投入，對什麼專案有興趣就找志同道合的朋友合作開發！對於 H4 成員來說，聚會不僅是個可以放鬆和增進能力的地方，還是一個認識朋友結交知己的場所，在這樣互相合作進步的動力驅使之下，不但能激發參與者更多創意點子，更能找到協力開發程式的樂趣與能量。

Hacking Thursday 官方網站：
http://hackingthursday.wikidot.com/

Hacking Thursday Google 網上論壇：http://groups.google.com/group/hackingthursday?hl=zh-TW