施比受更有福

幸福建立在錢上面是很脆弱的，

那是一個無底洞，

為了幸福-->就要賺更多錢-->花更多的時間心力在工作-->反而越不幸福

當然我不是說錢不重要，最基本的生活底線是需要一些基本開銷，

但是千萬不要把幸福全部建立在有錢上面，那只會讓你痛苦，不會給你帶來幸福的，


偶爾羨慕人家是難免，無傷大雅

不過如果打從心裡羨慕人家的人多半是對自己的生活不滿意

或是對自己自信心不足

而對於生活的滿意以及自信都只是自己的想法跟態度而已，

你應該想想怎樣調整你的生活，

幸福只是一種感受而已，

有本書叫做「黃金的下半場」（名字不太確定）

內容其實很簡單，就是一個人他在45歲之前，就是為了追求社會上所謂的「成功人生」而努力，

努力賺錢，努力SOCIAL，努力往上爬，

結果45歲那一年他生了一場大病，他的人生完全改觀，

他病癒之後，決定要將人生的下半場，追求一個「有意義」或是「有價值」的人生，

而不是別人眼中所謂的「成功」。

他固定會去當義工，會作一些別人眼裡覺得很傻的事情，

但是他深知道施比受更有福這句話的真正意涵，當自己有能力幫助別人的時候，我是幸福的，

之後他的下半輩子，雖然收入減少，但是他每天都過的很充實，很快樂，很有意義，也幫助了很多人...

很多人總是在預支他的人生，總是計畫著：我要努力拼到45歲或50歲，然後退休享福～

我很冒昧問一句，你怎麼知道你能健健康康活到50歲？

活在當下，把握每一刻，珍惜身邊的人才是你最應該作的，

懂得感恩，每天早上醒來都還有呼吸就要感恩，我想你會是個幸福的人


最後提一個觀念：

錢對你的意義是什麼，你是錢的主人，還是錢是你的主人？

你的每一筆收入都充分的「善用」了嗎？還是「濫用」了呢？

善用你的錢，才是所謂理財的最基本，

錢是最好的僕人（工具），卻是最糟糕的主人，

希望大家都可以有個美好幸福的人生～

The Chair for Programmer

The Chair for Programmer

Herman Miller Aeron Chair
Herman Miller Mirra chair

http://www.hermanmillerred.com/

http://www.codinghorror.com/blog/archives/001146.html

A good programming is 99% sweat and 1% coffee

A good programming is 99% sweat and 1% coffee

寫一年的程式要有一年的功力

我一向認為寫一年的程式要有一年的功力, 而不是來一個需求, 就抄上一個改改就完成了, 有時應該停下來想想, 這次的程式設計或專案留下什麼經驗, 可提供下次專案參考, 如何更有效率或更有生產力的完成, 例如：整理可再用的工具模組, 商用模組, 甚至開發自動化工具, 如報表程式產生器, 系統文件產生器, 反向工程工具, 隨著您的創意, 您可以不斷創造出有價值的東西或商品. 當別人要花一天16小時才能完成的工作, 您只要兩小時. 上面我所說的, 我都確實在我的工作生涯中做到了.
因此, 您的經驗得以再用, 您的創意得發揮, 而這些就在於您是不是保有工作的熱誠, 當您有工作的熱誠, 您會在乎如何有效率的完成工作, 如何將經驗分享給團隊, 提升團隊戰力, 如何服務客戶, 提升組織績效及公司業績, 您會在乎如何以最少的成本帶給公司最大的價值.
去年從其他位同仁接下一個失敗的案子, 以較少的人力於一個月內自力完成, 而且得到客戶很好的回應, 關鍵就在於”經驗“
由於人力並不充裕, 在專案中, 我往往除了程式設計外, 也扮演專案管理與系統分析的角色, 另外也扮演內部人員及使用者的教育訓練的講師, 因此資深同仁, 往往負有更多的工作及責任, 在知識經濟的時代, 大家都認知”知識”是組織重要的資產, 能累積知識及經驗並分享與傳承, 我想這更是資深同仁的重要價值所在
年資淺者除了精進技術外, 應該多學習團隊其他成員的優點, 吸收其他人的經驗, 在專案過程中, 學習專案執行的技巧及藝術, 並學習人際的互動與談判或推銷的技巧, 有一天您自然能擔當大任.
而真正瓶頸所在, 是許多人失去年輕時的求知熱誠, 過於計較金錢與名位, 忘記真正工作的價值, 非但不是提升團隊戰力的酵素, 還成為組織成長的阻力, 如此35歲帶來的是成本, 而不是價值了

寫程式要有結構、常數值要先宣告不能在程式中直接用

剛畢業的幾年，總覺得工程師像電容或是手機的電池一樣，就在新技術潮來潮往之間，不斷的充電和放電，直到有一天新知識裝不下去，舊技術沒價值時，就叫做年紀大了。
近不惑之年，經歷了軟體界的各個角色後，看法大不相同，願與大家分享。
阿亮說，凡走過必留下痕跡。充放電之間，到處是值得掌握的當下。
Programmer 隨著年資的增加，經驗心得是不是也跟著累積？例如，我們會不會告訴新來的菜鳥，寫程式要有結構、常數值要先宣告不能在程式中直接用、輸入的引數要先檢查以免問題一再傳播難以追蹤、Naming要有規矩別人才看得懂、軟體要備份和版本控制才不會亂成一團、...？
如果答案是肯定的，資深Programmer的價值當然存在。反之，35歲的工程師做得事情和剛畢業的學生差不多，在功利的角度下衡量，薪水自然也差不多。
又如果，資深Programmer可以把份內的事做得這麼好，有什麼道理不請來Design系統呢？因為這樣子，設計的時候就已經想好，程式要怎麼樣才能被 Programmer順利的寫出來。一路推上去，也不會發生現在我們常抱怨的，『分析師都不懂技術實做，轉換非常困難』之類的問題。
如果做好每一段的工作，未來的方向是可以由自己選擇的。只是，走得順不順利卻是造化，這種問題交給老天爺就好了。

五隻猴子的故事

五隻猴子的故事

把五隻猴子關在一個籠子裡，籠子上頭有一串香蕉。實驗人員裝了一個自動裝置，若是偵測到有猴子要去拿香蕉，馬上就會有水噴向籠子，這五隻猴子馬上會被淋濕。

首先有隻猴子想去拿香蕉，馬上水噴出來，每隻猴子都淋濕了。每隻猴子都去嘗試了發現都是如此。於是猴子們達到一個共識：不要去拿香蕉，因為有水會噴出來。

後來實驗人員把其中的一隻猴子換掉，換一隻新猴子（稱為A猴子好了）。關到籠子裡這隻A猴子看到香蕉，馬上想要去拿。結果，被其他四隻舊猴子海K了一頓，因為其他四隻猴子認為新猴子會害他們被水淋到，所以制止這新猴子去拿香蕉。這新猴子嘗試了幾次，被打的滿頭包，還是沒有拿到香蕉。當然，這五隻猴子就沒有被水噴到。

後來實驗人員再把一隻舊猴子換掉，換另外一隻新猴子（稱為B猴子好了）關到籠子裡。這隻B猴子看到香蕉，當然也是馬上要去拿，結果也是被其他四隻猴子K了一頓。那隻A猴子打的特別用力（這叫老兵欺負新兵 呵呵！） B猴子試了幾次總是被打的很慘，只好作罷。

後來慢慢的一隻一隻的，所有的舊猴子都換成新猴子了。大家都不敢去動那香蕉，但是他們都不知道為什麼，只知道去動香蕉會被猴扁。

這就是「傳統」的由來。

call_user_func_array vs $myfunction( &$params )

call_user_func_array vs $myfunction( &$params )

Hi,

I was looking at
http://www.php.net/manual/en/function.call-user-func-array.php and I
was wondering...

Given,
// --
function foo( &$params)
{
echo 'bar';
}
// --

What is the difference between

// --
$params = array( $stuff);
$myFn = 'foo';
$myFn($params)
// --

And

// --
$params = array( $stuff);
$myFn = 'foo';
call_user_func_array( $myFn, $params );
// --

Wont they both achieve the same result?

FFMG
=============================

call_user_func_array is useful when the number of parameters to a called
function is variable or unknown, for example:

function nice_dump() {
$params = func_get_args();
echo "

";
call_user_func_array('var_dump', $params);
echo "

";
}

nice_dump(1, 2, 3);

=============================

Indeed, it's not really function name that's interesting in this
particular example, it's the parameters that particular piece of code
doesn't have to worry about.

Then again, one of it's major advantages is it also supports callbacks, so
you can easily give a class function or object method to it. Your code
would be rather complex to get that otherwise...