剛剛接到一通自稱是單車小站服務人員的電話，大致內容是說要取消分期刷卡簽單，雖然想也知道是詐騙，我就多跟她互動了一下，發現她對於我的交易內容還蠻清楚的，只是她並不知道我回答的內容有刻意造成的錯誤，因為飯已經送上桌了(我在便當店接到)，所以就揭穿她是詐騙的事實，她還回覆說"你確定嘛？你有證據嘛？如果不是你要負責喔！"，看來他們的講稿已經可以包容各種不同的回應，聽口音也不像是大陸人。
來電顯示是台南的號碼沒錯，只是現在這個號碼是可以變造的，所以打回去的意義不大。
大致可以猜出資料外流的兩種途徑： 經手的員工或是帳號被入侵 ，因為我是直接透過 Email 完成交易的。
回到家之後就打電話給單車小站的人員，要他們趕緊修改密碼；也把資訊提供給 165 反詐騙專線。只是基於不希望真的有人受騙，加上單車小站確實沒有做好個人資料保護的工作，所以選擇把資訊公開。我的 Mobile01 帳號好像已經被鎖很久，有帳號的朋友就麻煩將資訊轉到那上面吧。
下午還在弄客戶的東西，到一個段落之後才開始準備晚上要分享的東西，腦子裡原本都是一些流暢的劇本，但是到了現場才發現， 5 分鐘真的好短 ^^||
我並沒有報名 osdc 白天的活動，因為已經預期這段期間會困在程式碼當中，只是上面一個專案剛有些成果出來，想要找個地方發表一下，所以就報名了 YDN 的活動。提早到了現場，發現找不到入口？只有個很模糊的看板寫著 Babe room 18 ，但是營業時間是晚上 10 點開始，所以就在旁邊繞啊繞的，在找有沒有其他更像是活動會場的入口，只是背著電腦做這種事情感覺不是挺好。
去附近晃了一下，回來後那個門口才開始有舉辦活動的感覺，一堆看起來就像是工程師的人在簽到中。我也去簽到了，拿到了一個名牌，接著得在外面等，因為活動場地準備當中，還好附近蠻多地方可以逛的，加上前面的廣場就有街頭藝人表演，還不至於太無聊。
實際進入會場後，感覺有些許的酒臭味，應該很多人在那個樓梯間吐出來過吧，所以即使整理過了，還是很難不留下異味。這是個夜店，因此裏面有很典型的吧台、開放式的小隔間以及許多的沙發，不像是適合辦研討會的地方，但這個活動也沒說是研討會，只是死工程師個性作祟罷了。
進去之後就是公關公司的暖場活動，雖然一堆人不是很賞臉，但還不至於讓氣氛變得太僵，畢竟派了幾個辣妹在現場了，這是另一個工程師的死個性 
晚餐吃的是 Pizza ，為了待會兒上場，所以不敢吃多，中間就開始去試機器了，還好筆電沒有出糗，只是開機時一直在偵測網路而卡了一陣子，害我擔心了一下。在我前面先是 Yahoo 的人員介紹新服務，接著是 UrMap 也來宣傳新功能，而在我後面那個好像說是忘了帶要展示的東西…^^||
原本的準備是 4 個循環來介紹 oa-tools ，不過講了 2 個循環時間就超過了，所以就草草結束，畢竟這不是個適合在技術議題多所著墨的地方，看後面美麗的公關公司小姐們都一臉茫然的樣子就知道，我又再次加強了那種死工程師的調調了。
過程中兩個貴賓 Rasmus 與 Chris 有透過一些題目考考大家，細節不太記得了，只記得最後一題讓所有人都出局了。整個活動的氣氛還不錯，只是我好像有點沒辦法進入狀況，太久沒有放鬆自己吧
最近參與了 FrontAccounting 社群關於授權方式的討論：
http://frontaccounting.net/punbb/viewtopic.php?id=398
FrontAccounting(FA) 的前身是 OpenAccounting(OA) 與 webERP ，其中 OA 已經很久沒有更新了，而 OA 與 webERP 都是使用 GPLv2 授權，因此 FA 在 2.0 與早期版本都是使用 GPLv2，只是在上面討論發起後，開發者似乎有意將授權轉換為 AGPLv3 。
雖然 OA 是改寫自 webERP ，據說已經完全沒有使用到 webERP 的程式碼，而 FA 的開發者取得 OA 作者的同意，將程式的授權更新到 GPLv3 。接著， FA 的開發者發現 GPL 授權內容有提到， AGPLv3 相容於 GPLv3 ，因此認為可以直接將 GPLv3 授權轉換為 AGPLv3 ，所以就決定在 FA 2.1 版開始使用 AGPLv3 授權。
我在 gnu 網站找到了一則關於相容的說明：
http://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible
這才了解到，GPL 所謂的相容是指兩個不同授權的程式可以放在一起，像是核心程式使用 AGPLv3 時，模組可以選擇使用 AGPLv3 或 GPLv3 任一授權方式，並非如同 FA 開發者所指能夠直接轉換。接著針對這點發現提出回應，也將內容發到 gpl-violations 的通訊論壇確認。
接著 FA 開發者暫時將以 AGPLv3 授權的程式撤下，透過各種方式進行意見的交流，不過他們提到已經取得 OA 作者的完整授權，選擇 GPLv3 或是 AGPLv3 都可以，只是希望聽聽大家的意見。
我提到，對網頁介面為基礎的程式來說，AGPLv3 就好像是共產主義一樣，任何人只要能夠存取程式就可以要求完整的原始碼，而 GPLv3 就好像是資本主義下的稅負一般，即使總是有人抱怨其他人的逃漏稅，但這不應該是改選擇共產主義的理由。
我並不喜歡那種抱著投機心態使用 ASP/SAAS 授權模式的商業模式，但是我更不喜歡一堆不相干的人無時無刻吵著要程式碼的態度，這是我排斥使用 AGPL 授權的原因。在討論中還有提到，那些使用 ASP/SAAS 方式迴避 GPL 授權的供應商，他們所修改的程式碼還是有回到社群的機會，因為工作中接觸到那些程式碼的工程師或是合作廠商，只要他們在放棄合作與工作前提出要求，GPL 有著不得加諸限制的條款，他們原則上可以合法取得完整的程式碼以及散佈那些程式碼的權力。如果社群中真需要那樣的功能，而那些公司也沒能夠妥善照顧所有可接觸程式碼的工程師，相信這些程式碼還是有機會回到社群。
最後， FA 選擇了 GPLv3 ，不過也語帶保留的提到或許未來還是有可能改採 AGPLv3：
http://frontaccounting.net/punbb/viewtopic.php?id=480
簡單的說， GPLv3 跟 AGPLv3 兩個授權可以放在一起，但是不能換來換去。
昨晚跟 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/ )。
已經有人在做？那為何不要一起做？團結不是應該力量大些嘛？
你沒看錯，就這間！
為什麼取這個名字？因為打廣告容易，怎麼說呢？
就因為這樣，所以取名"就這間"…很好記吧
不過不要誤會，我不是趕流行趕到被裁員，而是自己想要離職的，因為總覺得在公司裡面沒辦法做些自己想做的事情，在公司的程式開發工作到一個段落後，提出離職的申請。離職後跟原本的公司也許會有額外的合約關係，所以有想要做類似網站的朋友先說聲抱歉了，基於道德與法律的考量，無法承接這種委託。
工作室會做些什麼？初期大概就是平常在做的那些事情，長期性的規劃會在基本的收支能夠平衡後陸續進行。
工作室會使用 olc.tw 這個網址，而未來跟工作室有關或商業性的文章就會發表在荒費許久的 osobiz.com ，農曆年期間會陸續進行整理。
也感謝那些願意給我工作機會的朋友，只是短時間內可能不會考慮再進入到一個公司的體制之下，希望自己闖闖看。
目前在籌備期間，歡迎有意願合作的朋友透過信箱 kiang @ osobiz . com 連繫，在資料準備好後會主動拜會大家 
12/11
準備的比較匆忙，主要試著去講內建的一些方法，包括 Model 的 find() 系列函式，後來就留著給大家自由發揮，不過看樣子這種方式效果不佳。(其實我自己都忘了自己講些什麼)
12/18
以一個問題開頭"如果這是個 CRM ，你覺得需要加入什麼功能？"，因為覺得想的清楚會比做的快要來的有價值些，所以回頭將焦點放在想法的組成上面。同學們提到了客服系統、訂單管理與生日通知等，以客服系統作為目標，開始一起思考該開什麼樣的資料表與欄位，接著一樣透過 bake 產生基本的結構，逐一把問題提出、解決，透過這樣的方式好像大家比較容易進入狀況。只是隨著組合的程式碼越來越多，就開始反應出大家基礎不夠深厚的問題，畢竟 Framework 是讓一些有經驗的人使用，對於 html, php 都還有些半生不熟的人可能很吃力。
不管怎麼樣，今天感覺還不賴，幾乎講到最後一分鐘，讓這短短的五次上課有了一個不錯的結局。
是的，課程結束了，因為同學們接下來要準備期末考。原本想了很多東西，但是並不符合大部分同學所需要，所以這五次的上課幾乎都環繞在一些基本的操作上面，不確定對於同學們有沒有一些幫助。
在這簡短的教學經驗看來，CakePHP 的課程對象如果是初學者，也許需要 60 ~100 個小時才能夠進入狀況，理想的狀況下還是一週有個三次上課會比較好，每週一次的效果差了些。
基礎還是很重要的，學習一個程式語言並不是學那個千篇一律的基本語法，而是去深入內建的函式、環境等，進而跟實際需求結合，共勉之
應老師的邀請，現在每週四晚上都會跟一群北商四技三年級的學生做技術性的分享，據說是這些學生主動跟老師反應，學校教的東西他們覺得未來出社會後不知道該怎麼用，所以希望有些實務上的教學，就這樣開始了。
11/20
第一次上課，花了些時間熟悉同學間的狀況，看樣子有接觸過 Java, Linux ，對於 PHP 只有操作過 XOOPS 的安裝，大部份對於未來工作的想法是放在 MIS 與 DBA 等職務上面，我當然就是為程式設計師這個工作做了些道德勸說，然後展示了以 Bake 快速建置基礎操作介面的過程。
讓我意外的是，他們對於 Linux 的接受程度還蠻高的。
由於同學們沒有特別的想法，我就從自己最熟悉的下手，所以接下來主題確定是放在 CakePHP 。
這裡其實有些爭議，畢竟 CakePHP 是給比較熟悉 PHP 的人使用，拿它來教一群對 PHP 沒什麼實作經驗的人，或許有些難度；只是，我就想要用這個主題，他們就…^^||
11/27
當天將焦點放在透過 Bake 指令完成基本結構，由於學校提供的操作環境是 Windows ，加上當時網路出了些狀況，環境的建置就花了一些時間，讓同學們實作完簡單的 Bake 操作後就收工了。
這裡發現了些狀況，同學們普遍英文程度比較落後，而我在教學過程似乎給了太多專有名詞，讓他們有些無所適從；但是這種時候提供翻譯也許會害了他們，畢竟未來的技術性工作中，很難把英文當作不存在的東西。
12/4
簡單介紹了 CakePHP 的結構，以及 CakePHP 中的4個關聯，實作的部份還是以 Bake 進行，只是看樣子我的進度安排太快了，同學們在基礎的操作中還是花了些時間，所以還沒能夠開始進入狀況。
我並不想要花太多時間在基礎觀念上，所以課程中提醒同學們，以這樣的進度，也許到了學期末能夠做出來的東西還是很陽春，所以希望他們能夠利用一些額外的時間，讓教過的部份可以熟練些。這個課程有些特殊性，一週只會見面一次，所以如果每次都得從頭開始，進度只會非常緩慢；為了不辜負老師及同學們對這個課程的期望，也許進度的安排會有些跳躍性，進度之間的空缺就需要有心的同學花時間補上了。
我不是個正規的老師，我只是把一些工作中的想法落實在這些同學上，讓他們有機會看到進入社會後接觸到的是什麼樣的挑戰；在面試時接觸過那麼多的新人後，發現這些剛從學校畢業的學生，競爭力確實有下滑的感覺，希望這個課程中，我不會是這種情況的幫兇。
筆記型電腦買了一陣子了，到剛剛才把 Ubuntu 下的無線網路搞定，一切只能說太幸運了，剛好買到這台使用 Atheros AR5006EX 無線網路晶片的電腦，據說 Linux 核心 2.7 版才會完整支援，所以在 Ubuntu 下怎麼也看不到無線網路介面，害我每次需要用時就得切到內附的 Vista ，很不喜歡。
網路上找的到的方法都試過，只是大多沒有辦法解決問題，直到最近才找到這個可行的解決方案。
步驟：
1. wget http://snapshots.madwifi.org/special/madwifi-hal-0.10.5.6-r3698-20080604.tar.gz
2. tar -xzf madwifi-hal-0.10.5.6-r3698-20080604.tar.gz
3. cd madwifi-hal-0.10.5.6-r3698-20080604
4. sudo aptitude install build-essential
5. sudo make install
6. sudo modprobe ath_pci ，到這裡已經可以開始使用無線網路
7. sudo pico /etc/modules
加入 ath_pci 後儲存、關閉，這樣一來每次開機就會自己啟動
記得先把無線網路開關打開，啟用模組後透過 系統 -> 管理 -> 網路 做設定即可。
第一次在 Ubuntu 上無線網路，感動的記下這一刻…
怎麼開始的？
在實際使用 CakePHP 前，我已經是個以設計 PHP 應用為主的工程師，也是開始體會到，程式設計其實還有蠻多煩瑣的工作必須完成，不是每天都可以接觸新玩意兒。
一個使用者在操作過程發現，好像應該加一個欄位進去，需求進到工作清單，在資料表開了對應的欄位，接著就是在表單新增一個欄位，確認資料可以塞進資料庫後，就開始著手修改畫面，簡單測試後就請使用者試試。然後使用者會發現，這個欄位並不只是要顯示而已，應該加入一些判斷，讓他更好做事，這種工作就這樣成了無限迴圈，使用的人越多，發生的頻率越高。
接著老闆突發其想，要將某某流程透過程式自動化，在需求訪談過程會驚覺，原來這個某某流程平時根本沒有標準可言，文件亂、例外狀況多，儼然就是個燙手山芋。在老闆執意進行之下，這系統還是莫名其妙出現了，接著就是操作單位與開發單位的大亂鬥，老闆見情況不妙就開始躲在一旁，在兩個單位沒能夠達成共識之前，功能的雛型就是一直晾在那裡。
最經典的還是那句話，「為什麼誰誰誰有，我們卻沒有？」，這句話可以讓一個需求衍生為全面且多樣性的功能，也可以讓開發單位被要求每天得盯著競爭對手的網站，其中的無奈可想而知。
當然，使用 CakePHP 並不會像拿了什麼寶物一樣讓那些人全部閉上嘴巴，只是在逐漸趨於追逐時效性的現實情況下，能夠有個快速滿足需求的工具會讓生活好過些。
只有 CakePHP ？
在腦子裡開始出現求生念頭時，其實懷抱著許多憧憬，當時耳聞有工具可以將 UML 資料直接轉換為程式碼，或是透過拖拉與設定就可以搞定程式，於是就貪心的把類似的工具當作目標尋找，雖然過程有接觸過 CakePHP ，但是覺得它離理想工具還有些差距，所以一開始並沒有將焦點放在它身上。即使在確認沒有那種夢幻般的工具後，我一開始是使用 Seagull PHP Framework 嘗試進行開發，發現它得花好長一段時間進入狀況，加上接觸當時的文件並不齊全，所以沒有繼續使用。
接著接觸到 Qcodo 這個程式架構，它強調可以自動產生更多、更完整的程式碼，一段放在網站上的展示影片吸引了我；只是吸引我的並不只有 Qcodo 這個工具，還包括他所使用的編輯器，因為在那個時候我還是使用 UltraEdit 這類只有提供程式碼醒目標示的工具(也就是透過各種顏色顯示程式碼，讓程式碼更容易閱讀)，這才更加認為自己應該在工具的使用上多下些功夫。
很幸運的，在掙扎是否要購買 Zend Studio 時，出現了一個免費的工具 PHP Development Tool ，剛好能夠滿足比較迫切的一些需求，所以現在也還是這個工具的忠實用戶。
在 PDT 的協助之下，對 Qcodo 有比較深一層的認識，只是也開始遇到了瓶頸，因為 Qcodo 背後的開發團隊不大(初期只有一個人)，使用的人也不多，加上持續發展當中，所以許多情況下得試著深入核心程式來找出問題，而能夠投入的時間有限，後來主要開發者也消失了一陣子，我就開始轉換跑道了。
期間也有試過 PRADO 與 symfony 等專案，因為複雜度較高而選擇放棄；同時間 Zend 也開始推出自己的程式架構 ，跟另一個公司所分享的 eZ Components 類似，專注在提供高品質的程式元件，並不是很吸引人。
最後，在眾多的程式架構中，我選擇了 CakePHP ，因為它的社群很活躍，進入的門檻較低，相關的介紹與教學也很豐富。
CakePHP 哪裡快？
嚴格說起來，CakePHP 的執行速度並不快，但是它的架構允許你透過各種快取來彌補執行速度不快的問題；真正快的地方是開發速度，自動產生資料增刪改查的程式、資料表的維護、多國語言的語系檔案產生以及單元測試等，這些都可以透過指令完成，而系統本身提供了豐富的元件，加上高擴充性的架構，讓 CakePHP 吸引了許多的程式開發人員。
一個典型的功能開發過程：
1.先透過工具在資料庫完成資料表建立
2.產生資料的增刪改查介面雛型
3.調整操作畫面後進行延伸功能開發
4.設計單元測試範例
5.抽出程式碼中的語言定義
6.上線前設定快取規則
7.納入權限管理設定
最值得一提的是，CakePHP 對於關聯資料的取得相當方便，許多過去要輸入大量 SQL 查詢語法才能產生的資料，在 CakePHP 中只要簡單的幾行程式就能夠做到，而且可以做完整的控制。不過這個好處只有在雛型開發時可以盡情享用，因為預設取得關聯資料的方式會產生大量資料庫查詢，這對於應用程式的速度相當不利，一些預期會需要大量使用的資料存取還是建議手動設計查詢語法。
CakePHP 的演進速度也很快，因為社群龐大，所以許多問題在自己還沒發現之前就被提出、解決了，討論群組的文章數量、網友透過部落格分享的心得以及使用各種語言的在地化社群都持續在增加當中，每隔幾分鐘就會有新資訊從世界的某個角落進入到網際網路中。
另外，CakePHP 的許多概念承襲自 Ruby on Rails ，如果是 愛好者且有 PHP 程式開發需求，CakePHP 或許是個比較快上手的選擇。
停止抱怨，開始寫程式
這個世界總是有喜歡抱怨以及聽了抱怨會擔心、害怕的人，這篇文章並不是為了對抗這種勢力而存在；我是個實際的使用者，在採用 CakePHP 後確實獲得了許多好處，希望藉由這篇文章做個分享。有人喜歡喝自己壓的柳橙汁，有人喜歡用機器壓，也有人接受工廠大量生產的濃縮還原柳橙汁，這只是選擇，別想的太嚴重。
接手了朋友的 eeepc p701 ，把玩了兩天，發現內建的系統限制很多，而且開啟速度比較慢，所以就想要找其他系統替代；找著找著就找到了 lxde 專案，先是依照 pcman 在 mobile01 的文章操作成功：
http://www.mobile01.com/topicdetail.php?f=233&t=682303&p=1
速度真的快很多，而且可以自己惡搞 ^^
但是接著仍然有許多問題需要解決，像是預設有線網路需要手動改為 dhcp ，系統時間用 ntpdate 修正，更新程式時也出現大量錯誤訊息，視窗超出畫面讓我按不到按鈕，網路上的相關討論也還不多。
後來在官方討論區發現有新版本：
http://forum.lxde.org/viewtopic.php?f=10&p=36
第一次安裝失敗，目前正在做第二次嘗試，真的不行就退回去乖乖用舊版了 ^^
這台主要的目的是取代已經陣亡的 PDA ，系統搞定後就要慢慢想辦法把以前的 PDA 資料搬過來了，待續…
