愈來愈不喜歡講架構了，因為講的人痛苦，聽的人也痛苦

近幾年來的感覺特別明顯，尤其是跟不太熟的人講的時候

第一，你不知道對方的程度到那邊，講的太多，他們聽不懂; 講的太少，還是聽不懂

第二，你做了一些設計，但結果大多數都會聽到：『這跟我當初想的不一樣~~~』(靠，那你當初為甚麼不想？要我想？？？)

第三，在你做之前，會告訴你很多願景：『我希望可以共用』、『我希望未來會有延展性』、『我希望很好維護』。結果，大部份等看到實際的設計之後，都會說：『我們需要搞這樣複雜嗎？』

第四，有些客戶，因為自己覺得自己很厲害，所以常常會提出他自己的看法：『我覺得這樣改比較好』、『這樣應該比較正確吧？』、『這樣的設計才是我當初的構想』。我很想說：『你早說我不就不用想了嗎？』。如果你覺得你比較厲害，那你應該自己做，不應該要我來做。浪費你的時間，我的腦力~~~

這幾年愈來愈覺得感慨很深~~~
大多數人希望軟體就像一灘死水，只要寫完就希望不要再去改，但是這幾年的變化卻是愈來愈快、愈來愈多
等到要把一灘死水攪活的時候，就得找看不怕臭、不怕髒的人下去搞
或者是把所有的東西就推給廠商，反正只要出一張嘴，其他那是你家的事，付錢的就是大爺~~~

死的是誰？死的是這些工程師、還有廣大的使用者~~~因為軟體愈難用，就愈不會有人想用
而軟體愈難寫，工程師也就會愈來愈偷懶，愈來愈不想動腦筋

所以漏洞永遠都在，只是有沒有人會去發現而已

所以說：客戶，你說的都對，是我的錯，我不應該 over design 的....

到底甚麼是架構？甚麼又是SD該做的事情？

今天跟同事討論到這個問題，是因為他問了我一個問題：『可不可以把現在我在專案中做的機制，列出來，當作後續專案的遵循依據』

老實說，我覺得這個問題很難回答

1. 所有的機制，要留下程式碼，不是不行，但是因為事過境遷，很容易因為技術的進步而讓這些機制原本留下的程式碼，在因為時間以及技術的變遷，導致之前所撰寫出來的東西，開始逐漸出現一些不合適的情況
2. 留下來的程式碼，如果原作者，沒有適當的再重複的修改以及利用，其實對於交接的人來說，是很難去理解當初的想法是甚麼。如果再經過歲月的累積以及層層的程式碼堆疊以及繼承，很容易就失去當初的目標以及重心了
3. 因為每次在實作的時候，通常都是根據當時專案所要達成的目標，而去量身訂做的一些作法，除非下一次專案可以完全一模一樣，否則通常很難達到說完全移植的情況出現。更何況，下一個實作的人可能不是你，誤差會更大。
4. 如果不是非常了解所採用的 framework 本身的機制，很容易在遇到問題的時候，變成無解的狀況出現。而在之後的實作當中，你的好意就被忽略了....

其實說了這樣多，講穿了一點，就是溝通以及思考方向問題

因為其實做專案這樣幾年下來，其實專案裏面，應該要做到的事情以及目標，其實大多明確

只是，往往目標明確，卻死在實作的細節上

因為可能大家都知道要做到甚麼東西，卻不知道要怎樣才能做到那樣的效果

以至於不是評估的過於難做，就是樂觀的以為很容易就可以做到，卻發現實際上在做的人，達不到你想要的效果

或許是我有點悲觀，但現實面來說，發生的可能性往往超出自己的預料之外

或許我們把『架構』這件事情搞得太大了

因為架構應該是一個最基本的框框，去定義你該做甚麼事情、不該做甚麼事情

只要遵循這樣的處理方式，就可以達到基本的要求

而SD要做到的，就是在這樣的方向底下，根據實際狀況來量身訂作專案所應該要做到的事情

或許該做的事情還是很多，但至少不會被架構給綁死

不過，往往『架構』這件事情，搞到最後，因為程式碼的累積

以及被 ReUse 觀念理解錯誤，導致很多程式碼都會被綁到架構的程式碼裏面去

若沒有經過重整以及介面的釐清，到最後就是跟窩窩頭一樣，一層一層的感覺~~~

你說那是錯的嗎？我只能說那是時間以及環境所造成的......

而真的懂這種事情以及做的出來的人又有多少？？？

Google Has Stopped Developing Gears

Google Has Stopped Developing Gears: "Google seems to be no longer interested in further developing Gears, promoting HTML 5 instead. By Abel Avram"

看到這個新聞，加上我昨天晚上看的相關 HTML5 的資料

http://www.wowbox.com.tw/blog/article.asp?id=2446

http://zh.wikipedia.org/wiki/HTML_5

還有雲端運算的加入～

我想 2010 會是一個很不一樣的年，對於技術人來說，應該是個蠻衝擊的年

Learning Grails

最近又回來 Java 陣營了~ 因為專案大致上要開始啟動了
所以，也要有點準備

剛好，前一陣子 Grails 發佈了 1.1 的新版本，之前我是不太清楚，我知道 Groovy
但是那時候認為 Groovy 還需要等待一點時間讓他成熟，而且前幾年也還看不出來他應用的層面在那邊
光 Performance 問題在剛開始就被砍掉了，不會再繼續下去

另外一個很大的原因就是，學習曲線是有的，在當時公司成長的狀況
光 java 可能就搞不定了，更不要說是另外一種 Language 了

近幾年來，RoR 造成的一股風潮，帶動了 Dynamic Language 的一個熱度
也相對的讓 Web 開發，進入了另外一個領域，以 DSL (Domain Specific Language) 語言，搭配 Aglie 的開發方式
讓工程師能夠更加的容易進入開發，也用了類似 Mashup 的方式，避免掉 DRY (Don't Repeat Youself)
等於說，把近代一些比較熱門的技術或想法結合在一起

所以，Groovy 身為 Dynamic Language 的一員，出現了 Grails，對我們這些開發人員來說，有利也有弊

有利的是，可以不用再花費很多時間，去思考很多的 Solution 要怎樣拼湊一起，尤其現在的一個需求，往往是需要很多解決方案
但是，如果要自己重頭開發，或者是要自己去拼拼湊湊，往往前置作業就要花掉你很多時間
但是在 RAD 的世代，我碰過開發期只有一個月的專案，那還有時間讓你這樣搞

不過，相對來說，對於剛入門的新手，如果不懂得這些你要 Mashup 東西的基本原理，大概就只能湊個簡單的解法
對於深入使用來說，就會很慘了，因為他們都幫你包掉了，所以，你很難去找到其中的小秘訣或者是問題點
必須要苦苦的等待新版本或者是 bug fix~ 然後，可能就得跟客戶說：『抱歉，這不是我的問題』，然後狠狠的被批~

不過，因為整個 java, groovy 核心效能的改善，以及硬體的搭配，我自己是認為，這些 Dynamic Language 已經可以慢慢開始學了，如果還沒有學的話
因為我想 javascript 目前的成功，也告訴了我們，這種 Dynamic Language 勢必會是下一段改變的開始
逐步進入，也避免等到需要的時候，才來學，我想已經被人超越一大段了

新年新希望！

去年，2008年，其實我覺得是一個變動蠻大的一年
雖然我的工作沒變，哈哈，好家在
不過，去年倒是有很多新的體驗~

• 去北京，坐地鐵，擁擠感大於新鮮感
• 有點戀愛的感覺，不過蠻短的，可能在還沒感覺到就夭折了
• 自己一個人出國自助旅行，還去了日本東京，我連五十音都有點記不住了。之後還想去澳洲....
• 開始看.Net，雖然我還是Java的擁護者，學了一陣子趕鴨上架後，我還是喜歡Java
• 算是開始有敗家的感覺，因為去年買了很多東西，除了旅行之外，去年算是我這幾年來花費最多的一年
• 開始有一點點認真的想過自己未來的生活，也想要有個自己的窩了.... 前題是錢要存夠....

新年新希望

• 小摺，因為最近騎腳踏車很風行，我也想要....放一台在車裏面，棒！
• Wii + Wii Fit ，可惜家裡還有兩個小孩，難....
• 第二次自助旅行，地點，目前還在想，可能想去英語系國家，至少我覺得我英文比日文好...
• 自己的窩.... 恩~ 這更難了.... 首先應該還得搞定家裡的意見再說.... 不過，地點也是很重要的，只是這可能只是想想吧，至少我想今年是達不到的

去年景氣不好，我想今年應該也是會在持續下去，我沒那樣樂觀，因為這也不是一天兩天的事情
出來混的，總是要還的
只是現在是全民陪著一起還就是

不過，還是要自己努力一點，讓自己變成『不可取代的』角色，才是重點，這樣就不用太擔心了....

試用 twiki, 殘念....

最近因為參與一個專案，在參與前期系統訪談的時候，發現了一個問題
客戶以及我們，在整理需求文件的時候，是用很傳統的方式，以 Word 來條列所有想到的項目，以及用 Word 整理畫面基本的 prototype，以及很多很多的檢核規則

另外，還有以下的一個特性
1. 客戶以及我們的 SA 都有『同時修改』文件的可能性
2. 有很多地方，是屬於專有名詞，必須要參考另外一份『看起來是整理好的共用規範』，或者是資料庫的相關文件
3. 有很多規則是在討論過程中，逐步釐清的

鑑於以上的這幾個特點，我思考的一個方向是
1. 要怎樣讓雙方都好修改文件，而且只保持一份？
2. 有歷史紀錄，可以比較之前修改的紀錄
3. 如何可以很好參考很多的專有名詞？比如說可以用超連結直接連過去
4. 不需要在意格式，因為這樣會花費很多時間在調整文件樣式

我思考的過程中，發現，其實現在，導入作K.M.的方式，很多是以 Wiki 來當做知識以及文件的整理平台
雖然現在公司有在試用 dokuwiki，但是總覺得少了點什麼
因為我可能需要
1. 區分專案
2. 好編輯
3. 可支援subversion

網路上剛好有一個網站 http://www.wikimatrix.org/，可以根據你的需求，挑出最適合你的 wiki
所以後來找了一下，找到了一個 twiki ，評價不錯，而且都還有陸續在更新，也有很多的 plugin
在 ubuntu 上面，也很好安裝，只要執行 "sudo aptitude install twiki" 就可以了

可是呢，這個 twiki 好像在外國是很熱門的 wiki，在台灣不是很多人用，所以中文的文件或者是部落格文章都不容易找，所以現在也還在試用當中

其實初期的 wiki 編輯都差不多，不管是 dokuwiki or twiki，wiki 的優點像是 internal link, history 等特性都可以很容易的顯現出來
只不過，整個在試用的唯一一個，也是最重要的一點就是

Shit! 文件已經太大量了..... 已經無法從 word 轉到 wiki 了
因為要使用 wiki ，不是把文章原封不動的一篇一篇搬到 wiki 上面，這樣一點都無法利用到 wiki 的特性
所以，光這點，我就已經想不出來，要怎樣去告訴客戶或者是SA，要使用這個 wiki 來做共通的文件平台

...... 習慣是導入新東西的殺手阿~~~

最近在討論公司內部專管系統

業務流程決定軟體程式，軟體程式追隨業務流程

最近在跟主管討論，目前公司內部使用的專管系統，希望做個改版，讓他比較好用，而且比較有實用價值
剛好今天就看到這篇文章，真的是心有慼慼焉

對於一個『好用』、『能用』的系統
不是在於他功能有多少，系統多強大
而是在於，這個系統，到底有多少『實用性』，對於實際上的公司現行作業幫助有多大

不然，這個系統也等於是一個形同虛設的系統，只不過是因為公司內部需求，所以才『幫忙』填些資料罷了

這是另外一篇延伸閱讀的文章

從用例到測試用例的追蹤

聽歌的習慣

我自己聽歌有個習慣，如果聽到自己非常覺的非常好聽的歌，就會讓他不斷的重複播放
就算聽了幾十遍，也是會繼續聽下去，甚至像是昨天，我聽丁噹的那首歌，就聽到快一點多

單純的只是想讓自己沉浸在音樂裏面
就好像看電影一樣，讓自己在那個情境裏面流連，只是單純的去感受這首音樂想要表達的意義
然後在搭配 MV 的情節，就真的好項在看一部電影一樣

原來，這些都是我不知道的祕密!!

funP 快看- 原來，這些都是我不知道的祕密- Money As Debt

昨天看了這篇 blog，是有點沮喪，但是大概一分鐘後，我就忘了
因為，我擔心也沒用~~~

自助旅行確認！接下來開始規劃行程了

今天請同事幫忙跟旅行社確定了機位，明天應該就有答案了，我想團票應該是沒有問題的
住宿的部份，今天也上網訂購好了，看起來開始一切是順利的
所以現在開始就要收集資料去了
準備開始規劃這幾天要去哪裡逛。

恩~ 祝我順利~~~

東京自由行~五天四夜~ 嘿嘿 想起來就爽.....
這也算是放自己幾天假罷，因為最近總覺得工作起來不是很帶勁
總覺得少了麼東西一樣

雖然說我每天還是早早的起床出門，不會有什麼不想上班的感覺
但是寫起程式來，就是有點覺得思緒停頓，我不覺得這是我什麼上了年紀的問題，靠。
我只覺得是自己好像有點放不開的感覺
所以其實很期待今年的年假，能夠好好的讓自己不要再侷限在目前的一個框框裏面，看可不可以有比較好的思考方向
對於自己，對於未來......