Posts Tagged ‘OpenFoundry’

0711, 0712 工作坊 CakePHP 課程

星期日, 七月 12th, 2009

在課程開始前自己有針對課程做了個劇本,原本還擔心這個劇本無法支撐 6 個小時的課程,但經過這兩天實際進行後才發現,我擔心太多了,因為很多劇本以外的狀況,而即使那些狀況都不發生,把那些東西一股腦的塞給來參與的朋友似乎也太多了,因為大部分人對於 CakePHP 都僅是粗淺的認識,也有部份朋友對 PHP 並不是那麼熟悉,所以一直在調整自己的腳步,在第一天就顯得有些渾亂,第二天好一些。

在這兩天開始時都是針對基礎環境的建置做介紹,目的是希望參與的朋友回到家都能夠重建這些環境進行練習,所以上午的步調都明顯緩慢些;在電腦教室的環境也是有許多狀況,因為使用 xampp 的隨身版本,發現它對於環境的兼容性不是很好,而部份電腦因為已經裝過 xampp 的安裝版本,設定也出現混淆的情況,當然,也有些沒有跟著步調進行而出現的設定錯誤或是意外狀況,所以第一天在上午只有把環境建置完成,並且丟了個 hello world 。第二天因為有了些經驗,雖然也是狀況不斷,但進度比較穩定些,上午課程結束時已經完成了第一個範例的實做。

第一天下午只把單一資料表的存取、查詢等功能完成,進一步要介紹檔案上傳的處理時,發現時間已經差不多了,所以就直接打斷,進入 Q&A 的時間;第二天則是調整方向,略過檔案上傳的處理,直接切入兩個資料表的關聯處理,進一步的作到關聯資料編輯流程的修正,算是比較像樣些。在第一天的人數與問答比較多一些,第二天就相對沉默,可能也是人少一點吧。

課程的進行方式就是一步一步推進,我進行一些操作,藉著請參與的朋友在自己電腦進行同樣操作,在後面的實做部份也另外透過 ftp 方式讓所有人可以直接存取我所展示的程式碼,減少因為程式碼繕打所需要的時間。只不過因為程式碼都是現場輸入,所以沒有針對程式碼的細節多做說明,只希望有心的朋友可以拿著疑問去比對官方手冊,畢竟 6 小時要吸收這些東西是有點痛苦。依據過去的經驗,過度著重在概念的陳述時會發現下面朋友持續點頭或兩眼無神的情況,所以這一次大量的進行實務操作,但也相對的在概念的建立上就顯得薄弱,這算是兩難吧。

比較對不起參與朋友的地方是,我沒能夠有太多的前置時間做準備,上個星期還去高等法院洗了個三溫暖,所以準備的部份確實不足,只能希望這兩天參與的朋友能夠有一個開始的印象,藉此作為繼續深入的起點。 ;)

環境建置對於這種短暫的教學活動確實會有不小的影響,有朋友建議使用 VM 建置基本環境,讓教學活動可以聚焦在必要的操作之上,也許未來還有機會時可以透過這樣的形式。這兩天最大的遺憾是有不少朋友報名了卻未前來,這也是在台北辦活動的一個難處,台北人太忙了,所以經常沒辦法照著行程走,降低一些活動舉辦的意願。

這兩天的課程也需要感謝 Openfoundry 提供的機會以及 Freddi 細心的安排與為兩天活動的紀錄開了個頭,有興趣的朋友可以參考:
http://of.openfoundry.org/kwiki/ossfworkshop/index.cgi?WorkShop-0711
http://of.openfoundry.org/kwiki/ossfworkshop/index.cgi?WorkShop-071112

James 也針對第一天上午的環境建置提供了紀錄:
http://code.google.com/p/zf-tw/wiki/SettingUpCakePHPEnv

如果時間允許,也許會找時間做些整理吧;總之,這兩天的活動結束了,好好睡覺去 ;)

給 OpenFoundry 的建議

星期六, 二月 7th, 2009

昨晚跟 Freddi 與 KC 碰面,聊的是 OpenFoundry 的推廣活動,在討論過程中有提到過去跟 OpenFoundry 的一些互動,不過時間太久所以印象模糊了些,於是剛剛就找了一下。

是從這篇文章的評論開始的:
http://kiang.blogspot.com/2004/07/20040711.html

OpenFoundry 是由 RT, Kwiki, Sympa, SVK 等工具組成,早期透過 Perl 設計一個整合式的 UI ,現在是使用 Ruby 。在當時看到 autrijus 的評論後,我就試著去翻譯 gforge ,翻譯的成果在 OpenFoundry 網站上都還找的到,只是很久沒有更新:
http://of.openfoundry.org/projects/161/download

不過 OpenFoundry 並沒有採用,只是一直用自己的方式試著把一些工具組合在一起,因此穩定度、畫面整合等問題似乎到了今天還是沒有根本的解決,所以我還是強烈建議他們改採用 gforge ,或是可以選擇類似 sourceforge.net 最近的作法,提供一些常見的應用給專案開發者,像是 Trac ,他們也有將修改的部份公開來:
http://sourceforge.net/project/showfiles.php?group_id=238161&package_id=289462

OpenFoundry 所選擇的應用程式不是不好,而是需要花許多的功夫進行整合,而 GForge 已經整合好了,為什麼不用? GForge 是基於 Sourceforge 早期釋出的版本進行延伸,因此熟悉 Sourceforge 操作的人對於 GForge 並不會感到陌生,它的安裝相信不會比起開發一個整合介面要難。

就算喜歡使用 Ruby 開發,那為何不選擇使用 Redmine ( http://www.redmine.org/ ),它實作了 Trac 上看的到的功能,還進一步支援多專案等功能,連 Git 都支援了…

上面是針對平台的建議,再來是針對推廣工作。

OpenFoundry 在開放原始碼軟體的推廣工作往往受限於年度計劃方向、執行者的目的(論文?)或是排斥商業行為的習慣,引來了不少的抱怨。

在昨晚的討論中有提到,為什麼不先將焦點放在一些能夠產生良性循環的專案上面?以 CRM 為例,想要使用這方面軟體的公司不少,如果針對這個軟體進行一系列的說明、教學等活動,擴大使用者社群後,自然願意在社群投注資源的企業就會變多,資源多了自然就可以吸引開發者,開發者如果能夠專注於開放原始碼的創作而不需要顧慮經濟問題,相信這個社群會進入所謂的良性循環。

但是目前看到的一些推廣工作,都是將大部分的焦點放在開發者,試著要培養更多的開發者,但是結果似乎永遠不如預期,為什麼?因為參與活動的人大多將獲得的知識放在自己的工作上面,也大多只對於跟現在或未來工作相關的主題感興趣,最後大概只有那種滿腔熱血的青年會跳出來做些事情,不過這樣的熱情大多燃燒不了多久,因為沒有適當的環境來延續這些熱情。

但過度商業化也不是一件好事,如果活動裏面介紹的都是些商業軟體,或是被調整過而且無法直接取得的軟體,相信效果也會大打折扣。

簡單的說,請將焦點集中在使用者社群,這樣的社群才有機會形成產業,產業出現了,就不用擔心開發者不夠的問題;把餅做大,而不是一直在消耗資源讓圈子越來越小。

好吧,如果真的那麼排斥商業,那不妨就先將焦點放在學校用的到的部份,像是 Moodle 或者國人自行開發的學務系統也好( http://x.tnc.edu.tw/ )。

已經有人在做?那為何不要一起做?團結不是應該力量大些嘛?