現在回首望去，都是不堪路。想當年自己傻傻呼呼的，遇到問題
不求甚解
，到頭來，除了問題解決了，最後什麼都沒明白，現在的經驗告訴我，如果時間還夠寬裕，最好找到問題原因。一直認為，發現問題及解決問題的過程中對自己才是最大的幫助。但是真正出現了問題，有時候卻又是及其的糾結、煩悶，但是問題還是要解決的，不可能繞過這個問題，一旦這個問題是求助他人解決的，自己又失去了乙個成長的機會，並且在他人的心中的印象又差了一分。所以說，遇到問題靜下來多想想，想明白問題了，可能答案也就出來了。
現在總結開發中的一些問題。第一點，介面呼叫的問題，系統裡面各個模組之間都講究高內聚、低耦合，這樣模組修改造成的影響會更小一點，但是很多時候更不做不到低耦合，而且耦合度非常高，如果模組的修改小點還好，如果修改太大，造成的影響也是非常大，所以具體來說，也要看具體情況，考慮下該介面是否可能會調整，這一點一定要想清楚，盡量不要耦合他人的東西，但是如果是同乙個模組，在實現功能的情況下，改動盡可能要小，並不是**越多越好，關鍵看**質量及工期吧。
第二點，前端選擇器方面，慎用
id選擇器，很多時候覺得這個元素可能一定是唯一的，但是說不定什麼時候就可能出現了同名的
id，如果非得用
id，那就在前面加個限制域吧，比如
formid
之類的東西，前段時間改這方面的問題，改了許多許多，以前很多元件之間都是一對一的，所以用
id沒問題，但是後面改為了多對一，然後就悲劇了，「涉事」的元件全部需要修改。
第三點，學習方面，很多人可能不滿足工作中的這麼點技術，業務時間可能會去研究一些技術，這應該是非常好的方面，但是有時候你是否會感到技術停滯了呢，自己非常希望突破瓶頸，但是又有諸多限制。你是否有對工作中用的工具、開發的平台又非常深刻的認識呢，沒有吧，其實我們平常吐槽的平台中融入了多代程式設計師大神的心血，雖然很多沒有注釋，但是多看看很是很容易懂的，然後呢，想想實現上有沒有什麼替代方法，且效果更好的方法，然後千萬別去動，想想就好，然後記下來，什麼時候，在某個技術會議上，全部說出來，這樣的效果可能會非常好，然後之前業餘時間學到的技術可能就派上用場了。研究了解平台還有乙個非常大的利處，我們日常工作基本上離不開這個平台，一旦你完全了解這個平台，接下來的工作還不是如魚得水麼，可能接下來就是擺脫了具體的開發工作了。一般什麼人在那編碼呢，都是不太懂的人，懂的人都是看著那些不懂的人編碼，反正我是這樣認為的。
第四點，辦公室生活方面，千萬別私下裡討論他人，因為和你議論他人是否的人，可能平常就喜歡議論他人，今天你和他議論他人，明天可能就是他和你議論的那人在議論你了，並且在賣你，唉，血和淚的教訓啊。
寫的比較亂，先就這樣吧，以後再回頭看看吧。
BlueZ開發隨筆
從2010年的一月份到現在藍芽的專案已經開始兩個多月了。除去過年的二十天，我們已經做40多天了。面對完全未知的藍芽，我們一步步摸索，直到今天終於有了一點小成績。記下我此時興奮和探索bluez的感觸，以回憶！剛開始做這個專案，只知道做基於linux下bluez的應用程式的開發，然後再移植到開發板上。當...
Ext開發隨筆
今天在開發乙個專案時，前端用的是ext框架，在開發過程中碰到乙個問題 missing in xml expression。因為本人是用firefox瀏覽器的外掛程式firebug做為除錯，所就碰上這事。如果不用firefox可能永遠碰到著。發現問題咱們就來解決問題。使用firedebug跟蹤了一下返...
開發隨筆 NOTINvsNOTEXISTS
之前在論壇中見到乙個針對in exists的討論，原帖懶得找了，這裡介紹一下最近的學習小結 not in和not eixts在對允許為null的列查詢時會有一定的風險。特別是not in，如果子查詢包含了最少乙個null，會出現非預期的結果。下面做乙個演示。if object id shipment...