訂定進度與追蹤的方式

1. 切割區塊，設立主題
2. 主題分析，並切割次主題，給予資源（工程師）
3. 第一次 review 要提出粗估時間，約一星期（就是每星期 review 的時間）
4. 討論與產品時間的差距，並刪減或增加主題，必須加到感覺不可能完成的狀態。
5. 每星期 review ，允許更改 schedule，必須註明原因。
6. schedule 每個主題必須包含
   
   1. study：需產出一份 PPT 說明怎麼規劃此主題 （first week），當然也可將需要study的部份額外加入
   2. implemention：需星期提交程式碼，列出主要功能
   3. milestone：需提出進度狀態以供參考，文件或程式碼 （一個主題，至少提供三個 milestones ）
   4. Integration：列出整合元件，並給予整合時間
   5. test：整合測試與單元測試時間（並不一定要有，目前想法可以合併於 implement 中）
   6. issue：列出此主題遇到重大問題，從問題發生開始計錄時間。
7. 保留每星期的 schedule ，直到專案結束，需開會表揚與檢討
8. 績效需以 schedule 為參考依據
9. 給予資源，可以依據工程師個人的興趣來選擇，但想對也必須負責另外一部份強制給予的工作

三個圈圈

昨天看到一個談話性節目，在討論父母是否該干涉小孩的興趣以及未來夢想。

自己個觀念是不要干涉，但是可以在必要時給於協助及鼓勵，因為父母的鼓勵會成為孩子完成夢想的一個很大的助力。

在節目中也提到三個圈圈的比喻，從 藥師活力網 中摘錄下面的段落：

這些問題建立在三個圈圈，天份，熱情，價值的重疊性．所謂的天份指的是你生來就應該從事這樣工作的感覺．如果有天份投入在有熱情的事情上，甚至一個人就可以改變這個社會。

如同黑幼龍說的：『一般人這三個圈圈 ，通常都是分開的，有一個交集就很不錯！當然最好是三個圈圈都能交集，而工作也落在這三個交集處，那是最棒的。』當下真的有種點頭如搗蒜的感覺，也許我們沒辦法天生就能把天份，熱情，價值交集在一起，但是經過成長學習，我們應該可以練習把這三個圈圈用各種不同的方式產生交集，這就我們該努力的方向。

不過往往我們在努力（工作）的過程中，常常都會有種很難說出的感覺，大部分的人稱這些很難說出的感覺為 " 低潮 "，但我卻覺得那是自己的內心在吶喊，努力（工作）的方向似乎跟自己想做的事情有些不同，就像是購物狂的異想世界中，麗貝卡最後不去他之前嚮往的工作邀約，反而是依據自己心理的想法，走自己認為應該走的路。也許很多人都覺得那是電影，現實哪有人有這樣的好運，可以賣出所有的東西，然後可以還債還能有盈餘，然後開始新的人生？恩！是的，有這麼好的運氣，應該要感謝祖宗八代燒好香，除了運氣以外，我們還剩什麼？


來思考這三個圈圈吧！其實我覺得圈圈的範圍可以自己決定，你可以開始作些事情讓你的圈圈產生變化。天份，與其說是自己生下來的特質，不如說是可以天天努力磨練得到的本能，專家也是磨練十萬個小時（十年）才有這樣的能力。熱情，是你可以喜歡一件事情，在做它的過程中，會忘記時間的流逝，即使到 80 歲也不會後悔一直在做這樣的事情。價值，取決於你怎麼看這個世界，這跟成長環境有關，不過也是可以經由閱讀及學習去改變的。

以前的自己，很不會處理低潮，只是覺得悶，很多事情不如預期，即使很多目標都達到，卻開心不起來。一直在思考是否生活中少了些什麼？我想，是少了些勇氣與夢想，跨出改變那一步的勇氣，以及有編織夢想的能力。

一直以來都覺得自己有，但心理知道那很虛無不切實際，原因是缺乏推動這夢想的動力，使命感不足與現實生活的種種，讓自己放不開，導致的現在的情況。也許我該練習讓自己放開，放空一切，從頭來。

2010 瞻前顧後

2009已經成為歷史，朋友們跨年夜沒辦法陪伴你們一起度過，真是抱歉，請容小弟深深一鞠躬，Sorry！Sorry！。

寫這篇文章的目的，是為了提醒自己，可以努力的時間已經少了一年，今年自己又幹了些什麼好事？來回顧一下吧！

1. Android 的出現 
• 也許是我後知後覺，我一直開始工作半年，才記起 Android 這東西的存在，這也就是我沒去手機廠工作的主要原因（根本就忘記XD），果然當兵會讓人失憶。所以今年是自己的Android 元年，因為一整年都跟它有關，不過可惜的是不算是自己的案子，名義上只能說是支援，不過可以支援接近一年也是很神奇的一件事。
• 工作上，並不覺得自己做的很好，因為總是找的出缺憾，所以今年要更努力。
  
2. 一位好朋友結婚 
• 定居馬來西亞，所以記得要去馬來西亞的時候要去拜訪她。
3. 泳渡日月潭
• 這件事情一定要提，因為很值得！連上英文課的老師都覺得很棒，哈！（其實小朋友都可以游過去，為啥？我不行？）一世人一定要去一次（台），不管有沒有泳渡成功，一定要去見識一下！
4. 參與開放社群活動
• 與其說參加活動，不如說去上課的，不能貢獻些什麼真慚愧，我會繼續努力。
5. 轉職回宅男
• 這就不要問我了，很大原因是自己造成的。
  
6. 夢想計劃書（元年） 
• 開始給自己年度計劃書，也許是想認真過生活，給自己目標，生活會比較有重心，而雖然 2009 所達到的目標只有兩個（根本是鬼混），至少是一個開始。
1. 閱讀 12 本書，並發表心得。（唸完的書約 15+，都沒寫心得）
2. 財務知識的學習與實踐。（學習知足的生活與金錢的規劃）
3. 滑雪團。（壓根忘記，想到的時候是跨年前幾天）
4. 減重。（一直有在想，但沒成功）
5. 紀錄 12 想法，並提出一個實行（有想 idea ，不過執行不徹底）

2009 已經回顧完了（都過完了還能怎樣？），看起來不太滿意啊！所以 2010 再來挑戰一次吧（剛剛被朋友說，整個超有元氣）！
 
2010 夢想計劃書

1. 滑雪團一定會成行（純，三日以上滑雪）
• 費用：三～五萬，日本
• 時間：2010/12~ 2011/2月（農曆年前）
  
• 跟團：請開始存錢（一個月 3K ~ 4K ，想實現夢想總要付出些什麼，對吧！）
  
2. Android/iPhone 上的 application project 
• 這是寫好玩的，順便學習。
3. Linux 實做練習
• 是非常基本的學習
  
• 也是貫徹 J大說過的 "作中學"，並發表出來在 blog 中。
  
4. 放空假期
• 一季一次
• 整理計畫進度
• 處理方式思考
  
5. 12 本書 （4 本心得文章）
• 今年要雪恥，一定要有產出。
• 減少心得文章的產出，保持產出水準（其實是偷懶吧？）
  
6. 12 想法 （4 個整體想法，一個可實現作法）
• 為了保持腦袋的靈活度
  
7. 2 個展覽或藝文活動
• 保留一點藝文氣質
8. 財務知識的學習與實踐
• 練習持續做的能力
  
9. 盡量不加班（八點到公司，八點前下班）
• 保持有效率的產出。
10. 認識同好
• 有夢想的人

以上，報告完畢。2010 加油！

SimpleSDK and Xcode

這是一位12歲大的小男生，在 youtube 上的 Xcode 教學，教你如何使用 Xcode 寫你的 iPhone App，不但口齒清晰，整個流程都很流暢，整體看起來很棒。

從影片中，約略可以知道 SimpleSDK 對 php 及網頁相關的技術似乎還有一點了解。剛開始的時候有些不敢相信，一直覺得這是位女生，仔細端倪後才發現是個非常專業的小朋友。也許是因為 Xcode 的設計還不錯，讓買 Mac 的使用者都可以很方便的加入寫程式的行列，並 publish program。

看到這影片真的是讓我大開眼界，那種震撼的感覺一直到現在都還在。
只能說，自己要努力啊～

參考：
http://blog.simplesdk.com/
http://www.youtube.com/user/SimpleSDK

週年紀錄

工作滿一週年，留個紀念。

雖然工作上所發展東西，並沒有如自己所預期的順利。但也算差強人意，不知是自己能力不足，還是其他的關係。也許作 project 與買股票一樣，不能放太多主觀的熱情，才不會有太多失望。不過我並不喜歡這樣，因為喜歡才有熱情，才會有出乎意料的成果，如果只是做完該做的事情，這樣是不會傑出的，產品也只會普普。

瞭解自己是個龜毛中人，有時候某些地方不對，打死就是不願意這樣做下去。最近接觸比較多真正在寫 code 寫歷史的人，有種好嚮往的感覺，也許不知不覺自己就會往這樣的方向去發展。畢竟熱情才是最重要的一件事情。沒有熱情，有在厲害的技術，也只是浪費，因為往往不知道該如何利用才會發會最大價值。

期待下個年度，可以達到自己給的目標，不只在公司專案上有成長，自己有興趣的回家作業也可以有漂亮的成果。加油～

Graphic and Reality World

最近一頭腦的栽入了 Linux Graphic and OpenGL/ES 的世界，不過也是因為工作上的需要，才會有機會這樣去實際瞭解 Graphic 的發展現況。

在 Linux 上的 Graphic 其實頗有趣，尤其是看到 OpenGL Demo Program 執行後的效果，更讓人覺得興奮（是我太久沒打 Game 的關係嗎？），雖然只是簡單的機器人或是茶壺的旋轉，但是仔細看程式後，發現這都是一行一行的程式碼，除非需要貼圖的動作，才會有額外的圖片，所有的動作都是以程式的方式動態繪出。

目前需要瞭解的方向可以分為：

• MESA 3D Library
• Gallium3d Driver Architecture
• DRM and DRI
• OpenGL/ES and EGL

雖然對這幾個部份都有一些涉獵，但是還是覺得看 Code 的速度還是不夠快，如果可以更快的測試並作修正，也許瞭解的速度會比較快。
另外可能是生性孤僻，比較不知道應該如何跟 community 透過 mailing list 溝通，所以想對特定的 project 作貢獻的機會也就比較少。

看到 0xlab 在 Android 上面的貢獻，發展了很多的東西，而且品質很不錯。改寫的速度之快，讓小弟很慚愧，期望哪天我也能進步到這樣的程度。

雖然有時工作上得想法並不會得到認同，但是還是希望能作些有用的東西，且是自己會期待事情，也許對自己不會有太多益處，但那樣沈浸思考與挑戰的過程，是工程師在暴風下的避難所。回歸原點，找到自己的熱情，以自己的方式出發，並為自己的決定負責，會是很有趣的人生。

[Study] Linux Graphic

安裝 ubuntu 9.04 後，發現畫面顯示的部份比原本預期的好很多，而在 xp 上並沒有這樣的表現，而且記憶體的使用上也更精簡，開完機記憶的使用約 256MB （原本打算多弄點 ram 來使用，看來可以省下一筆費用）。所以開始對畫面的顯示有點好奇，也想深入了結一下。所以開始我的 Graphic 學習之旅。

觀念文章，下面這些文章都是在 Debian Taiwan irc conference 的資料，主講人為 jserv，很精彩，對 Linux X11, OpenGL, 等有關 Graphic 的議題，有很深入的討論。建議花時間閱讀。
FreeDesktop.org 與 X.org 嶄新發展概況
FreeDesktop.org 與 X.org 嶄新發展概況(續集)
Xorg 嶄新的硬體加速與效能提昇機制
Xorg 嶄新的硬體加速與效能提昇機制 (續集)

The State of Linux Graphics

在 Framebuffer實現與應用 提到

但Framebuffer本身不具备任何运算数据的能力,就只好比是一个暂时存放水的水池.CPU将运算后的结果放到这个水池,水池再将结果流到显示器. 中间不会对数据做处理. 应用程序也可以直接读写这个水池的内容.在这种机制下，尽管Framebuffer需要真正的显卡驱动的支持，但所有显示任务都有CPU完成,因此CPU 负担很重.
framebuffer的设备文件一般是 /dev/fb0、/dev/fb1 等等

參考文件

• Linux Framebuffer Howto
• Framebuffer tools
• Framebuffer實現與應用