回顧這兩周左右的時間(12.08~12.24)，粗略地研究了symbian圖形子系統和camera相關領域(應用、服務、驅動)。可謂五味雜呈！
有時候感覺像攀爬絕壁，在對問題了解很少的情況下，動手開始解決問題。通常是迫於外部的壓力，無奈卻又不得不拿出赴湯蹈火的勇氣來；
有時候是「山外有山」，大的問題被分解為小的子問題，人們的眼界往往侷限在當前子問題上，因為當前的子問題比較困難，注意力集中在它上面。隨著時間的推移，當前問題的被解決，人們的焦點轉移到新的子問題，於是新的子問題被「發現」了。所謂「山外有山」，更確切的說是子問題之外或之後還會又新的子問題，我們可以經常看到子問題的系列發生；
當然大部分時間還是在徜徉在盤旋的山路上，沿著盤旋的路前進，圍繞著一些問題，從外圍到相互聯絡來逐步理解和研究。你會更全面，系統地了解問題中要素及其相互制約的規律，從而發現治「本」的方法。而這是我個人認為最佳的前進節奏。
有一種觀點認為：軟體工業是乙個schedule(進度表)驅動的工業。認為問題解決的進度需要服從於schedule。而schedule的制訂者在考慮中，商業競爭因素遠大於設計與實現(製造)的因素，這是不可靠的。而在實際執行過程又不得不因為設計和實現的困難來推遲schedule。這就是軟體工業的專案管理的根本矛盾！
那麼就有乙個問題了，可靠的schedule從**來呢？商業競爭因素是必須要考慮的，這是價值的基礎；而設計和實現因素也不可或缺，如果不能在預定時間實現，或者根本就實現不了，那就是不現實的，必定要失敗。那麼schedule的制定/修改的依據就只能是兩者的平衡。換句話說「軟體需求－設計實現」平衡決定schedule的制定和調整。當需求的數量和複雜度增加時，設計實現增加，而且大於線性增加，反之減少需要的數量和複雜度，在設計實現上就大大減少。最後得到的好處是縮短了進入市場的時間，而這會「嚴重」的影響銷售。
在軟體專案實踐中，有一些典型的情形，將在後續的文章中來逐步分析。
2008.平安夜
無窮無盡的內建函式
可惡 還有這個啊 新增元素到尾部 集合 新增元素 add 元素 記錄特定值出現的次數 count 值 刪除所有元素 clear 全沒了 刺激 del 位置 轉換成字典 刪掉啦 合併列表 extend yyy 和yyy就被合併啦 enumerate 函式用於將乙個可遍歷的資料物件 如列表 元組或字串 ...
你的燈還亮著嗎
1,搞清誰 問題的物件 有問題.2,問題的本質是什麼 大多數問題其實就是你期望的東西和你體驗的東西之間的差別.解決辦法是要麼改變期望,要麼改變體驗.3,不要把他們解決問題的方法誤認為是問題的定義 特別是在你使用自己的解決方法時 要搞清楚問題的定義 4,如果你太輕易的解決了他們的問題,他們永遠不會相信...
C程式無窮無盡的坑之一 賦值和判斷
被這個賦值 判斷 坑了好多次，下次還會繼續被坑。舉個例子 k 0 和 k 0 k 0 是把 0 賦值給 k k 0 判斷 k 的值是否為 0。1.while k 0 是把 k 賦值為 0，同時表示式的結果也是 0，所以while下的迴圈體不會執行。a b 是將b的值傳給 a,while a b 則表...