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 工具大量投入是否达到无法控制的底部，核心问题是工具的控制域