Another letter sent in Japan

發表於 2011 年 08 月 02 日 由 kiang

Hi, we, me and my wife, are coming from Taiwan and living in Osaka with working holiday visa(2011/06/22 ~ 2012/06/22). We are planing to move to Sapporo since the beginning of October.

Before checking the availabilities of rooms, just want to know if there’s any chance to decrease the budget with my skill. :)

I’m 30 years old, this is my first time and last time to have the chance to live in foreign country with working holiday visa. I have strong knowledge in PHP, the programming language behind the website you are using. I do familiar with some computer proper nouns, like linux, apache, mysql and php. One proof is that I’m the founder of Taiwan PHP User Group( http://twpug.net ), the website was founded since 2002. And I own a small company in Taiwan that provides services around PHP( http://olc.tw/ ), including programming and consulting, the company was founded since 2009/01. We are working on some contracts with international companies, the famous one is TrendMicro.

I believe I’m able to bring you some office automation systems based on your demands. Or maybe just share some loading in maintaining this website.

I don’t know most about Japanese language. Just have some basic English abilities and very good at Chinese, of course.

Hope this message won’t bother anyone. Thanks for being patient in reading. :)

發表於 post | 已標籤 , | 迴響已關閉

Looking for contract jobs related to CakePHP in Japan, a guy from Taiwan

發表於 2011 年 01 月 29 日 由 kiang
We, me and my wife, are planing to have working holiday visa in Japan start from June this year. It means that we will live in Japan for one year start from June and we are able to work there legally during living. Although it may have some risks that one or both of us are not able to get the visa(Hope the risks won’t heppened…^^||)

I’m a freelancer working for customers to customize or develop applications using PHP. Most of my contracts are related to CakePHP now and some of the customers are located in U.S. The contracts won’t be terminated even if I stay in Japan. So it’s a little bit hard for me to find a full time job during the one year. And another reason is my Japanese skill is very poor. But I really long to find at least one contract in Japan to have some interactions with people there. That’s why I try to post the information here. ;)

I was a PHP developer since 2004 and founded TWPUG( http://twpug.net ) in the same year. I should have necessary skills to develop most kinds of applications using PHP, it would be great to keep using CakePHP. The biggest issue is that all the conversations must be using English or Chinese. ( My English is poor, too. But should be better than Japanese. ) I know it’s hard in such conditions. But it should be great if you are trying to have your website in English and Chinese.

We haven’t decided where to live, although Tokyo and Osaka are current candidates since we used to live there in the past for traveling. We would love to talk about more possibilities base on requests from customers. Tokyo would be the best one since most events related to technologies I knew were hold there. I hope I could attend some of them during the one year living. But it’s not required.

If your company have branch in Taiwan, I would love to have some talks with people there to confirm if I’m qualified for your demands.
發表於 商業消息 | 已標籤 | 迴響已關閉

另一個正在 WebERP 專案發生的故事

發表於 2011 年 01 月 06 日 由 kiang
首先，我並不是非常深入這個故事的始末，只是就一個旁觀者的角度去說明這個情況，我想應該會有很多盲點，誤解的地方就當作是一個美麗的錯誤吧 ;)

Phil 是 WebERP 的原始開發者，而 Tim 是後來加入了這個專案，不確定整個團隊的貢獻度比例怎麼分配，但是在 Tim 加入後這個專案確實變得活躍許多，他會很快的回覆問題、修改錯誤以及加入新功能，這正是開放原始碼專案所期待的夥伴。只是隨著時間久了，就像夫妻一樣，總是會出現些嫌隙。 Phil 發現 Tim 雖然很積極，但是總會有些不按牌理出牌的情況，遺留了許多問題，讓他覺得自己好像跟在後面擦屁股一樣。而 Tim 可能覺得自己的貢獻度越來越高，希望其他夥伴能夠照著他的想法走，隨之而來的就是領導的衝突出現，兩個人的衝突愈來愈多，而且也慢慢浮上檯面。

Phil 針對一個功能模組提出了異議，這個模組應該是由 Tim 所貢獻。Phil 提到這個模組有很多的問題存在，他質疑這個模組完成度不高，不應該放在專案中，他希望能夠重新改寫該功能。Phil 同時在公開的信中強調，希望加入專案中的功能能夠多些測試，能夠根據他過去所訂下的一些規則進行開發工作。Tim 隨即表示那個功能已經有很多人在使用(應該是他的客戶)，應該要試著修補它，而不是立即決定改寫。他覺得 Phil 自作主張的認定程式碼品質，沒有去深入產生那些程式碼背後的需求背景。

Phil 沒有直接回應，他接著將問題放上了 wiki ，還是強烈的表達了希望用改寫的方式來取代這個功能。 Tim 接著表達，專案有著版本控制系統，因此加入些實驗性的功能並不會造成太大的問題，而且新模組造成的問題並不會那麼樣難以修正。接著兩個人就開始把累積的不滿持續提出，互相糾正彼此的觀念。基本上都還是針對專案的程式，只是人的情緒來了，那個話就容易出現語病，然後就產生更多的誤解，以及更多的情緒 ;)

在一陣衝突後， Tim 決定離開這個專案，他同時表示 Phil 太過獨斷獨行。Phil 在移除了 Tim 的權限後，將這個問題的始末放上了 wiki 。

這樣的故事似乎一再的在開放原始碼專案上演，當專案出現了兩個人想要主導著不同的方向，專案就會開始分裂。這其實很正常吧，連恩愛的夫妻都會離婚了，更何況是相隔兩地且彼此沒碰過面的兩個人。只是有點好奇，在 Ruby 與 Python 社群中，最近聽到的反而是分別有兩個規模不小的專案決定合併( Rails3 & Merb, TurboGears & Pylons)，不知道這個合併的過程，開發者們是如何克服類似的衝突，又或者其實合併以後反而讓一些無法適應的開發者另外開始新的方向？

# Phil 對於問題始末的記錄 http://www.weberp.org/TimSchofieldDisagreement
# Tim 的新專案 https://launchpad.net/web-erp/
發表於 胡言亂語 | 已標籤 | 迴響已關閉

談專業工作

發表於 2010 年 09 月 12 日 由 kiang

恩，其實我忙翻了，但是人在忙的時候總是會發生很多意外，所以就聊聊意外…

昨天早上機車發不動了，所以就牽去機車行修理，機車行的師傅在檢查後判斷是油杯故障，於是就換了油杯，然後機車就真的可以發動了，可是感覺怪怪的。師傅說 OK ，所以我就騎走了，想說會不會一陣子就好了，但是愈騎越覺得怪，怎麼還沒摧油門機車就會往前跑，讓我在停下來的時候都得緊握煞車讓它熄火，等能夠移動的時候才重新啟動，於是我繞回去問那個師傅，他檢查也沒有就告訴我化油器有問題，他表示之前就有發現，不過他表達的意思好像是不修也可以，就是得忍受些不正常的情況，我就沒當一回事騎走了。

騎了 2~3 公里後，車子又沒辦法發動了，於是我就成了俗稱的顧路邊，打電話給那個機車行來幫忙"推"回去；機車行的師傅似乎都必備這樣的能耐，就是騎機車時靠一隻腳推動另外一台機車，我只要控制方向跟煞車就可以。

回到機車行，由剛剛幫忙推車的師傅(另一個)重新檢查，不過他還是開啟同樣的地方，似乎發現一些管線沒有接好，導致鬆脫後無法發動。這個師傅說我的機車使用了其他型號的化油器，也覺得是化油器有問題。第三個師傅靠了過來，表示車輪無法倒退，離合器應該有點問題，第三個師傅為第一個師傅護航了一下，表示這樣的情況難免啊之類的，然後說他們不會隨便換零件，一定要我這邊決定了才會去修其他地方，否則就是根據當下發現的問題處理。

其實我已經沒什麼信心在這個機車行修理了，所以在他們把管線接好後，雖然機車還是一樣會沒辦法停下，我還是勉強騎到了另一個機車行，然後直接告訴他離合器有問題，他在測試了輪胎後也認同我的判斷，於是開始幫忙拆解離合器週邊的零件。拆開來後竟然發現，離合器斷裂，這應該算是蠻危險的事情，因為斷裂的零件有可能造成機車行進間鎖死而發生意外，但是前一個機車行居然讓我就這麼離開而不願意做些檢查動作，我只能說還好我在路上沒有發生意外…

其實想想，軟體開發中也偶爾會發生類似的情形，因為每天接觸而形成習慣，加上對自我專業的信任，許多時候即使可以想到很多可能性，但是總只會選擇一兩個作為切入點去檢驗是否有問題，當這一兩個切入點的問題排除後，就以為所有問題都被排除了，即使已經有了非常明顯的徵兆指出其他可能性需要確認，往往缺乏這樣的耐性繼續去進行問題的排除，然後就等意外發生。

因為身邊的人也是一樣的態度，所以不太容易扭轉已經做出的決定，於是客戶的意見就被忽略或淡化了。這個潛在的後顧之憂，幸運的可以在行程寬鬆時偶然發現，然後頂多心理捏了一把冷汗；但是萬一跟其他的意外一起發生，悲劇就這麼造成了。

從這個角度看，也許在客戶與技術人員間有個非技術人員作為緩衝是件好事，可以多一個角度去檢驗問題。只是在台灣，包括上面提到的機車行以及我們這種小公司的軟體技術人員，往往基於成本的考量而省去中間的緩衝，在需求持續增加時就會發現問題越來越嚴重，而且陷入深淵的公司經常看不透到底問題發生在哪裡，然後就慢慢走下坡。

這個世界當然不會只有一個可能，只是一個意外的發生總會讓人有些省思，希望我這個陷入深淵的人可以早點看懂爬出來的方式 ;)

發表於 post | 迴響已關閉

這是個測試，沒想到 WordPress 也可以做這種事情，真是越來越強大了啊~~…

發表於 2010 年 08 月 31 日 由 kiang

這是個測試，沒想到 WordPress 也可以做這種事情，真是越來越強大了啊~~~

發表於 status | 3 則迴響

又遇到了詐騙電話(錄音)

發表於 2010 年 03 月 13 日 由 kiang

詐騙過程的資訊已經送到了 http://165.gov.tw/case_tell.aspx (感謝 sjh 提供 ;) )

補上一個錄音檔案 ^^

20100313_2012

發表於 胡言亂語 | 迴響已關閉

我遇到了好人，遇到了壞人

發表於 2010 年 02 月 25 日 由 kiang

我遇到了好人，在生活中遇到了突發的狀況，經由朋友的介紹，我們獲得了一些專業的朋友協助。在討論問題的過程中，我們也相當相信他們的專業，因此把問題托付給他們。因為他們是好人，所以我們對他們的決定沒有太多懷疑，儘管關切的親友有提到一些疑問，我們都為他們找到理由、藉口回應，讓關切的親友也相信他們是好人。也許是他們在忙、他們應該有專業的考量、我們應該相信他們，因為他們是好人，我們沒有太多的懷疑，狀況處理的過程都照著他們的指示進行，也順利了度過了第一個難關。

悲劇總是接連發生的意外所造成，第一個難關之後延伸了更棘手的第二關，因為他們是好人，我們還是請他們協助，也儘可能的提供我們所能夠提供的資訊。因為他們是好人，有很多人相信他們，所以他們變得很忙，第二關儘管比較棘手，他們也有些力不從心，因為我們相信他們是好人，所以他們也繼續當好人，只是過程中沒辦法提供更多的協助，儘管我們提到希望投入更多的資源來取得他們更多的協助，他們並沒有接受，因為他們是好人，他們也相信能夠以有限的資源進行處理，我們也相信他們，然後他們繼續當我們的好人。

悲劇的意思就是沒有歡喜的結果，我們在第二關慘遭滑鐵盧，發現很大的原因是他們在協助第一關時留下了隱憂，而這樣的隱憂在第二關變成了致命的關鍵，我們事後才知道這個隱憂的存在，而這個隱憂如果當初沒有急著在第一關畫下句點，我們也許可以有充份的討論來避開它，當時我們佔盡優勢。因為他們是好人，我們在處理過程中忽略了應該有的警戒心，因此需要面對嚴重的後果。我們還是相信他們是好人，但是對於這樣的後果我們無法自行承擔，因此在長時間的討論後，我們決定要求他們分擔其中的損失，但這時候他們也抗議了，抗議我們沒有交代清楚資訊、抗議我們別有居心、抗議我們相信他們是好人。很遺憾的，那些說是沒有交代的資訊，我們在口頭提到時沒有錄音記錄，但我們確實有提過，因為我們是第一次面對這樣的問題，深怕有任何不測，所以過程的任何細節我們都有深刻的印象，我們也沒有能力去思考其他的意圖。

遇到好人還是會面對這樣的結果，最悲哀的是，我們需要跟好人在爭辯的過程中承擔這個後果，那個壞人繼續耀武揚威。

我遇到了壞人，因為在第一關時他們不願意積極處理問題，讓我們需要求助於好人。因為他們是壞人，在第一關有明顯的缺失存在，但是他們一直不承認自己有錯，甚至找了其他的壞人編織故事想要讓我們耽誤問題處理的時間。因為他們是壞人，我們不相信他們，所以有看出他們的意圖以及注意到問題的時效性，我們及時找到了好人幫忙處理，壞人自然就被打敗了。

因為他們是壞人，第二關也是拒絕配合，而且還更進一步的透過各種方式進行騷擾。因為他們是壞人，所以各種騷擾都遊走在法律的邊緣，簡訊、電話或是到住家叫囂，即使請警方協助處理，警方也表示莫可耐何，我們只能繼續提防他們這些壞人。第二關一度是我們佔上風時，壞人情緒化的程度加深，開始有了超過法律邊緣的舉動，可惜沒有來的及進行蒐證，所以他們還是可以繼續當幸運的壞人。

最後，第二關我們輸了，他們竟然還是繼續騷擾。因為騷擾的過程警察也幫不上忙，於是我們將這個過程寄給壞人的父親，請他轉達不要再做這種傻事。壞人在得知後反而變本加厲，這時候我們已經準備好各種蒐證工具，他們也的確踰越了法律的界線，我們將所有的資料送交警方處理，希望給他們一些警惕。因為他們是壞人，我們在處理時可以保持警覺，可以毫不猶豫的透過各種方式懲罰他們。

生命的過程似乎總會遇到些好人、壞人，但有時候換個角度看，好人不一定好、壞人不一定壞，投入過多的情感會讓好與壞之間失去界線，但是沒有情感好像也不像個人。儘管人生充滿矛盾，我們還是得繼續走下去。下一關我們得面對好人跟壞人，祝福我們吧。

發表於 胡言亂語 | 2 則迴響

激情過後，在下一個莫拉克來臨前

發表於 2010 年 01 月 05 日 由 kiang
莫拉克颱風於 2009年8月7日於23時50分由台灣花蓮縣登陸，8月8日14時由桃園縣出海，是台灣氣象史上傷亡最慘重的侵台颱風。這次風災也或許是資訊最混亂的一次，或該說是資訊技術參與救災最廣的一次，因為陸續有多個自願者架設了彙集資訊的網站，主要是讓受災民眾可以透過網路發出求救的聲音，或是由網友提供各種相關資訊，顛覆了以往只能等待政府、媒體提供資訊的型態，而且參與人數以及程度都可說是空前。
因為這些網站都沒有足夠的時間進行規劃，因此陸續出現了下面問題：
1. 短時間內產生的資料量過大，網站無法負荷而頻頻當機
2. 進入系統的資訊過多，剛開始時沒有組織人力進行即時的過濾與處理
3. 發佈的災情資訊不易追蹤，導致救災資源的重置或浪費
4. 有心人士利用系統進行各種非相關資訊的宣傳，或是試圖攻擊系統
5. 缺乏政府相關單位的支援，導致部份資訊沒有獲得應有的重視
6. 多個網站間資訊有重複、不同步的問題，讓資訊更難以掌控
7. 過多的資訊引發恐慌、焦慮等心理影響
8. 大部分的資訊都是匿名發佈，不容易辨識真偽
接著開始有許多自發性的救災活動透過上述網站進行人員、資源募集，透過新聞媒體得知一些狀況發生：
1. 志工未經妥善安排，導致與政府救災機制產生衝突
2. 非營利組織之間資訊難以交流，導致受災民眾需要填寫大量的資料來確認受災身份，也有資源重置情形
3. 各種救災物資送錯地方，有災民收到不需要的資源、有災民一直等不到資源
4. 政府的注意力隨著媒體前進，許多媒體並未注意到的災區政府缺乏即時的因應機制
5. 開始有投機性的災民或是一般民眾利用錯誤的資訊來圖利自己
在災害慢慢趨緩後，似乎也沒看到對這些資訊的整理、統計、分析工作進行，畢竟下一個災害來臨前，我們需要這些經驗來進行災害的防治工作。
今天上午有跟蕭博士碰面討論，他們打算以 Sahana 為基礎去延伸救災資訊所需工具。他提到，目前許多廠商積極爭取政府單位的救災系統建置計劃，只希望這些計劃未來能夠透過標準格式產出相關資訊，讓 Sahana 可以運用；而他們對 Sahana 這個系統的期望是能夠整合不同非營利組織的資訊，以及管理來自各種社交網站或個人發佈的訊息，最後與政府的系統進行資訊交換，讓救災工作能夠順利進行。不過 Sahana 目前的狀態並沒辦法立即滿足這些需求，需要爭取相關預算來進行在地化的調整。
對 Sahana 還不是很熟悉，僅就少數的觀察歸納出3個需求：
1. 能夠承載高流量的問題回報系統
在災害發生當時，如果沒有影響到網路基礎建設，會有許多的資訊透過網路發出，這個系統的主要工作就是取得與過濾這些資訊，而且維持穩定運作。特別需要加強過濾功能，除了透過技術進行辨識外，也要保有外部志工參與人工過濾的機制，像是問題新增同時指派志工處理，處理過程持續更新、合併重複資料等等。
2. 能夠管理災民、物資、志工的資源管理系統
在救災團體進入到災區後，需要有這樣的資訊系統輔助相關工作進行，這個系統的訴求是完整性，像是下面幾個例子：
[1]災民從登記、安頓、配發物資到脫離庇護的流程
[2]物資從登記、運輸、倉儲、配發到物資使用的教育等等
[3]志工從報名、集合、裝備配發、任務發派、心理輔導的安排到解散的流程
[4]罹難者的登記、攝影、辨識到遺體的處置登記等
3. 能夠將任務分派到手持式設備的資訊系統
人的記性有限，隨時帶著電腦進行救災工作也是有些難度，因此將任務資訊濃縮後放入手持式系統有一定的方便性存在，甚至可以進一步做到任務異動、取消的通知，避免救災人力的浪費。
上面提到的都是片面的想法，一定會有缺漏、錯誤的地方，目的只是希望拋磚引玉，讓更多人能夠協助促成這樣的救災資訊架構能夠成型，而且實際為需要的人們帶來幫助。
最後是一些災情通報網站的現況：
莫拉克颱風急資集散網 – http://lingtelli.org/savetaiwan
2010/01/05 17:00 無法連結
莫拉克災情資料表 – http://typhoon.oooo.tw/
2010/01/05 17:00 持續營運中
莫拉克颱風災情支援網 – http://disastertw.com/helps
2010/01/05 17:00 已經不存在
高雄縣社會處災情公告 – http://www.sw.kscg.gov.tw/index.php?html=cal_show.php
2010/01/05 17:00 在 1/4 有提供最新的捐款名冊
莫拉克災情網路中心 – http://typhoon.adct.org.tw/
2010/01/05 17:00 在 1:03 PM Oct 6th, 2009 後就沒有更新了
莫拉克災情資訊平台 – http://morakot.yam.com/
2010/01/05 17:00 在 2009-10-25 18:07 後就沒有更新了

莫拉克颱風於 2009年8月7日於23時50分由台灣花蓮縣登陸，8月8日14時由桃園縣出海，是台灣氣象史上傷亡最慘重的侵台颱風。這次風災也或許是資訊最混亂的一次，或該說是資訊技術參與救災最廣的一次，因為陸續有多個自願者架設了彙集資訊的網站，主要是讓受災民眾可以透過網路發出求救的聲音，或是由網友提供各種相關資訊，顛覆了以往只能等待政府、媒體提供資訊的型態，而且參與人數以及程度都可說是空前。

因為這些網站都沒有足夠的時間進行規劃，因此陸續出現了下面問題：

1. 短時間內產生的資料量過大，網站無法負荷而頻頻當機

2. 進入系統的資訊過多，剛開始時沒有組織人力進行即時的過濾與處理

3. 發佈的災情資訊不易追蹤，導致救災資源的重置或浪費

4. 有心人士利用系統進行各種非相關資訊的宣傳，或是試圖攻擊系統

5. 缺乏政府相關單位的支援，導致部份資訊沒有獲得應有的重視

6. 多個網站間資訊有重複、不同步的問題，讓資訊更難以掌控

7. 過多的資訊引發恐慌、焦慮等心理影響

8. 大部分的資訊都是匿名發佈，不容易辨識真偽

接著開始有許多自發性的救災活動透過上述網站進行人員、資源募集，透過新聞媒體得知一些狀況發生：

1. 志工未經妥善安排，導致與政府救災機制產生衝突

2. 非營利組織之間資訊難以交流，導致受災民眾需要填寫大量的資料來確認受災身份，也有資源重置情形

3. 各種救災物資送錯地方，有災民收到不需要的資源、有災民一直等不到資源

4. 政府的注意力隨著媒體前進，許多媒體並未注意到的災區政府缺乏即時的因應機制

5. 開始有投機性的災民或是一般民眾利用錯誤的資訊來圖利自己

在災害慢慢趨緩後，似乎也沒看到對這些資訊的整理、統計、分析工作進行，畢竟下一個災害來臨前，我們需要這些經驗來進行災害的防治工作。

今天上午有跟蕭博士碰面討論，他們打算以 Sahana 為基礎去延伸救災資訊所需工具。他提到，目前許多廠商積極爭取政府單位的救災系統建置計劃，只希望這些計劃未來能夠透過標準格式產出相關資訊，讓 Sahana 可以運用；而他們對 Sahana 這個系統的期望是能夠整合不同非營利組織的資訊，以及管理來自各種社交網站或個人發佈的訊息，最後與政府的系統進行資訊交換，讓救災工作能夠順利進行。不過 Sahana 目前的狀態並沒辦法立即滿足這些需求，需要爭取相關預算來進行在地化的調整。

對 Sahana 還不是很熟悉，僅就少數的觀察歸納出3個需求：

1. 能夠承載高流量的問題回報系統

在災害發生當時，如果沒有影響到網路基礎建設，會有許多的資訊透過網路發出，這個系統的主要工作就是取得與過濾這些資訊，而且維持穩定運作。特別需要加強過濾功能，除了透過技術進行辨識外，也要保有外部志工參與人工過濾的機制，像是問題新增同時指派志工處理，處理過程持續更新、合併重複資料等等。

2. 能夠管理災民、物資、志工的資源管理系統

在救災團體進入到災區後，需要有這樣的資訊系統輔助相關工作進行，這個系統的訴求是完整性，像是下面幾個例子：

[1]災民從登記、安頓、配發物資到脫離庇護的流程

[2]物資從登記、運輸、倉儲、配發到物資使用的教育等等

[3]志工從報名、集合、裝備配發、任務發派、心理輔導的安排到解散的流程

[4]罹難者的登記、攝影、辨識到遺體的處置登記等

3. 能夠將任務分派到手持式設備的資訊系統

人的記性有限，隨時帶著電腦進行救災工作也是有些難度，因此將任務資訊濃縮後放入手持式系統有一定的方便性存在，甚至可以進一步做到任務異動、取消的通知，避免救災人力的浪費。

上面提到的都是片面的想法，一定會有缺漏、錯誤的地方，目的只是希望拋磚引玉，讓更多人能夠協助促成這樣的救災資訊架構能夠成型，而且實際為需要的人們帶來幫助。

最後是一些災情通報網站的現況：

莫拉克颱風急資集散網 – http://lingtelli.org/savetaiwan

2010/01/05 17:00 無法連結

莫拉克災情資料表 – http://typhoon.oooo.tw/

2010/01/05 17:00 持續營運中

莫拉克颱風災情支援網 – http://disastertw.com/helps

2010/01/05 17:00 已經不存在

高雄縣社會處災情公告 – http://www.sw.kscg.gov.tw/index.php?html=cal_show.php

2010/01/05 17:00 在 1/4 有提供最新的捐款名冊

莫拉克災情網路中心 – http://typhoon.adct.org.tw/

2010/01/05 17:00 在 1:03 PM Oct 6th, 2009 後就沒有更新了

莫拉克災情資訊平台 – http://morakot.yam.com/

2010/01/05 17:00 在 2009-10-25 18:07 後就沒有更新了

發表於 胡言亂語 | 迴響已關閉

XOOPS 控告過去的專案負責人 Herko Coomans

發表於 2009 年 12 月 23 日 由 kiang
不管怎麼說，這都是個難過的時刻，在一個組織、社群被迫要透過法律途徑對抗一個過去的負責人來找尋正義時。
很不幸的，這是目前 XOOPS 社群與 Herko Coomans[1] 之間的現況，他是過去的專案負責人以及位於荷蘭的 "Stichting XOOPS" 基金會負責人。 XOOPS 透過荷蘭 Zwolle-Lelystad 地方法院對他提出訴訟，要求他返還屬於 XOOPS 社群的基金 (大約 15,000 歐元)，這筆基金目前在 "Stichting XOOPS" 基金會名下。 XOOPS 由 Dorhout Advocaten[2] 代表
(社群聯署活動略過，有興趣可以參考原文[3])
為什麼會走到這一步？
1) Herko 在 August 2003 — March 2006 之間擔任專案負責人，在 2006/4/20 ，當時的專案負責人 Skalpa 提出質疑時，他同意辭去他的位置[4]。
2) Herko Coomans 在擔任專案負責人時，於 2004 提議成立 XOOPS 基金會，原本要設置在美國，但 Herko 抱怨太難以及太貴(當然，這完全不正確)，他在取信於 XOOPS 社群後將它以 "Stichting XOOPS" 名義登記在荷蘭，也就是他居住的國家。
在 April 22, 2006 ， Herko Coomans 同意 XOOPS 專案不太可能正式選出負責人，他也同意開發團隊推薦決策成員不會有任何問題，因此在章程中加入了這個推薦並且確保它的合理。他也了解決策團隊與社群可以決定他是否能夠繼續擔任 Stichting XOOPS 的負責人，而 Stichting XOOPS 也必須要向開發團隊與社群提供報告。
3) Stichting XOOPS 發佈了 2005[5] 與 2006[6] 年報
在 2007 年決策成員被換成了 Marc-André Lanciault (Marcan) 與 David Ledbury (davidl2)
4) 在 2007 秋天，當社群開始要求 XOOPS 的財務報表，得到的都是 Herko 的空頭支票[7]，而我們所不知道的是 Marcan, David 與 Herko 開始策劃要對抗 XOOPS[8]，其中也包括了幾個月前霸佔了 XOOPS 伺服器的 James Morris[9]，當時是取得了來自 XOOPS 創始人 Onokazu 與主機商的協助才順利取回控制權。由於策劃對付 XOOPS, Marcan, David, 與 Herko 很明顯的違反了他們在身為 Stichting XOOPS 負責人所被托付的職責，這是相當充份的理由來將他們解職。
當遭遇反抗[10]時， Marcan 表示因為興趣不合而選擇辭職[10]
5) Marcan 在 December 2007 辭職後， David Ledbury 也接著在 January 2008 辭去決策團隊的身份，不過 Herko Coomans 拒絕辭職。
6) 在 Spring 2008 ， Herko Coomans 出售 www.xoops.com 網址，並且將網址指向網域名稱銷售網站，要求的金額是 $500
7) 在這之後， XOOPS 理事會[12] (當時是 Phppp, Mamba, Kris_fr, Runeher, Irmtfan) 表決一致通過，將 Herko Coomans 在 Stichting XOOPS 的決策者身份移除
(略過關於理事會合法性的說明，有興趣可以參考原文[3])
理事會在 August 26, 2008 發信[13]給 Herko 表示，他們的意見是 Herko 違反了被托付的職責，
他們決定將 Herko 從 Stichting XOOPS 除名。理事會也同時聲名他不再能夠代表 XOOPS 進行任何財務決策，當時所有人仍然希望能夠和平解決來讓社群繼續走下去。
8) Herko Coomans 拒絕接受並且由他的律師做後續連繫，他的律師提出了下面解決方案：
A) Stichting Xoops 將會無償將下面項目轉移給 Xoops Foundation 基金會：
- www.xoops.com 這個網域名稱
- 所有跟這個網域名稱以及 XOOPS 相關的品牌智慧財產權
- 現有財務餘額，估計為 10,000 歐元
B) 在這些權力移轉後， Stichting Xoops 必須要解散
違反了上述任何一項協議， Herko 同意為個別協議的違反支付 5,000 歐元(摘譯)
9) 根據 Herko 在討論[14]以及當時的財務資料[15]，基金會在 August 2007 應該還有大約 16,000 歐元，因此在 Stichting XOOPS 帳戶應該還有超過 15,000 歐元。
只有交出 10,000 很明顯是有問題的，因此理事會僱用了律師進行協調，進一步取得了銀行帳戶餘額資訊，截至 Nov. 11,2008 的餘額是 13,485.25 歐元以及 $3,758 美金，美金帳戶接著被移轉到歐元帳戶中。理事會也在這之中得知，Herko 不想要讓人知道他運用了基金會的款項，以 4,000 歐元向他自己購買了 www.xoops.com 這個網域，所以基本上 Herko 決定了 Stichting XOOPS 將會支付這筆金額到他的口袋。這當然也是很清楚的利益衝突，理事會也清楚表示這是非法挪用，在 Stichting XOOPS 章程[16]第 6 項清楚提到：
e. 管理團隊同意任何活動都不要求報酬，不過他們被賦與權力，在執行任務所衍生的費用可以獲得補償。
Herko 在 September 2003 以 $18.95 採購了這個網域名稱，當時他是專案負責人，而當時 Mithrandir 在 June 23, 2005 的文章[17]可以看出他是代表 XOOPS 專案進行這項採購。David Ledbury 在同一天的文章也可以證實[18]。
Herko 在 Nov. 22, 2008 以 4,000 歐元將網域名稱賣給 Stichting XOOPS ，這是在理事會通知他被從 Stichting XOOPS 除名之後，當時也告知他不再被允許代表 Stichting XOOPS 進行任何財務決策。因為它是當時唯一能夠存取 Stichting XOOPS 帳戶的人，他提取了 4,000 歐元給他自己，這被視為是非法挪用，因為他應該只能夠獲得 $18.95 。
10) 理事會仍然希望和平解決，也已經提議只要他歸還這些款項，這些款項可以用來支付理事會的律師費用，以及他律師費用的一半，然後專案可以繼續前進。
11) 很不幸的， Herko Coomans 拒絕了這個方案，因此唯一的方法就是進入法律程序
[1] http://www.herkocoomans.net/
[2] http://www.dorhout.nl/
[3] http://www.xoops.org/modules/news/article.php?storyid=5170
[4] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=215096#forumpost215096
[5] http://www.xoops.org/uploads/foundation/2005YearReportXOOPSFoundation.pdf
[6] http://www.xoops.org/uploads/foundation/2006YearReportXOOPSFoundation.pdf
[7] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=271279#forumpost271279
[8] http://tinyurl.com/ycxlahd
[9] http://www.xoops.org/modules/news/article.php?storyid=3982
[10] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=279397#forumpost279397
[11] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=279433#forumpost279433
[12] http://www.xoops.org/modules/wfchannel/index.php?cid=17
[13] http://www.xoops.org/uploads/foundation/letterXoopsHerko2.pdf
[14] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=284098#forumpost284098
[15] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=284105#forumpost284105
[16] http://www.xoops.org/uploads/foundation/XOOPS_FoundationStatutes.pdf
[17] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=165567#forumpost165567
[18] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=165544#forumpost165544

不管怎麼說，這都是個難過的時刻，在一個組織、社群被迫要透過法律途徑對抗一個過去的負責人來找尋正義時。

很不幸的，這是目前 XOOPS 社群與 Herko Coomans[1] 之間的現況，他是過去的專案負責人以及位於荷蘭的 "Stichting XOOPS" 基金會負責人。 XOOPS 透過荷蘭 Zwolle-Lelystad 地方法院對他提出訴訟，要求他返還屬於 XOOPS 社群的基金 (大約 15,000 歐元)，這筆基金目前在 "Stichting XOOPS" 基金會名下。 XOOPS 由 Dorhout Advocaten[2] 代表

(社群聯署活動略過，有興趣可以參考原文[3])

為什麼會走到這一步？

1) Herko 在 August 2003 — March 2006 之間擔任專案負責人，在 2006/4/20 ，當時的專案負責人 Skalpa 提出質疑時，他同意辭去他的位置[4]。

2) Herko Coomans 在擔任專案負責人時，於 2004 提議成立 XOOPS 基金會，原本要設置在美國，但 Herko 抱怨太難以及太貴(當然，這完全不正確)，他在取信於 XOOPS 社群後將它以 "Stichting XOOPS" 名義登記在荷蘭，也就是他居住的國家。

在 April 22, 2006 ， Herko Coomans 同意 XOOPS 專案不太可能正式選出負責人，他也同意開發團隊推薦決策成員不會有任何問題，因此在章程中加入了這個推薦並且確保它的合理。他也了解決策團隊與社群可以決定他是否能夠繼續擔任 Stichting XOOPS 的負責人，而 Stichting XOOPS 也必須要向開發團隊與社群提供報告。

3) Stichting XOOPS 發佈了 2005[5] 與 2006[6] 年報

在 2007 年決策成員被換成了 Marc-André Lanciault (Marcan) 與 David Ledbury (davidl2)

4) 在 2007 秋天，當社群開始要求 XOOPS 的財務報表，得到的都是 Herko 的空頭支票[7]，而我們所不知道的是 Marcan, David 與 Herko 開始策劃要對抗 XOOPS[8]，其中也包括了幾個月前霸佔了 XOOPS 伺服器的 James Morris[9]，當時是取得了來自 XOOPS 創始人 Onokazu 與主機商的協助才順利取回控制權。由於策劃對付 XOOPS, Marcan, David, 與 Herko 很明顯的違反了他們在身為 Stichting XOOPS 負責人所被托付的職責，這是相當充份的理由來將他們解職。

當遭遇反抗[10]時， Marcan 表示因為興趣不合而選擇辭職[10]

5) Marcan 在 December 2007 辭職後， David Ledbury 也接著在 January 2008 辭去決策團隊的身份，不過 Herko Coomans 拒絕辭職。

6) 在 Spring 2008 ， Herko Coomans 出售 www.xoops.com 網址，並且將網址指向網域名稱銷售網站，要求的金額是 $500

7) 在這之後， XOOPS 理事會[12] (當時是 Phppp, Mamba, Kris_fr, Runeher, Irmtfan) 表決一致通過，將 Herko Coomans 在 Stichting XOOPS 的決策者身份移除

(略過關於理事會合法性的說明，有興趣可以參考原文[3])

理事會在 August 26, 2008 發信[13]給 Herko 表示，他們的意見是 Herko 違反了被托付的職責，

他們決定將 Herko 從 Stichting XOOPS 除名。理事會也同時聲名他不再能夠代表 XOOPS 進行任何財務決策，當時所有人仍然希望能夠和平解決來讓社群繼續走下去。

8) Herko Coomans 拒絕接受並且由他的律師做後續連繫，他的律師提出了下面解決方案：

A) Stichting Xoops 將會無償將下面項目轉移給 Xoops Foundation 基金會：

- www.xoops.com 這個網域名稱

- 所有跟這個網域名稱以及 XOOPS 相關的品牌智慧財產權

- 現有財務餘額，估計為 10,000 歐元

B) 在這些權力移轉後， Stichting Xoops 必須要解散

違反了上述任何一項協議， Herko 同意為個別協議的違反支付 5,000 歐元(摘譯)

9) 根據 Herko 在討論[14]以及當時的財務資料[15]，基金會在 August 2007 應該還有大約 16,000 歐元，因此在 Stichting XOOPS 帳戶應該還有超過 15,000 歐元。

只有交出 10,000 很明顯是有問題的，因此理事會僱用了律師進行協調，進一步取得了銀行帳戶餘額資訊，截至 Nov. 11,2008 的餘額是 13,485.25 歐元以及 $3,758 美金，美金帳戶接著被移轉到歐元帳戶中。理事會也在這之中得知，Herko 不想要讓人知道他運用了基金會的款項，以 4,000 歐元向他自己購買了 www.xoops.com 這個網域，所以基本上 Herko 決定了 Stichting XOOPS 將會支付這筆金額到他的口袋。這當然也是很清楚的利益衝突，理事會也清楚表示這是非法挪用，在 Stichting XOOPS 章程[16]第 6 項清楚提到：

e. 管理團隊同意任何活動都不要求報酬，不過他們被賦與權力，在執行任務所衍生的費用可以獲得補償。

Herko 在 September 2003 以 $18.95 採購了這個網域名稱，當時他是專案負責人，而當時 Mithrandir 在 June 23, 2005 的文章[17]可以看出他是代表 XOOPS 專案進行這項採購。David Ledbury 在同一天的文章也可以證實[18]。

Herko 在 Nov. 22, 2008 以 4,000 歐元將網域名稱賣給 Stichting XOOPS ，這是在理事會通知他被從 Stichting XOOPS 除名之後，當時也告知他不再被允許代表 Stichting XOOPS 進行任何財務決策。因為它是當時唯一能夠存取 Stichting XOOPS 帳戶的人，他提取了 4,000 歐元給他自己，這被視為是非法挪用，因為他應該只能夠獲得 $18.95 。

10) 理事會仍然希望和平解決，也已經提議只要他歸還這些款項，這些款項可以用來支付理事會的律師費用，以及他律師費用的一半，然後專案可以繼續前進。

11) 很不幸的， Herko Coomans 拒絕了這個方案，因此唯一的方法就是進入法律程序

[1] http://www.herkocoomans.net/

[2] http://www.dorhout.nl/

[3] http://www.xoops.org/modules/news/article.php?storyid=5170

[4] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=215096#forumpost215096

[5] http://www.xoops.org/uploads/foundation/2005YearReportXOOPSFoundation.pdf

[6] http://www.xoops.org/uploads/foundation/2006YearReportXOOPSFoundation.pdf

[7] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=271279#forumpost271279

[8] http://tinyurl.com/ycxlahd

[9] http://www.xoops.org/modules/news/article.php?storyid=3982

[10] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=279397#forumpost279397

[11] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=279433#forumpost279433

[12] http://www.xoops.org/modules/wfchannel/index.php?cid=17

[13] http://www.xoops.org/uploads/foundation/letterXoopsHerko2.pdf

[14] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=284098#forumpost284098

[15] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=284105#forumpost284105

[16] http://www.xoops.org/uploads/foundation/XOOPS_FoundationStatutes.pdf

[17] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=165567#forumpost165567

[18] http://www.xoops.org/modules/newbb/viewtopic.php?post_id=165544#forumpost165544

發表於 胡言亂語 | 迴響已關閉

教學回憶錄

發表於 2009 年 11 月 24 日 由 kiang
在 8/25 ~ 10/15 之間，跟幾個朋友進行了十次的 PHP 入門課程，在這前後也跟 OpenFoundry 合辦了下面工作坊：
1. 7/11, 7/12 – CakePHP 教學
2. 10/21 – CakePHP 入門
3. 10/22 – jQuery 入門
4. 10/24 – jQuery 與 CakePHP
5. 11/14 – 版本控制 – Subversion + Git svn
6. 11/17 – php 入門
11/13 開始也會跟中原大學的一個實驗室進行 PHP 入門的教學。
在這些過程中，有時候會遇到手邊工作比較忙的情況，有時候又會剛好在專案之間的空窗期，所以自己覺得品質不是很穩定；對於表現不佳的時候，會有些抱歉。
在這些課程中，對象都有著類似的情況，有些人已經很熟悉相關技術，也有些人完全沒有概念，每次準備教學時所假定的目標族群總是很難剛好涵蓋大部分人的情況。之前去日本時有跟 APC 開發者聊到，他覺得自己準備的東西好像很難讓一般人聽懂，也擔心會不會太過簡單而讓一些高手感到失望，我們最後有個結論，就針對自己最熟悉的部份去切入吧，自己的狀態總是比較好掌握的(不過當時我的主題比較簡單，不知道會不會害到他 ;) )。
因此，在課程的準備上，我使用的大多是自己比較熟悉的環境，對有些朋友而言可能是非常陌生的。而在內容的安排上，我把焦點放在實作過程，對一群人不停的從頭講到尾並不是我的專長，因此偶爾會有朋友反應，一些相關概念的說明也許不是那麼清楚，也許未來在這個部份需要做些努力。
CakePHP 的教學中，在環境設定上面經常花了比預期要多的時間，雖然後續改用 VirtualBox 搭配 Ubuntu 的方式進行，問題還是蠻多的。也許是操作過程太長，以畫面逐步說明的方式不容易記憶，應該要針對這個部份準備比較完整的講義。先前有跟出版社討論出版這個主題的書，不過後來開工作室忙了就沒辦法集中精神在這方面，如果接下來行程不會太緊湊(好像很難…)，也許會把它完成吧。
單純針對 jQuery 的教學似乎大家比較容易進入狀況，因為環境設置簡單，而且 jQuery 的語法也相當簡潔，甚至有朋友在當下就依循著教學內容去組合出比較複雜的應用，時間的安排也剛好，那次感覺比較舒服些 ;)
版本控制的課程，台下的反應比預期要熱烈些，應該是這類型的需求與日俱增吧，畢竟應用程式的複雜度越來越高，不是每個人都能夠清楚記得自己在各個環節進行的操作。
最近一次 PHP 入門的工作坊出了些狀況，因為使用 Windows 環境(我居然對 Windows 這麼陌生…)出現了一些預期外的狀況，加上範例剛好踩到 CakePHP 的保留字以及新版本的 bug ，原本想要在這個過程展示一下每天在做的事情，結果反而讓課程中斷了十多分鐘，真是尷尬。事後想想，這種跳脫原本進度的展示方式，也許需要將時間儘量縮短，否則會讓人轉不過來。
中原大學的課程剛開始網路有些狀況，因為原本預期是在電腦教室或網路備妥的情況下，所以沒有準備太多可以直接陳述的內容，讓剛開始的氣氛有些尷尬。這也反應了之前的問題，我也許需要在不需要電腦輔助的議題上面多些準備。
在入門性質的教學中，有朋友反應進行的速度太快，可能因為自己已經太習慣這樣的步調；不過同時也有些朋友反應內容太過簡單，恩，這總是兩難的。
因為教學活動產生的互動過程是相對有趣的，畢竟每天面對著電腦螢幕十多個小時的人不太有機會跟那麼多人做實際的互動。不管怎麼樣，希望在這過程所傳達的資訊，真的能夠幫助到參與的朋友，也許這樣就夠了吧 ;)

在 8/25 ~ 10/15 之間，跟幾個朋友進行了十次的 PHP 入門課程，在這前後也跟 OpenFoundry 合辦了下面工作坊：

1. 7/11, 7/12 – CakePHP 教學

2. 10/21 – CakePHP 入門

3. 10/22 – jQuery 入門

4. 10/24 – jQuery 與 CakePHP

5. 11/14 – 版本控制 – Subversion + Git svn

6. 11/17 – php 入門

11/13 開始也會跟中原大學的一個實驗室進行 PHP 入門的教學。

在這些過程中，有時候會遇到手邊工作比較忙的情況，有時候又會剛好在專案之間的空窗期，所以自己覺得品質不是很穩定；對於表現不佳的時候，會有些抱歉。

在這些課程中，對象都有著類似的情況，有些人已經很熟悉相關技術，也有些人完全沒有概念，每次準備教學時所假定的目標族群總是很難剛好涵蓋大部分人的情況。之前去日本時有跟 APC 開發者聊到，他覺得自己準備的東西好像很難讓一般人聽懂，也擔心會不會太過簡單而讓一些高手感到失望，我們最後有個結論，就針對自己最熟悉的部份去切入吧，自己的狀態總是比較好掌握的(不過當時我的主題比較簡單，不知道會不會害到他 ;) )。

因此，在課程的準備上，我使用的大多是自己比較熟悉的環境，對有些朋友而言可能是非常陌生的。而在內容的安排上，我把焦點放在實作過程，對一群人不停的從頭講到尾並不是我的專長，因此偶爾會有朋友反應，一些相關概念的說明也許不是那麼清楚，也許未來在這個部份需要做些努力。

CakePHP 的教學中，在環境設定上面經常花了比預期要多的時間，雖然後續改用 VirtualBox 搭配 Ubuntu 的方式進行，問題還是蠻多的。也許是操作過程太長，以畫面逐步說明的方式不容易記憶，應該要針對這個部份準備比較完整的講義。先前有跟出版社討論出版這個主題的書，不過後來開工作室忙了就沒辦法集中精神在這方面，如果接下來行程不會太緊湊(好像很難…)，也許會把它完成吧。

單純針對 jQuery 的教學似乎大家比較容易進入狀況，因為環境設置簡單，而且 jQuery 的語法也相當簡潔，甚至有朋友在當下就依循著教學內容去組合出比較複雜的應用，時間的安排也剛好，那次感覺比較舒服些 ;)

版本控制的課程，台下的反應比預期要熱烈些，應該是這類型的需求與日俱增吧，畢竟應用程式的複雜度越來越高，不是每個人都能夠清楚記得自己在各個環節進行的操作。

最近一次 PHP 入門的工作坊出了些狀況，因為使用 Windows 環境(我居然對 Windows 這麼陌生…)出現了一些預期外的狀況，加上範例剛好踩到 CakePHP 的保留字以及新版本的 bug ，原本想要在這個過程展示一下每天在做的事情，結果反而讓課程中斷了十多分鐘，真是尷尬。事後想想，這種跳脫原本進度的展示方式，也許需要將時間儘量縮短，否則會讓人轉不過來。

中原大學的課程剛開始網路有些狀況，因為原本預期是在電腦教室或網路備妥的情況下，所以沒有準備太多可以直接陳述的內容，讓剛開始的氣氛有些尷尬。這也反應了之前的問題，我也許需要在不需要電腦輔助的議題上面多些準備。

在入門性質的教學中，有朋友反應進行的速度太快，可能因為自己已經太習慣這樣的步調；不過同時也有些朋友反應內容太過簡單，恩，這總是兩難的。

因為教學活動產生的互動過程是相對有趣的，畢竟每天面對著電腦螢幕十多個小時的人不太有機會跟那麼多人做實際的互動。不管怎麼樣，希望在這過程所傳達的資訊，真的能夠幫助到參與的朋友，也許這樣就夠了吧 ;)

發表於 活動感想 | 迴響已關閉