其實還是有點複雜，可以更簡化一點，就如學長說的，每個物件的存在都必須要有目的。
一般版
1920 x 1080 桌面版
昨天跟學長對話，收獲最多的就是學長說的：「每一個物件都需要有清楚的存在目的。」
我的父親工作了一輩子買了個房子跟一個山坡地，這幾十年來，任何家中或者是朋友要丟棄的傢俱、電器、大型物品，父親都會找貨車搬運到山上置放，除了山上，父親在家中還有幾個房間，堆放著幾十年下來累積的寶物。
多數的傢俱因為沒有好好保養，樣貌結構多已受損汙穢。幾十年累積的遙控器、變壓器、配件、許多過時或損毀的電器，父親不懂他們的作用，不知道怎麼修，只是都習慣留著。所以父親有很多東西，但多半是沒有什麼人想要，父親也不知道放置在哪裡，或者自己存放著哪些東西。
GTD有一個項目 Someday maybe，意思是”總有一天會做的事情“。這個設計的目的，其實是幫我們把許多的工作，挑選出不是最重要的項目，讓重要的任務能夠跳出來。
但如果我們的工作清單中，九成都被歸類成“總有一天會做的事情”，這些累積一大堆不重要的鬼任務，除了造成瞎忙的錯覺還有心中的壓力，其實對我們一點幫助都沒有。
每一個任務，都需要時間、人員、資源等成本，如果他們的回收低於成本，就都成了債務。
最可怕的，是身邊許許多多積年累月長期的債務，一點一滴暗自耗損珍貴的資源。
評估資產的時候，如果“以防萬一”的庫存與設備比例太高，是浪費的來源。進了太多“或許有人會買的”產品，如果沒賣完，所有的採購、倉儲、運送、人力成本就都浪費了。買了太多“以防萬一的設備”，如果我們都沒用，採購的費用、人員的訓練、電力與置放空間就都浪費了。如果我們的清單中“總有一天會做的事情”比例特別高，這也表示著我們的效率提升有很大的進步空間。
每一個任務都是債務，另外一個地方就是機會成本，瞎忙跟不重要的任務就像是流沙會把我們湮沒。所以，桌面、我的檔案夾、還有 Inbox都需要定期整理，“總有一天會做的事情”也需要定期精簡，挑選出來哪些事情是 1. 做了不符合效益 2. 太遙遠 3.此生無緣 或許我們可以更專注在更重要的事情上。
Origami服務的概念是要做為家族成員們之間的社群網路平台，除了我們熟悉的 Facebook文字、圖片等分享之外，特點是只有家族成員能使用，同時訂購服務之後 Origami會提供一個獨特的網址給該家族。
一如 Facebook，Origami可以讓家族成員在彼此之間分享照片、影片跟故事。每一個成員可以一起分享整理"共同的"家族聚會相簿，這一個功能倒是在其他的網路服務上比較欠缺的，各位應該都有過經驗，某一次聚會，參與的成員各自都拍攝了許多照片，我們都希望能看到彼此的照片，藉由facebook、email或dropbox方式來分享照片總是耗費許多時間，能不能有一個地方讓我們一起把照片都放在同一個地方呢？Orgami做到了。Orgami可以把 Facebook、Picasa或 Flikr的照片根據事件匯總在相簿中。
Orgami同時提供電子報功能，在每天早晨發送更新家族成員動態。而家族成員通訊錄，則是另外一個方便的通訊錄集結工具，不同於其他資訊離散的通訊錄工具，每一個人可以將自己的通訊資料放在只有家族看得到的內部通訊錄中，即便是遠親也可以取得最新由本人維護的的最新聯絡資訊，這些都是小巧、貼心且實用的功能。
除了家族專屬的網址之外，隱私性跟資料開放性也是 Origami強調的地方。所有的資料都只有家族成員才能看到，同時比較有良心的做法就是所有成員放上去的資料，都可以透過 email或 DropBox備份取出，並不會被綁在 Origami中，讓使用者可以放心使用。
以每個月 5美金，一年 50美金的費用來看，Origami是一個負擔不高且有趣的小工具。個人覺得有趣的是這樣的家族設群網路是在西方社會先做了起來，中國市場還沒看過有類似的服務。我覺得這樣的服務在小家庭普遍、付費觀念不普及加上 Facebook風行的台灣市場推起來有一定的難度，但看起來在美國市場是有存活獲利的空間。唯一一個比較保留的地方式，網站中並沒有提到任何有關資料安全性的措施，但或許是 Startups還沒提撥資源部署到這一塊，整體上我相信這是一個會成功的服務模式。
先前在看 Happy Hacking Professional Keyboard的時候，很疑惑的有幾點
1. 沒有方向鍵，那注音選字怎麼辦（是的，我還在用注音）
2. Option/Control/Command只能選二，難道左右四個 key就加上 FN這樣分配完嗎？
加上先前看到許多 Vim的使用者很驕傲的地方就是他們不需要用到方向鍵，今天 Google一下終於在 Apple官方網站上找到答案了
http://support.apple.com/kb/HT1343?viewlocale=zh_TW
[注音選字的做法]
[在文件中移動定位標的方式]
使用 Control + 的組合鍵來完成
A：跳到行前端
E：跳到行最後
B：往前一個字元
F：往後一個字元
N：下一行
P：上一行
V：下一頁
[刪除]
使用 Control + 的組合鍵來完成
D：刪除定位標前的字元
H：刪除定位標後的字元
K：刪除定位標後一行/一個段落所有的字元
[插入]
使用 Control + 的組合鍵來完成
O：定位標後插入一行
[編輯文件格式]
Command + Control + C：複製樣式
Command + Control + V：貼上樣式
Command + { ：置左
Command + }：置右
Command + | ：置中
Command + T：開啟 Font選單
Command + B：粗體
Command + I ：斜體
Command + U：底線
即便如此，我還是不會買 60%的鍵盤，對我來說太硬了，87%倒是有機會想試試。
物件導向程式設計 Object Oriented Programming第一次聽到的時候覺得好可怕，現在稍微理解一些，跟各位剛接觸 Progaming的朋友分享一下我的認知邏輯。
在圖片中我們看到三個大方塊，等於是三個層級的 Class，用一個容易理解的例子來看
動物 > 靈長類 > 人類
就可以看到上一層的 Class有許多特性，下一層的會有，例如在人類那一層可能會有其他的 class如大金剛。
為什麼寫程式的時候會想要這樣分層級呢？最大的好處是可以少寫很多程式碼。怎麼說呢？
各位可以看到圖片中的 Class後面，有functions跟 properties，先從properties來說..
動物、靈長類、人類有些共同的特點，例如，早晚會死掉。我在跟電腦定義這三個物件的時候，用物件導向的邏輯來規劃，只需要寫在動物那一個層級，這樣電腦就知道下面的物件，不論是靈長類、猴子或人類，早晚都會死掉。
所以在規劃的時候將每個物件的層級規劃好，我們可以把每個物件都共同會用到的公開資料、共同特性（限制、反映），還有共同可以做的事情（Function/Methods根據不同的語言定義有些不同，在此先不管）。就可以用來模擬許多現實生活中的資料互動規則，例如讀者都可以借書，然而我們看到每一個層級比較低的物件都可以另外定義自己專用的功能與屬性，拿讀者這個分類來說，我們可以往下建立一個教授身份的讀者，他們可以借書的數量就可以設置比較多，借閱時間比較長。
一般來說會將這種由上往下傳的屬性叫做繼承（inheritance），意思是上一層的屬性，下面會有，下面的屬性，不會往上傳。繼承的架構，有"一對一"與"一對多"兩種，我們用一個例子來重新瞭解"一對多"還有屬性不會往上傳的概念，馬跟驢他們兩種層級所產生的下一代“騾”的屬性繼承，就是“一對多”的一種表現，馬跟驢的某些特性都傳給了“騾”，而“騾”的屬性並不一定會往上傳遞。
各位可能會想，如果馬的屬性有一條“斑點 = 很多“，而我們需要定義“騾”沒有斑點怎麼辦？物件導向程式設計的邏輯是，我們這時候在“騾”的屬性定義好”斑點 = 沒有“就可以覆蓋掉上一層的包袱。用這樣的方式來規劃，我們可以從上層既成許多已經寫好的程式碼，在必要的時候加以修改下層物件的特殊屬性與功能即可。
然而對於如 Ruby這樣 1 to 1的程式語言，使用的方式則是用 mixin將其他的class的methods跟 property整合進來，或者用 require把其他原本屬於封閉的 module內容拉進去。許多人喜歡將一個大的系統給 abstract為很多很多 layer，就跟photoshops一樣，這樣往後需要抽換、刪除、修改、整合各個 layer中的程式碼，比較容易，而且不會造成系統太大的影響。
以上，報告完畢：）
網路讓我們回到嬰兒時的環境，任何感覺都可以直接發聲。
