1 當水淹到了我們的腳，我們一定要有人淹到了脖子
2 不要做傳話筒，要做分析者，讓別人坐享其成吧
3 工作內容非正義或者對社會貢獻少，員工心理自然比別人矮半頭
1溝通不能解決所有問題，有的問題必須提升層次，由高層決策，你要做的是準備資料影響決策。
2矩陣管理導致責大于權，干事的沒有權，有權的不干活
3需求是客觀存在的，需要挖掘，用戶不說不代表它不存在
4性能需求優先級和重要性要大于核心需求，沒有可用性就談不上核心需求滿足
1 provider必須有
2 provider的路徑和存儲路徑匹配
3 require時候要注意有時候第三方js庫不能在構件構建期引用（構建的js文件引用），必須在外部聲明（避免使用require），比如集成ibm的最新富文本編輯框
4 注意生命周期，在postcreate時基礎html已經展現完畢
IE6內存泄露、不安全、速度超慢為什么還會有人用？全靠盜版xp普及！
不爽的就是我們這樣的軟件行業里的人，所有的問題都要管，今天遇到一個問題200個樹節點做遞歸IE6竟然崩潰？而在IE8下一點問題都沒有，我整了一下午找了一個替代方案，但是對用戶體驗有影響，另外IE6下很多高級方法用不了，比如scrollToView等關鍵Web應用方法。
IE6，真實希望你趕快滾蛋！
在IE8中上傳路徑變成了C:\fakepath\*，主要原因是因為微軟又體貼了用戶一把，如何解決呢？
1 工具 -> Internet選項 -> 安全 -> 自定義級別 -> 找到“其他”中的“將本地文件上載至服務器時包含本地目錄路徑”，選中“啟用”即可。
2
<script type="text/javascript">
function getPath(obj) {
if (obj) {
if (window.navigator.userAgent.indexOf("MSIE") >= 1) {
obj.select(); return document.selection.createRange().text;
}
else if (window.navigator.userAgent.indexOf("Firefox") >= 1) {
if (obj.files) {
return obj.files.item(0).getAsDataURL();
}
return obj.value;
}
return obj.value;
}
}
//以下即為完整客戶端路徑
var filepath=getPath(document.getElementById("iptfileupload"));
</script>
互聯網用戶買的是現實（能馬上用到），而企業用戶買的是預期（開發商做成啥樣就是啥樣）
互聯網的競爭是品質的競爭，而企業用戶的競爭是人脈的競爭
互聯網強調體驗，而企業應用強調功能
innerHTML中的javascript是不能執行腳本的，必須用別的手段來接手動實現，dojo的html包提供了set方法可以解決問題，但是增加了html掃描次數，在企業解決方案領域對性能的影響是需要考慮，這個方法直接關系到單頁前臺性能優化是否能成功，糾結中。。。
今天想說一下關于資源復用與個人價值評價之間矛盾的個人一點想法：
只要是做軟件的沒有一個不知道“復用”這個概念的，新手對復用的第一個感覺就是復用好呀，節省成本，提高效率，在業界混時間長的就會說復用架構，避免錯誤，降低學習曲線，這所有的假設都是基于最好條件下，天堂的東西永遠都是好的。我的觀點很明確，直譯某國外大牛的話就是“復用就是個屁”，也就是說你一直在復用的東西可能是團屎，只是你自己覺得好罷了，想想微軟每年為XP打的那些補丁吧，就知道復用的到底啥？但是不復用行不行？明確的說，不行，軟件行業的可悲之處就在于此，明知道是潑屎，你還得享用，因為復用最起碼能活著，不復用就得死。
今天到不想說軟件復用，主要想說人的復用，人的復用形式很多，比如目前這種交叉管理形式就是典型的人的復用，目的是什么呢？通過復用人將團隊效率提高，避免累的累死，閑的閑死，前提是什么呢？人是工具，結果是什么呢大部分團隊效率沒有提高倒反降低，具體原因有很多，一是內耗 二是管理成本巨大 三是也是最重要的人的價值評價會被扭曲，也就是說多人評價等于沒有評價，體驗是啥？到年底，發現自己竟然沒有成果，挫折感自然就產生，這是一方面，另外還有一方面就是關于個人能力的發揮，如果是在一個方向 基本可以專心做自己擅長的，一旦復用，你就必須做自己不擅長的，做什么基本上都會感到是浮云。
不復用行不行？對于大型軟件企業，對于大部分人來說，是不可能的，怎么辦？只有兩條路，要么跑路去小公司要么適應環境，等你做上管理層后，你會發現你也這么干，呵呵，突然想起一句話“世襲的冷漠”
今天在網上看到一個人的文章很給力，他結尾引用了這樣一句話：
找到味道好的飯店，登在刊物上介紹給大家，告訴人家去那里吃那種東西。可是何苦非做這種事不可呢？為什么偏要你一一指點該吃什么不該吃什么呢？為什么偏要你就連怎樣選菜譜都指手畫腳一番呢？況且，被你介紹過的那家飯店，隨著名氣的提高，味道和服務態度反倒急劇滑坡。十有八九都是如此。因為供求之間的平衡被破壞了，而這恰恰就是我們干的好事。每當發現什么，就把它無微不至地貶低一番。一發現潔白的東西，非把它糟蹋得面目全非不可。人們稱之為信息，稱把生活空間底朝天過一遍篩子是什么信息的集約化。這種勾當簡直煩透人了——自己干的就是這個。
不由感慨了一番，做產品的我們服務的對象是誰？核心用戶，什么是核心用戶？就是給我們最大回報的用戶，他們的回報能頂一萬各劣質用戶，為什么不能大而全？因為我們資源和時間是有限的，要保質量，必須有所取舍，由此引來了需求的有限級的劃分：1真正用戶的需求；2核心用戶的需求 3符合產品發展方向的需求，仔細體會這三點能給我們需求分析以很大的幫助！否則我們只能被那些劣質用戶的需求所淹沒，劣幣真的就驅逐了良幣。
軟件產品線概念在這里不詳細說，網上有很多，實現有必要說一下，軟件產品線和傳統開發過程重要區別在于原來開發過程區分領域積累或者叫做資產管理環節，軟件產品線通過兩階段開發方式解決這個問題，使開發過程更加豐滿，按照現在流行說法叫"Sexy".具體實現有幾個關鍵部分，模型、裝配（工具精細化開發）、資產化（模板、組件、擴展點）。
產品線的背景、國內應用情況等情況以及發展前景等問題問題域太大，我沒有能力也不想談，我只想列一下實現了會面對的目前基于Java的解決方案的企業開發的一些阻礙，個人認為克服這些阻礙是想實現軟件產品線的公司必須考慮的問題，說來慚愧目前這些問題我沒有一個想出答案。
1 歷史資產如何處理，基于OSGI對歷史資產不模型化是個思路，但是似乎和模型驅動被動而弛，這個問題核心是成本
2 業務邏輯如何模型化，不模型化似乎是解決方案，但是UI是否要模型化
3 初始階段是否應該兩階段開發，問題是能否活著得到受益
4 工具大量投入是否達到無法控制的底部，核心問題是工具的控制域