Posts

消基會抽查預付卡100%違規設使用期限,NCC:將要求業者改善

這是鬧劇嗎?兩邊都是笑話。

電信公司給預付卡一個門號跟維持一個門號是有成本的,為什麼 NCC 可以要求業者要無限期的維持一個沒有使用中的門號,設使用期限或者是有每月低消本來就是很合理的事,中華民國政府的 "行政單位NCC" 竟然可笑的定了這種 "規定" 出來。

更可笑的是, NCC 自己定的 "規定" ,卻連自己都不去強制遵守,要求業者遵循規定。

「上下交相賊」,上個求個美名所以定個便民的規範,但是卻不去執行,把責任推給商家,真是好個「儒家社會」啊

消基會抽查預付卡100%違規設使用期限,NCC:將要求業者改善 消基會抽查國內11件預付卡商品,發現100%都違反規定設有使用期限,應記載資訊也沒有完整詳細說明,NCC表示將進行查核,督促業者依規定落實改善。

文/蘇文彬 | 2014-03-14發表

消基會抽查11件電信預付卡商品,發現全部違反國內電信禮券定型化契約規定設定使用期限。

消基會調查電信業者推出的預付卡發現,預付卡雖然免綁約,且提供消費者控制通話費,但都訂有使用時間限制。對此NCC表示,電信儲值卡不應限制使用期限,將督促業者改善。

消基會這次一共抽查11件預付卡商品,其中7件為金額儲值型,4件為計量型上網儲值卡,並依據「電信商品或服務禮券定型化契約應記載及不得記載事項」不應限制用戶使用期限的規定,檢視抽查的預付卡服務內容說明是否有違反法律規定的情形。抽查的預付卡銷售商包括遠傳、台灣大哥大、中華電信、威寶、亞太、家樂福、7-Eleven等。

結果卻發現抽查的預付卡商品全部都設有使用期限,用戶每次儲值需在一定的時間內使用,業者通常限制為180天,上網儲值卡更只有30天,用戶在期限內再次儲值才能再展延180天或30天。

消基會指出,抽查的預付卡100%違反規定,並非消費者儲值後就能一直使用到儲值金額用完為止。一般購買禮券不因只消費部份金額,就被要求將剩餘金額在一定期限內消費完,但電信儲值卡卻有使用期限,除非再次儲值才能延後使用,但儲值金額用不完還要消費者再儲值才能繼續使用並不合理,且違反規定。

預付卡儲值金額若在時限內未使用完,部份電信業者可以申請退費,但部份業者規定只能辦理移轉,將預付卡內剩餘金額轉移到同一家業者月租費門號帳上,若用戶超過6個月沒有申辦轉移,剩餘儲值金額會保留,但會收取保管費直到扣完為止。

除了使用期限,消基會也發現其他資訊,例如業者名稱、地址、發售編號、履約保證、餘額處理方式、遣失處理等資訊在包裝或業者官網上說明不夠明確。

消基會表示,「電信商品或服務禮券定型化契約應記載及不得記載事項」在2007年通過,該年6月消基會首次抽查即100%違反規定設定用戶使用期限,今年再再次調查仍是100%違反規定,部份業者甚至規定屆期金額歸零,NCC應加強督導業者,消費者選擇儲值卡也應注意業者相關規定。

對於消基會抽查預付卡結果,NCC回應,依電信禮券定型化契約規定,逾期未使用完的傳輸量,用戶沒有特別聲明,應自動用以折抵通話費。消費者購買預付卡為不記名的禮券商品服務,依規定不得限制使用期限,NCC將會督促業者落實規定改善。

從壓力測試回想到一些老故事

最近壓力測試因為 戶政系統 的原因,上了幾天的新聞,講到壓力測試,就想到我這輩子職場上的一個恥辱,把一個產品搞倒的紀錄。

2007 年我還在 Rhapsody.com 時,當時我是擔任我們 webservice api 的 QA Lead ,做一個有 40 個內外部客戶的服務的守門員,每一次的產品更新,都要我跑完了數萬個測試,說可以出貨了才可以出貨。

四月時忙完跟 Tivo 的合作案,把系統的負荷量測到及調整到可以服務 500萬線上用戶的量後,另一個團隊又開發了新的 social 網站。

那是 facebook 才上線三年,或者說才對外公開服務的第一年,當所有人都還不知道什麼是社交功能時,rhapsody就已經開發出來社交功能,可以互相推薦音樂清單、可以 follow 別人、還可以自定 avatar

在上線前,我問了我的主管的主管,需不需要對 social web 的上線做測試,當時大主管是說不用。沒想到一上線,這 social web 非常的熱門,一下子就有數萬個用戶從標準的頁面轉換到 social 版去,似乎,一個新的 killer app 就要產生了。

然而才上線兩三天,網站的速度就慢了下來,後來才知道,原來 social web 濫用了我們的一個 GET api ,我們的 GET api 允許一次抓多個 object ,結果 social web 一次一個 request 就抓了 500 object ,一個 object 4k 就好,一次就抓 2MB ,在加上 object serialization 中間所花的記憶體空間,一個 request 就要佔 6MB 以上,一下就把那個年代的 server 打垮了。

就這樣,這個 social web 就下線整修,但不知為什麼,就此沒有再上線過了....

Mongodb vs MySQL/RDBMS

許多人從 RDBMS 跳到 NoSQL 的第一站都是 MongoDB ,所以這一篇,就是特別寫來解釋,為什麼很多人選用 MongoDB ,以及解釋你為什麼不該用 MongoDB 來換掉 RDBMS 。

MongoDB 熱門的理由

MongoDB 熱門的原因是因為他提供了一個可以跟 SQL 相比的 Query Language ,在 NoSQL 不同面向的眾多方案中, MongoDB 所能支援的 AdHoc Query 是沒人能比的, Riak 跟 CouchDB 的 AdHoc Query 也不差,但是 Riak 在跑 MapReduce Query 時是不能透過 index 加速的, CouchDB 則是跟本不支援 index ,所以在這邊 MongoDB 看似 是個很好的 MySQL drop-in replacement

使用 MongoDB 來取代 MySQL ,在初期,看來是學習成本最低,轉換風險最低的解決方案,所以多數商業公司,為了降低風險,在追循潮流一窩風的採用 NoSQL 時,選擇了 MongoDB 這個看似合理且安全的選項。

然而糖衣底下掩蓋的,卻是數不盡的陷井在那。

Trade-Off

技術的選用,往往是一連串的取捨,拿某樣功能去換回了另一項功能,所以,接下來我們就來看看,我們從 MySQL/RDBMS 跳到 MongoDB 去,我們到底是跟魔鬼做了什麼樣的交易,拿了什麼樣的東西,去換回了什麼。

首先,我們先看看我們換出去的是什麼?我們換出去的是 ACID (Atomicity, Consistency, Isolation, Durability) 及 Relational Model

ACID

對絕大多數的應用來說,交易的正確性跟不可否任性,是系統必要的基石, ACID 便是協助達成這一目標的工具之一。

ACID 雖然是一大重要工具,但也不是不能夠取代,像是 CQRS PatternCassandra Summit 有一個很好的講題就是介紹怎麼用 Cassandra 透過 CQRS 來寫一個給銀行用的轉帳系統。

SAGA Pattern 則是另一個在沒有 Transaction 下,來解決多事件互動的 Pattern 。

然而 CQRS 或 SAGA Pattern 都沒有 Transaction 好用,以及廣被眾人所了解,連我自己都只是讀過沒有親身實作過,要做的話,連底層的工具都要自己從頭開始作,或者是要去學一些非常新的工具如 Datomic

因為換出的是 ACID 這樣強大的工具,替代的方案又是高未知的空間,所以許多人最後選擇的替代方案就是 -- 頭埋起來假裝沒有問題

而且 MongoDB 本身號稱的 BASE 跟本是 Eventual Inconsistency ,在 Call me maybe: MongoDB 這篇文章中就驗證到,當 Network Partition 發生時,既使 MongoDB 回復寫入成功,但是實際上還是會失敗的,所以就在這種底層實作不可靠下,你上層加什麼工具也是枉然,所以多數人就是假裝沒這回事,想說自己沒這麼倒楣。

Relational Model

Relational Model 是三十年前那次 DB 戰爭中,打敗 Network Model, Hierarchical Model 剩出的王者,在三十年後,再次受到 Document Model 的挑戰,這次的結果如何呢?

Relational Model 的好處是可以透過正規化,減少資料的重複、提高資料的一致性,以及透過 SQL ,除了 AdHoc Query 外,還可以對多個 Table 進行 Joined Query,這個是 MongoDB / Document Model 所做不到的。

那這個特性重要嗎?我想透過一個例子就可以很簡單的介紹 Relational Model 的強大,跟 Document Model 在應用上會碰到的問題。

Relational Model Example

我們公司是做人肉搜索的,對於同一個人 / email 來說,我們會有很多來自不同來源的 metadata ,今天假設是兩個來源好了。

在 RDBMS 中,就是開兩個 Table ,各自記錄不同來源來的資料

| TableA        | Email         | likes      |
| ------------- |---------------| -----------|
|               | billg@ms.com  |  1600      |


| TableB        | Email         | tweets     |
| ------------- |---------------| -----------|
|               | billg@ms.com  |  9999      |

在 Document Model 可能就是用一個 Document 如

{
    email: "billg@ms.com",
    likes: 1600,
    tweets: 9999
}

在 Query 時,前者要一個 join 才可以取回關於這個 email 的所有資料,後者則是一個 lookup ,自然後者的效率較好,而且同樣可以對不同的欄位下 Query 條件。

然而,既然要用 NoSQL 就要玩 BIG DATA ,所以我們把問題修改一下,我們從兩個來源,分別拿到十億筆 email 的 likes 數,跟十億筆 email 的 tweets 數,我們想把這些資料寫到 DB 去再拿回來用。

用 RDBMS 自然是輕鬆愉快,兩個檔案輪流打開,一筆筆的加到 DB 中,DBMS對這種簡單的寫入可以做到 10,000 insert / sec 沒問題,大概 55 分鐘就可以做完了。

但是 MongoDB 呢?因為兩個屬性都是在同一個 Document 上,所以要馬是先把十億筆 (email, likes) ,先寫到 MongoDB 中,再下十億筆 Read + Update 把 Document 讀回來再加上 tweets ,如果很不幸你的 Document Id 不是 email ,那就是要下十億筆 Search + Update ,不管怎麼算,都不是太漂亮。

另一個作法是,你先把兩個十億筆的資料在本機的記億體中做 join ,然後再寫到 MongoDB 去,ㄜ... 這樣搞你不覺得累嗎?這麼小的應用問題就要自己動手刻程式碼,而且 前面我們不是說 big data 嗎?如果資料不是十億筆而是一百億筆,你放不進記億體中,那你要先用 radix sort 寫到 file system 再讀回來嗎?

然後你忙了這麼多後, MongoDB 給你的,因為 global write lock ,還是一樣是 10,000 insert /sec ,然後因為 MongoDB 實作的問題,如果你的 Document 有 indexed field ,那麼寫到兩百萬筆後會越寫越慢,這問題在成熟的 DB 上是沒有的。

我想,這個小例子就說明了 Relational Model 的強大之處及 Document Model 弱的地方,當你要既有的資料新增欄位時, Relational Model 是可以很簡單的增加一個 column 或 table 就做到,在 MongoDB 上,則是要跳過重重關卡才可以達成。

在軟體需求不穩定時,或常有變更時 Relational Model 對變革的適應能力,較 Document Model 高出許多。

MongoDB 的長處

在交換出 ACID對Model 對變革的適應能力 後,我們從 MongoDB 到底換回來了什麼呢?

  • cluster 帶來的更多的儲存空間
  • cluster 帶來的更 scalable read operation.
  • 在某個資料大小下,一個非常快速的 index

前兩個長處就不用多談了,Opensource RDBMS的長處並不在這塊,跟從一開始就要做 cluster 的 MongoDB 是沒得比的,MongoDB 目前已有超過 100 node 的單一 cluster。

第三個先略過不說,等說完結論再回來說

結論

我們看完了 Trade-off 後,我們要來思考一下,我們這個交易到底划不划算?

對我來說,我們換出了 ACID 跟 對Model 對變革的適應能力 後,我們換回來的僅僅只有 Scalable storage & scalable read , 就我看來,這是一筆極差的交易,因為這個換回來的東西大多只能應用在一塊很小的地方,一個需要大量儲空間、一個需要大量讀取能力的應用,而且後者還可以被 cache 所取代。

前面講的 在某個資料大小下,一個非常快速的 index 就是指這個應用範圍, Navigenics 的 Dick Wall 就講過,他曾用 MongoDB 用來儲存要配對的 DNA Sequence ,他的資料大小,剛好是大到無法用 Redis 放在記億體中,但是 index 的大小剛好是可以透過 MongoDB 全部放在記億體中,剩餘的資料則是存在硬碟上,就這麼剛好透過 MongoDB ,在下複雜 Query 時,他的搜尋速度可以達到 MySQL 方案的一百倍。

然而,真正 big data 的應用,如 log storage & analysis ,MongoDB 是無法達到對 write operation 的需求的。 MongoDB 能適用的問題空間實在太小,而且既使你目前的需求是在 MongoDB 能達到的範圍內,但需求一變化,就長到 MongoDB 無法承擔的空間去了。

這也是我未來不會採用 MongoDB 的原因,在小量資料時,我會用 PostgreSQL / MySQL ,在資料量大時,會用 Postgres + Cassandra + ElasticSearch

附注

既然我說 MongoDB 的這筆交易不是個好交易,那什麼是好交易呢?

我覺得 Cassandra 這個就是個好交易,我們拿 ACID, AdHoc Query 出去換。是的我們把 AdHoc Query 都拿出去換掉了,換回來的是一次只能問兩個問題的 Query ,而且這兩個問題還是在 Table Design 時就要決定的。

但我們換回來的是幾乎無上限的 Read & Write operation 能力 ,在Netflix 的測試中,Cassandra 單一節點可以有 10,000 rw/sec ,然後一路隨著增加到 288 個節點,每加一個點可以增加 10,000 rw/sec 。

這個才是我說的好交易,因為這個特殊能力,是其它解決方案都辦不到的;雖然說我們交易掉了 ACID & AdHoc Query ,但是透過適當的 Table Design , Cassandra 的特性剛好可以用來解決 Big Data 中 log storage & analysis 這個大部份人需要解決的問題。

Mongodb - Schemaless

我覺得大家對 MongoDB 誤解最大的地方就是 schemaless , schemaless 應該是個大問題才對,不知道為什麼世人都跟 billg 一樣,把問題當做優點來看。

Schemaless 的優點

Schemaless 不是沒有優點的,在搭配上動態語言時, Schemaless 是個很好用的功能,不用設定 mapping configuration ,直接就可以打 item?.some_collections[0]?.city 就這樣一路對一個物件逛下去,不用為了新增一個欄位就要去改 mapping configuration 然後跑 db migration。

然而,這個特點,只有用在有 safe navigation 的動態語言上,才能享受到這些好處,要不然還是處處都要寫 null check ,要不然就會因為讀到前一版的 item 缺少某個欄位,而噴出了 NullPointerException。

Schemaless 與靜態語言

在靜態語言中使用 Schemaless DB 時,schemaless 的好處就消失怠盡了,像是我們公司是用 Morphia 來寫 Model & DAO 的,若是要新增一個欄位,免不了是要去更新 Model class 然後重新 compile & deploy 才能加上一個欄位的。

相較於使用 Schemaful DB ,我們省下的,只有跑 DB Migration 的時間,當然,若是你有個超大的 DB ,那這省下的 off-line maintenance downtime 也可是很驚人的,但是,並不是所有的 db migration 都是要把整個系統下線才能跑的,大多數的 db migration 都是會把系統設計成(對DB)向後相容的,所以不用把整個系統啦下線就可以跑。

對DB向後相容的 Application / 向前相容的 Schema :這邊指的是,先不要更新 Application ,先把 DB Migration 跑完,把資料庫的資料跟Schema更新完後,才把新版的 Application 上線。所以在某段時間內,是舊版的 Application 對著新版的 Schema 在跑的。

Schemaless 的問題

許多大系統用 Schemaless DB 的原因是因為不想因為跑 DB Migration 把整個系統下線,所以就用 Schemaless 的系統來避開這問題。

但是我想說的是,這誤會可大了,就像前面講的在 Schemaful DB 中,向前相容的 Schema 變動,是不用把系統下線就可以跑的,只有向前不相容的,才要跑 Offline DB Migration 或 Online Data Conversion.

Online Data Conversion 指的是,因為前後 Schema 不相容,所以開一個新的 Table 給新版本的物件用,每次讀取一個物件時,先去檢查是否已存在新的 Table 中,若沒有,則是從舊的 Table 讀出來,把格式更新,再存到新的 Table 中。

如此一來,就不用下線也可以把前後格式不相容的的 DB 更新。

前文所說的 db migration & online data conversion 就是 schemaless DB 的大問題,除非你是 ,Model 一次就設計好,可以用一輩子,要不然不跑 db migration ,在你的 DB 中,必然會存在著 V1, V2,V3...Vn 版本的物件。

不跑 db migration ,那就表示你要維護可以對 V1, V2, V3....Vn 存取的 Model class ,你可能有一個 db item 一整年沒被讀取到,但是一年後突然用到,你要怎樣保證還讀的回來呢??

最常見的做法就是,不去 大幅度 更新 Model ,削足適屨,既使你知道更新 Model 會讓你未來程式更好寫,但是因為不能去更新 Model ,那就只好去調整程式邏輯,癟腳的用不合適的 Model 來做新工作。

而既使你想跑 db migration ,但是因為 schemaless db 跟本不打算支援 db migration ,所以不會內建任何工具來幫助你,你只能很苦命的自己刻 online data conversion 的工具了。

後記

如果你對 DB Migration 的幾種方式有興趣的話,我建議你花一小時,把 Martin Fowler 與 Pramod Sadalage 的 Agile Database Development 聽完

MongoDB - Sharding

Sharding 是一個我非常討厭 MongoDB 的地方,在多台 DB 的解決方案中,免不了要用一個方式來決定那個 object 該放在那台機器上,一個解決方式就是用某個欄位來當 shard key 。

在 MongoDB 中,這個 Shard Key 一決定後就不能改了,然後 MongoDB 會幫你把 object 按 shard key 的值域,平均分配在 n 台機器上。

問題是,平均分派值域並不代表值會是平均非配的,例如 email ,因為姓名是集中在幾個字母上的,所以按值域分派會有 hot spot 產生,a-d 的特別多人,然後 x y z 的沒有人。

在其它的 DB 中,每個 shard 機器所負責的值域是可以讓 dba 去調整的,但 MongoDB 是不行的,所以必然會產生 hot spot 而且你無法去躲開。

有些人會自己去產生 UUID 來當 shard key ,在 MongoDB 2.4 中,則是加入了 hashed shard key 自動幫你把 shard key field 拿去算 hash key 出來當 shard key 用。但是,這還是免不了某些值域是 hot spot 的問題。

既使 MongoDB 能夠平均分派儲存的值域,但是最終我們要看的是,怎麼樣平均分派 read/write operation 。

因為在讀取時,也會發生因為某些原因,讓使用者對某些 object 的存取較其它物件多出 n 倍,所以每個 shard 所負責的值域一定要是 tunable ,要不然遲早一定會出問題。

所以,扔了 MongoDB 吧

QNAP Sucks

是我太多年沒裝機、還是這年頭的機構設計師都是天才?高高興興的把新買的 QNAP TS-212P 打開來,嗯... 好樣的,竟然沒有說明書。

好吧,就自己硬幹了,開始裝第一顆硬碟,右側索好兩顆螺絲後,換鎖左側,好樣的,孔位對不上!那就鎖一側好了。

先插排線,嗯...,怎麼 接頭卡到機板身上別的零件了,那這樣不是變成只能插一顆硬碟。2 Bay 的機種只能用一個是怎樣。

/images/2014-01-26/qnap-1.png

算了,先換另一個位子,先開機起來試用再說。

硬碟換到另一個孔位裝好後,再插一次排線 ,嗯,這次接上去了,換插 SATA 排線,嗯,線好短,應該夠長吧。

結果夠長是夠長拉,可是硬拉到那接頭的上下面是反的,所以又不夠長了。

/images/2014-01-26/qnap-2.png

靠,裝個機碰上三個設計問題是怎樣,浪費我時間

更新:

經過 Google 大神的指引,原來第一顆硬碟是要插到我卡到的地方去的 Orz... 第二顆硬碟,硬拉,線是剛剛好夠長的

http://forum.qnap.com/viewtopic.php?f=11&t=87993

http://i41.tinypic.com/notyf5.jpg

德國人為什麼強大

德國人為什麼強大,沒空看影片的,這邊做個簡述

  1. 德國男人 6:20 就起床,八點半上班,工時八小時,內含午餐一小時,下午四點半下班,就可以回家過家庭生活
  2. 德國人上班時不可以玩手機 fb ,就是認真幹事,沒有休息或發呆的,有空閒就是主動多抓工作來做。
  3. 德國工業還是採學徒制,公司都是做很專門的小事,做到世界第一。雖然沒有明說,但類似日本的終生僱用制,讓員工能夠專心的精進技能。
  4. 德國人對穩定的重視高過個人福利,薪資成長跟 CPI 一樣而已,為了成就團隊,個人可以什麼雜事都幹
  5. 德國女人在小孩三歲前都是全職家庭主婦,一天花四小時在家政上,剩下來時間花在調教小孩,讓小孩及早養成良好的生活習慣。
  6. 德國特有的森林幼稚園,就是把小朋友帶到森林去跟自然環境玩,發揮想像力,自己動手就地取材作玩具。
  7. 德國的小朋友上學,八點上課,下午很早就下課,一週有三天是在中午前就結束。

我的心德是,日德兩大工業國家果然有很多相似的地方,如勤奮重紀律、終生雇用、職人導向,德國還加上了重視家庭生活( 日本男人沒這麼爽 ),但相反的就是女性沒有什麼自主權。

project-manager-and-product-manager

矽谷為什麼是矽谷 - 談中小企業放款

自從加入新工作後,對新創公司的體會又多了一些,由其是在行銷找案子上,發覺台美兩地有很大的不同。

在這邊,我覺得很大的一塊差異就是在資本市場及資訊流這一塊,銀行的業務有六大塊,除了大家熟悉的幾樣 CB IB 外,有
  • Retail / Commercial Banking 做一般存放款、房貸業務的
  • Investment Banking 協助大型公司賣公債或是 IPO 的業務
  • Merchant banks 銀行的自營商部門
  • Private Banking 資產管理
  • Private Equity 銀行自己介入對中小企業經營的單位
  • Small Business Banking 對中小企業從放款的單位,也是今天要講的重點。

我工作的公司算是 A 輪之前的公司,只有老闆及一些天使投資人投資,資金就放在我們的銀行當中,同時,我們的銀行同時也是我們的投資人之一。

我們許多的合約,是透過我們的銀行拿到的,甚至一些併購案,也是我們銀行仲介來的;我們合作的中小企銀有多放款的對向,為了確保債權回收,所以會當做資訊流通的中介媒介,幫忙介紹一些潛在的客戶給我們。

而我們有幾個併購案,其實是其它跟我們銀行貸款的公司,在撐不下去倒閉時,銀行為了回收債權,所以開始兜售公司資產而找上我們的,銀行把公司的數位資產、商務合約、及人力資源拿來兜售。就這樣,我們用幾成的價錢買下了幾張商務合約。

有趣的是,往往自己的商務合約不夠多,但是多收幾間公司簽下來的合約,湊一湊,反而就可以賺錢了 :)

信用貸款

我曾問過台灣的銀行的中小企業企業處,有沒有在經營「企業資訊交流」這一塊,答案是沒有;我猜想原因是台灣這邊銀行不流行信用貸款的因素。

在國外,新創公司是可以靠跟銀行長期的合作,慢慢的累積信用,拿到不少的信用額度,讓公司可以做短期的資金調度,像我前公司就跟銀行有「六百萬美金」的額度可以調動。

對「信用額度」不熟悉的,可以假設你是一間餐廳的老闆,平時就是早上買東西進來晚上賣,賺點微薄的利潤;但是今天碰上過年,休市五天,要增加庫存但沒資金怎麼辦;這時就是可以靠過去跟銀行的往來,靠著信用就跟銀行借資金來週轉。

當然這信用額度不是你可以一次拿太多來用的,若是你一次提領太多,銀行就會把額度收減。

由於這些貸款是信用貸款,所以若是公司倒閉,公司的股東老闆是不用負責承擔的 \(O_O)/~~ 但是為了下次再跟銀行借到錢,公司的老闆在公司倒閉時,也會收尾收的漂亮的;像是幫買下公司資產的公司再工作個半年,讓資產的轉移順利進行。

在台灣就沒有這一回事了,中小企業放款,還是多是要求企業的經營者,用個人資產(房子)做抵押,因為公司的債務受到了保障,自然就沒有放那麼多心力在仲介客戶業務、確保債權能回收之上。

另外台灣多是製造業,只要有機台就可以生產可以搶客戶,商務合約不值錢,所以不能當成公司資產來看。

題外話

我猜想美國能有這麼多信用貸款而台灣沒有的一個原因,是因為台灣不是國家,因為台灣無法跟外國遷引渡條約,要是有人用信用貸款弄了幾千萬台幣,人卻跑到中國或美國去,那銀行就無法回收債權了,因此都會要求要用不動產設定抵押

結語

矽谷就這樣,不只是技術流通的快,商務資訊流通的速度也快,因此,才造就了創業的土壤。

不知道台灣這麼多銀行,那天才會有一家跳下來開始玩「資訊服務產業放款」的這一塊,除了資金外,也做資訊傳播的中間人。

個人財務部落格

上週 數說台灣 有一篇部落格文章影起很大的迴響,我轉到 fb 上,後來被 @deduce 推坑, 問說有那些個人財務部落格可看,因此,就把我剛出社會時的理財經驗,寫成部落格文章,記錄我逝去 的青春

支出項目

記得我剛在美國出社會時,第一份工作是透過介紹找來的,在軟體公司當 QA ,只要是非線上的系 統,全歸我管,雖然沒人帶我,但自己也玩的非常愉快。

但是當時領的是矽谷的 22K ,有一次知道矽谷的貧窮線是在年薪四萬五美金以下,若是收入低於這個數字, 可以領許多的補助,其中之一就是房屋補助 Affordable Housing Program ,如果拿了這個補助,我 可以住到更大的房子跟每年省下至少五千美金的房租。

  • /images/2013-11-10/apartment_1.jpg
  • /images/2013-11-10/apartment_2.jpg

當時的支出明細大約如下,當時租的公寓占去了收入的快半數,另外還有三成花在外食跟週末的愉樂費用上, 算是個標準的月光族吧,既然是月光族,就沒什麼財好理了,當時也沒什麼理財目標,搬到一個人生地不熟的 地方,跟戴董事長說的一樣,理財的目標是多認識一些人。

  • /images/2013-11-10/spending_2003.png

在美國生活的一個好處是,記帳超簡單,因為消費多是透過信用卡,銀行可以透過分析,直接告訴你你每個月 花多少錢在那一個商家及那一個類別之中,所以記帳的工作變的非常的簡單。每個月的月底登入網路銀行,把 這個月的支出明細看一遍,如果銀行幫你支出的類別有錯,例如外食支出認成雜貨採購,那麼你只要點幾下更 正,下次到同一家商家消費時,銀行會記住你上一次的分類,所以一段時間後,記帳的工作就變的很自動化了 ,跟本不用去做分類。

  • /images/2013-11-10/boa_yodlee.png

個人理財的第一步就是了解你的支出項目

控制支出

工作了一年後,因為景氣大好,被挖角到另一間公司去,薪水一次加了六成,開始拖離貧戶生活,手上寬裕不 少,然而那時候就理解到人有兩隻腳、錢有四隻腳,若是賺多少花多少,那麼,一輩子就只有被錢追著跑,所 以財務目標的第二課是「控制支出成長在 5% 一年」

當時除了