跳到主要內容

培基文教基金會理財課程心得分享

今年在教會上了培基文教基金會的理財課程,感覺非常實用,第一次發現聖經中的道理這麼實際而貼近生活,第一課就先談「財務自由」這個觀念,現在流行的財務自由觀念,大概來自富爸爸、窮爸爸系列的書,可以參考以下連結。
什麼是財務自由
簡言之,就是
持續性(非工資性)收入大於單次性(工資性)收入。

也就是說,如果你現在躺著不工作,也能透過之前的投資(或其他財務措施)擁有一份穩定又持續性的收入(現金流),那你就達到財務自由了,也就是不用一直努力每天工作才有收入(單次性)。
這不是聖經觀點的財務自由
透過培基的理財課程,我們知道聖經所透露出的財務自由是全面性的,是由人的生命角度出發來看的財務自由,其包含上帝的誡命、聖經的真理,以及人跟財務與上帝之間的關係。
而富爸爸所講得財務自由是很片面的,淺薄的一種財務自由,從定義來看就隱含了很多假設,如果這些假設不成立,那根本沒有所謂的自由。

第一個最明顯的假設就是:
持續性的穩定收入要大於你的經常開支。
例如個性浪費,愛亂花錢,隨意刷卡,或是賭博,那就算你每個月透過投資有穩定的高收入,最後還是會被你自己花光,還是得不到財務自由。這一點假設引申下去就是忽略了人性的墮落面,不管你有多少錢,人性各式各樣的墮落都會使人失去自由。

這定義隱含財務自由的焦點只有「金錢」
也許你窮盡一生創造了驚人的持續性高收入,但是回頭卻發現你的老婆要跟你離婚,分走你一半的積蓄,或是兒子偷偷騙走你的錢,更或是子女們為了爭奪財產搞得雞犬不寧,這是「富爸爸財務自由」不會提到的。

這種定義似乎假設人生沒有意外
雖然擁有持續性的穩定收入不用工作,但萬一你父母生重病、不可預期的投資失敗、金融海嘯、出車禍、朋友倒債等等,這些任何一項都有可能一下子就摧毀所謂的「富爸爸財務自由」。

所以,如果我們不該把目標定在膚淺的、片面的「富爸爸財務自由」。而理財課程告訴我們,在上帝的旨意裡管理財務,才能得到全面的、平衡的財務自由。所以培基的理財課從聖經的觀點談上帝對金錢設定的目的與旨意、十一奉獻的意義,以及比較方法性的記帳、詐騙、借貸、作保、購買、合夥,還有家庭、妻子、遺產等主題,可說是全方面造就我們在理財上得觀念,進而達到真正的財務自由。

留言

這個網誌中的熱門文章

Code Complete, 2ed (中譯:軟體建構之道) 讀後心得

Code Complete, 2ed (中譯:軟體建構之道) 讀後心得 雖然以前在學校有修過軟體工程,但是說實在現在我對建構軟體的整個概念都來自於兩本書:「人月神話」(The Mythical Man-Month)、Code Complete[1]。我畢業後第一份工作是軟體研發工程師,我們公司所開發的系統大約有近百位工程師共同維護,當然各有依功能與專業知識將系統劃分不同的區 塊來維護,在面對大型的系統與這麼多人寫程式是以前在學校沒有遇過的,因此也開始思考怎樣才是好的軟體開發方式。從大學好友那探聽到了Code Complete這本書,花了上千元買了英文版,(現在中文版已出,簡體版聽說只要三分之一的價錢)認真讀了幾篇之後,真是如獲至寶,於是自己讀過後,還跟同事組成讀書會一同研討這本書。 作者 Steve McConnell (個人Blog http://www.stevemcconnell.com/ )著作不算量大,但是我看過的幾本質量都很好,印象中他曾經在微軟工作過,後來成立一家軟體顧問公司 Construx Software 。 這本書(書本網站 http://cc2e.com/Default.aspx )的討論主題很廣泛,但是並不空泛,從最小的、最基本的如何寫出好的程式, 例如函式(routine)、註解 (comment)、變數的命名等,也談整個軟體建構的過程除錯、測試,最後也談到軟體工程師個人能力與技術生涯的發展,算是各方面都有提及。但是我比較 建議有半年以上的實際程式經驗來讀這本書比較適合,我自認為如果我在學生時代接觸本書,可能沒有什麼太大的感觸,因為面對的都是小格局、人數少的小系統, 書中所探討的原則與例子,很多時候沒有團隊開發或大型系統的經驗,很難體會。但稍有經驗的人,看完之後保證在程式撰寫與軟體開發方面的觀念會有很大的提 昇。 Table of Content Laying the Foundation 1 Welcome to Software Construction 2 Metaphors for a Richer Understanding of Software Development 3 Measure Twice, Cut Once: Upstream Prerequisites 4 Key

ZK 與響應式網頁設計(RWD)

響應式網頁設計 (RWD) 就現今而言應該是許多網站必備的條件之一,ZK 框架可以幫你從一個抽象層次較高的角度滿足 RWD,不需要了解 CSS Media Query 的細節。 元件層級 元件層級的 RWD 是由元件內部自動完成的。每個 ZK 元件都能區分瀏覽器的種類,因此會自動依據桌上型或行動裝置瀏覽器來自動調整元件的外觀,不需開發者介入,例如 datebox 在桌面瀏覽器會跳出小月曆: 在手機瀏覽器就會自動變成下方滾動條: 頁面層級 頁面層級的 RWD 因為牽涉到版面設計,因此無法靠元件自動完成,因為畢竟每個頁面需要的版面設計皆不相同,這通常不是一個技術性的決定,而是政策性或設計性上的決定,因此 ZK 提供一些工具讓你實現 RWD。以下根據你想要達成的效果,概述你可用的工具。 寬度、版面自動調整 如果你想要做出的效果是,畫面內各區域自動調整寬度,較窄時調整位置,我非常推薦搭配 Bootstrap Grid 與 ZK 一同使用,因為 易於整合 。使用 Grid system 只要在 div 套上 CSS class,如 col-md-4 ,因此跟 ZK 整合很容易,不需要特別的設定與程式。 元件變換 如果你希望畫面寬、窄時,各用不同的元件來顯示,例如側邊欄在畫面變窄時消失並換成小的選單圖示,這時元件本身當然無法得知要做這樣的轉換,你可以透過 onClientInfo 事件 或 @MatchMedia 來偵測畫面寬度變化,並針對該變化調整畫面元件。 更多細節可以參考以下資源: Use Bootstrap with ZK: Responsive Admin Template 範例專案 線上展示

ZK 教學 - 使用 MVC 或 MVVM?

不管是現在剛開始接觸 ZK 或是用過一陣子的人都可能會遇到的問題是到底要用 MVC 或 MVVM 的方式開發。從 ZK 8 之後又把 MVVM 的能力更佳的擴展,所以 MVVM 會是一個功能更強的開發方式。但 MVC 在使用上比較直覺,仍有其優勢,所以我想決定性的因素會比較是 開發者的偏好 及 專案的特性 。你可參考下面的比較來決定哪種方式比較適合你。 優勢比較 MVVM ViewModel 較不易受畫面變動影響。 因為 ViewModel 沒有變數直接指向 ZK 元件,因此若是畫面上有元件更改,ViewModel 一般不需要修改 ViewModel 較易於在不同頁面中重用。 因為 ViewModel 只包含資料跟業務邏輯,若是不同頁面需要的資料跟業務邏輯相同,就可以重用同一個 ViewModel 例如 A 頁面按按鈕執行搜尋,B 頁面點選單執行同樣的搜尋,則可以重用同一個 ViewModel 中的 command,只是兩個頁面 data binding 寫在不同的元件上。 畫面較易於重用(易於模組化)。 透過 shadow component 跟 template 機制,可以將一段頁面的片段做成可以接受傳入參數 套用 Responsive Design 的成本較低。 通常需要針對不同裝置設計不同版面,但是顯示的資料內容大同小異,因此 ViewModel 多半可以重用 易於套用美工所設計的畫面,或是網路上現成的元件。 易於整合第三方 javascript library 或 widget。 因為 ZK 8 提供了一個可以讓你透過 javascript 去呼叫 ViewModel 中的 command (client side binding) 的方式來跟後端溝通 ViewModel 的可測試性較好。 因為 ViewModel 不需要繼承特定類別跟實作特定介面,可以輕易地執行單元測試 MVC 操控元件方式直覺好學、易懂。 MVVM 控制元件較不直接,需要了解 zk framework data binding 的行為 可以完全使用元件所提供的所有 API。 仍有極少部分 ZK 元件行為沒辦法用 MVVM 控制。例如產生 Messagebox , Listbox.renderAll() , Popup.o