敏捷軟體開發宣言：
個體和互動 勝過 過程和工具
可以工作的軟體 勝過 面面俱到的文件
客戶合作 勝過 合同談判
響應變化 勝過遵循計畫
今天看了robert martin的ppp一書的第一部分，敏捷開發
回顧了自己曾經加盟過的幾個公司，經歷過的大大小小的專案，感慨良多。
這些公司中不乏奉過程開發為寶典，甚至有的蹭破頭皮為cmmi而設計一些開發流程，文件規範。
還有一些則奉敏捷為信條，當被指責**注釋不夠，文件缺乏的時候，這些大俠們就會搬出本文開頭的敏捷宣言。
我的想法是：
1.敏捷和過程其實並不矛盾，甚至是相輔相成，當過程開發給大家帶來好處的時候，敏捷這個詞語還沒出生呢。
2.敏捷其實是對過程的撥亂反正，當cmm/cmmi在大公司流行的時候，我身邊很多在某某知名軟體公司工作的同學，朋友就向我感慨道，他們的上班太沒意思了，基本上就是寫文件，很少寫**，甚至冗長的流程讓他們失去了往日的激情。。。其實敏捷並不排斥過程，只是敏捷更注重結果，人的作用，團隊的力量，而不是該死的條條框框。
3.有時候敏捷未必行得通，比如敏捷提倡當用例太多無法在規定時間完成的時候，就去砍需求。比如不提倡加班，勻速的進行開發。但是我認為這裡面的主角往往是專案經理以及更上層的老大，如果他們不能為團隊創造出乙個敏捷的氛圍的話，那麼這些想法就是白搭。
總之，不管是敏捷還是過程，我們的最終目的是可執行的軟體，良好的質量，良好的維護性。而創造這個最終成果的，是整個團隊。所以，乙個成功的專案背後，往往是一群凝聚力極強的人，以及乙個或者一群思維活躍的領導者。
結論：
任何一種思想都值得被尊重，沒有好與不好，只有是不是適合你。請以一種平常心對待任何有想法的東西，而不是去一味奉承或者一味貶低，尊重別人也是對自己的一種尊重。
關於OCR，一些想法
ocr一般分為兩種 1，根據給定的字元特徵集合，提取未知字元的特徵進行匹配識別 典型例子 gocr 2，不知道字元特徵，但給出提取特徵的規則，通過機器學習training來獲取某個字符集的特徵集，對未知字元進行匹配識別。典型例子 tesseract 第一種方法簡單，在某些場合很高效，但比較侷限，字符...
關於tv app的一些想法
以前是做iptv機頂盒的，現在是做網際網路電視機頂盒的，在技術上的區別是不大的。通過這些年與電信，廣電打交道，現在對產品有了一些小想法。那麼在顯示上都是以web為主，用web來顯示epg內容，用osd來顯示狀態。但是隨著android的出現，現在大部分機頂盒或電視劇集廠家，都開始了智慧型之旅。乙個是...
關於 Apple Metal API 的一些想法
更方便和友好的多執行緒 gpu 渲染支援 gles 的設計，所有東西都必須跟乙個 gl context 繫結，由 gl context 內部所控制的狀態機驅使，而 gl context 又跟單個執行緒本身緊密繫結在一起，導致很難支援構建乙個良好的多執行緒 gpu 渲染架構，chrome 的解決辦法是...