苏的笔记的博客网

因为自己之前很少开发web应用程序，对web技术了解也不多，比较落伍，为了充实自己，最近在学习web方面的一些技术，比如rest、flex，感觉现在的web技术比起几年前真的差别很大。
为了学习flex，下载了flex builder3，真的很惊喜，IDE竟然就是基于eclipse的，用起来极其顺畅，看来adobe的策略很是高明，即省事又较少初学者的学习曲线。
flex是一种RIA技术，在构建交互性强的web非常棒，在最近的调查中，ajax/js依然占据了90%以上的市场，flex和silverlight占据了不到10%的份额，虽然份额不大，但RIA应该是web发展的一个重要方向，不然ms不会死命推silverlight。
现在在市场上，貌似flex学习气氛比较火，不过典型案例确实少了点，大部分网站都是用了少量的flex。其实flex的应用范围还是挺广泛的，比如做视频在线播放（不知道土豆、youtube是否用了？）、在线office、在线游戏等等。
flex比起java applet来说，有很多优势，比如说最终以flash格式来发布（也可以直接在AIR中运行），基本上每个浏览器都会支持，而浏览器对jre的支持却很有限，而且UI界面比awt,swing好看、丰富得多，最重要的是flex里面支持根据internet的通信方式，比如http,rest...。当然，applet使用java开发，基本没有学习曲线，这点是flex无法比拟的，看着applet逐渐没落，flex应该可以大展拳脚。
flex builder3真的是一个很强大的flex IDE，通过它学习flex变得很容易。本来我对flex的规矩一点都不懂，通过一个例子，马上感觉flex真的不错。
首先，actionscript比较强大，支持非常多的UIcomponent，编程方式和java非常相似，支持package,class，继承，重载，而且可以在flex里面debug，要知道一个技术如果不容易debug，将是一件多么痛苦的事呀，ajax大概就是如此吧，呵呵。
flex里面内置了很多class，可以方便使用，由于其编程方式和java基本一样，一些在java中的编程经验很容易复制到flex，比如design pattern等等。
在flex builder3里面画一个界面，非常容易，只要把Component拖进来，然后设置一些属性，通过代码加入一些事件处理，一切就ok了，比起java里的繁琐的layout来说简单多了。
flex本身确实很强大，除此以外，还有不少框架，比如cairngorm就是flex客户端的mvc框架，这些对于大型应用，框架是非常有效的，对规范编码、后期的维护都有较大的优势。

即然flex有这么多优势，那么怎么应用到我们的产品中了？
在tsm版本中，其实登陆界面就是flex典范，topomap似乎不好用，因为我们使用了java的ui库，只能通过applet来实现了，但愿以后会有更多个人、公司提供一个丰富的flex UI 库。

学习之路很长，就慢慢学习吧，呵呵。

Apache Jakarta common里面的一部分。最早是从struts发展过来的，历史不多讲，网上介绍的多的是。它的主要功能就是能简化xml到对象映射。
以前，我们将xml中的信息读出，然后赋给对象，一般要通过SAX等来实现。实际上，这样操作起来很麻烦，而且每个不同的xml，可能你需要写不同的解析代码，扩展性不好。而且处理嵌套层次关系时非常复杂。
Digester能做到的就是帮助我们简化这些操作，将xml中的数据直接读取并映射到你定义好的java object中，而且这些对象间的嵌套层次关系也能轻松处理。

只需要在里面设置好一些属性和RuleSet，然后调用parse即能返回这个xml文件对应的根对象。
其内部的实现，实际上通过注册的一些RuleSet，按照strategy pattern来对xml中的不同元素按不同的规则做匹配和转换，最后生成对象实例。

最近突然想了解一下日本战国-幕府时代的历史，没细看，只大致了解了一下概况。
日本战国大约有130多年，跨越14xx-16xx，战国之后然后就是幕府时代，接着就是明治维新了。
幕府历史中最重要的就是德川家康，提起德川家康，一定会与织田信长和丰臣秀吉二人关联在一起。

关于战国，现在倒是有很多游戏来自战国题材，中国青少年了解日本历史大概也是通过游戏吧，太让人伤心了。
武士道精神大概源于此吧。

日本二战后，在屈辱下得到了快速发展，大概也来自于德川家康的精神吧，日本的忍术大概也是如此吧。
这与中国的刘邦似乎比较相近，与中国提倡的主流精神有些差别，呵呵。所以，中国就是中国，日本永远是日本。中华文明是几千年积累的结果，现在的日美文化侵略是难以撼动中国人道德观的。

仁仁2岁了，也到了上幼儿园的年龄（仁爸妈好像都没上过幼儿园，呵呵），上周算是仁仁去幼儿园的第一周吧，总的说来表现还好，一天比一天有进步。
本说好上上周就去的，但是一直下雨，就拖着到上周天气变好才去，没办法，仁仁喜欢在室外玩耍，下雨天憋着不出门实在是件很难受的事。
第一天到幼儿园，抱着外公就是不愿意下来，直到陪他玩了一会才愿意，呵呵。经过一周的适应，现在仁仁进步多了，不过他内心还是不愿意去幼儿园的，因为家里更加自由。
小孩也挺有意思的，好像很懂大人的心思。平日如果要到幼儿园去，他就睡觉拖到8点才起来，一到周末不用去幼儿园他就6点起床，一点不浪费自己玩耍的时间。

新版本的开发进行得如火如荼，整个版本的周期预计10个月，有11个左右的研发人员参与开发，到目前为止应该说已经可以看到产品的轮廓了。在整个开发过程中，团队不断磨合，不断摸索，对需求管理、开发流程等不断改进，虽然还存在不少问题，但大家对一些基本准则基本认同。在这个阶段，我们着重强调了code review、单元测试、反思改进。
对于code review，以前也进行过，但没有形成系统，时断时续，成为开发中的鸡肋。这次使用过程中，有不少体会。
1，必须有编码规范，版本管理规范，这些convention需要在大家认可的基础上不断完善。“不以规矩，无以成方圆”，有了规矩，就需要强力执行。
2，尽量用自动化工具，定期生成报告，减轻大家工作量，提高生产率。我们使用的是eclipse集成开发环境，里面有很多实用的插件，subversion、checkstyle、jupiter、ant、cruise control都是一些很好用的工具，当然，工具需要按照团队的实际去设置哪些该屏蔽掉，这个过程需要有互动、不断调整的过程。比如说checkstyle缺省的规则会报无数warning，严重打击大家的积极性。
3，code review中对提出的一些有代表性的问题，需要提出并加入到编码规范中。
4，对于code review的时间安排，个人觉得不宜太频繁，最好能固定下来review的周期。我们最早是每周一天，每次2人讲解代码、设计思路，然后大家各自在下周花半天去code review，并统一在下周的一天进行这些意见的总结并安排下一轮的讲解，这样花费的时间太长，大家抱怨真正开发的时间太少，没办法完成自己的任务，后来马上调整，每2周进行一次，每次只安排半天进行讲解和review总结，这样就需要在总结前把所有问题在总结会前都分类、统计出来，及时公布在wiki上，节省大家的时间。总结会后需要有人对这些问题进行跟踪，避免只提问题，不修复问题。
5，要有制度保证每人都去认真的做了review。Review不是为了让大家完成一项任务，而是为了让团队相互间理解代码、改进代码和设计，同时取长补短。如果没有养成一个习惯，刚开始实行起来是很难得，大家会有不少抱怨，有的人提得少，有的人干脆不提，有的人胡乱提，这都会挫伤提得多的人的积极性，需要及时提出。
单元测试能有效提高生产率和产品质量，它是一种白盒测试，一般有开发人员自己进行，可以说是产品测试的第一道关卡，如果没有良好的单元测试，质量是无法保证的，即使被测试人员发现了，后期也只能做一些fix bug的工作。真所谓软件不是改出来的，而是做出来的。
单元测试的内容其实很难界定，一般来说可以有功能测试、性能测试。对于功能测试，在用例上又可以细分很多粒度，一般在java应用里面都使用junit。本次开发过程中，我们强调需要对重要的类必须编写测试用例，而且有专人去检查用例，使用ant定期生成报告。听起来是件令人兴奋的事，但执行起来问题很多。首先大家对单元测试认识不够，对哪些类需要测试、哪些类具备可测试性存在分歧；同时有人抱怨编写太多的测试代码花费了太多精力；而且有些代码重构后，测试代码并没有同步；ant生成的报告，有时大家并没有理睬。虽然事先做了很多准备和约定，并不断改进，但单元测试真正成为武器还有相当一段路要走。
开发了几个月，有得有失，所以需要选择合适的时机刹车进行反思改进，倾听团队的声音，对代码的问题、工作安排、流程上的问题、设计的建议都需要集思广益。避免开快车最后团队士气不高，产品进度和质量失控。
产品还在开发中，我们还在……

呵呵，店主还是很用心的，虽然商品不多，但都是用心挑选的，呵呵。
欢迎大家访问：http://shop35395530.taobao.com

那一树花开，名字很好听，好像来自于徐志摩《人间四月天》里的吧。

呵呵。

新年新气象，2008年有很多愿望，但不能太贪，在此希望大家身体健康、开开心心，仁仁更乖些，更聪明，更健康，茁壮成长。

这个春节没回成湖南，特想儿子和父母，呵呵，等过几天，回趟家看望你们。
虽然哲人说人生不是规划出来的，但我每年总归都要计划一番，年终总结一下，周末在家好好想想，:-)

今年过年没有回湖南，除夕又见老大，风采依旧，最重要的是未来大嫂和我们一起共进晚餐，呵呵，祝福他们一路幸福。
去年下半年，老大的team509经营得非常不错，我也非常佩服他们的钻研精神和勇气，更佩服他们的个人能力，希望他们的梦想能早日成真，能够在安全界为中国人争一份光，这年头执着、有能力的人一定能成功。
在这里，再次推荐一下team509：http://www.team509.com

差不多半个月不能用，很郁闷，也许是挪窝的时候了。
真不知道yourblog.org是怎么想的，竟然能够让一个网站维护上那么久。

老实说，这个blog存在的不足还是很多的，比如无法将自己的blog导出成pdf或者word，或者提供一个导出自己所有blog的功能。这样备份也比较方便，据我所知，很多wiki软件可以做到这点。

这一阵，湖南一直大雪，昨天打电话给妈妈，得到一个更坏的消息，在我家生活了近11年的狗狗阿宝去了，更可恶的是被坏人毒死的，真是伤心至极，要知道，阿宝已经成为我家的一部分，它乖巧、聪明、漂亮、忠实、通人性，自从来到我家就非常讨人喜欢。老实说，在阿宝来我家之前，我家是很讨厌狗的，我觉得猫比狗可爱多了，但后来发现自己完全错了。11年前，它们漂亮的六兄弟姐妹出生后，它们的妈妈就去了，叔叔把它带到我家的第一天，想不到已经那么久了，那时弟弟也才十岁而已。
睹物思人，虽然它只是一个小动物，但没有了它，生活中总觉得不习惯，时间长了，感情愈深，尤其是我爸妈，他们两人在老家，一定很孤单，过了年一定要家里再养一条狗狗。
希望以后这样的事情不要再发生，强烈鄙视那些坏人。

又下雪了，这个冬天也许大家听到这句话都起茧了，这可是在50年难遇的大雪纷飞的冬天。湖南的下雪冰冻天已经持续20来天了，我父母说他们也是小时候才遇到这样冷的冬天，看来仁仁也赶上了这趟车，哈哈。
临近春节，大家都躁动起来，没票的着急，有票的也着急，可这又能怪谁了。只是希望每个人都平平安安度过这个春节。

quartz源代码的14个例子非常好，建议分析，执行一下。把log4j.xml拷贝到src/java即可。

CronTrigger也可以指定一个Job类。 0/15表示每15x执行一次

Scheduler.start()执行之后，任务才会被真正调度。

同一Job（fullName相同的job）的JobDataMap是共享的。(example4)

round的job，如果上一个job还没有执行结束，就需要跳过。需要从JobDataMap中获取一个状态标志isRunning，运行结束设为Idle并存入JobDataMap中。这样的一个问题是必须多过一轮才能执行到。（这样是否可以容忍了？）参考example5的实现。 haha，仔细看完example5之后，原来没那么复杂，quartz已经做得很好了，只要将job实现StatefulJob接口即可，而不是原来的Job接口，哈哈。

job fullname的规范：group1.job1
trigger fullname的规则：group1.trigger1
groupname=Task类型
jobname=j+task类名+job启动时间
triggername=t+task类名+job启动时间

如果一个job执行过程中发生异常，那么我们是否可以控制这种异常了？答：可以。quartz提供对job.execute执行过程中发生异常的继续处理流程，可以通过JobExecutionException来进行控制，比如： JobExecutionException e2 = new JobExecutionException(e); e2.refireImmediately(); //重新执行一次 e2.setUnscheduleAllTriggers(true); //让所有触发器都取消调度


如果一个定时轮询的任务，运行了一段时间，你想终止正在调度的任务，但是又不取消这个任务（仅仅终止本次调度，不影响后续的调度），此时该怎么实现?难道要自己写代码检测吗？答：不用。quartz提供了完全解决方案，你可以通过实现InterruptableJob即可。参考example7.


如何实现一个每年，每月，每天的任务调度? 答：容易，quartz提供了一系列的Calendar来加入到Scheduler的调度日历中即可。

任务结束后，让和让他回调一个Listener？答：容易，quartz提供了JobListener，在Scheduler上建立Listener，然后将Listener与Job关联，即能实现事件回调。这样可以做很多任务的关联，比如Job1执行结束后，然后将Job2放入调度器中。参考example9.

quartz的更高级特性：可持久化；当scheduler负载过大有些job可能没有被调度到，此时可以设置setRequestsRecovery来让其可以再被调度。能远程调度、EJB、和jboss等app server集成；支持cluster。基于优先级进行调度。

quartz与concurrent各自的优势：自己稍微看了一下，比较一下各自特点，不一定正确，哈哈。 quartz优势：对调度等封装得非常好，目前应用的非常广泛，成熟；但因为封装的缘故，你本身对内部的线程控制手段较少（不过可以通过listener做些处理，呵呵）。 concurrent优势：concurrent本身是jdk标准，jdk1.5才支持，支持丰富的并发处理能力，对调度要自己写很多的代码，不过concurrent本身也提供了对schedule的强大支持，而且对并发性能应该比quartz有优势，并支持Future等流行的线程通信方式。

confluence与jira一样，同样出于Atlassian公司之手，jira有的优点它同样具备，呵呵。
它可以作为一款wiki知识库系统、blog系统等，有如下特点：
提供了丰富的排版格式库，比如贴图，贴代码，画表格…，太多了，呵呵，这一点是最吸引人的地方，目前很多主流的blog都没有他丰富。
其他特点就不说了。
通过它可以让团队的知识得到最大化的共享，你可以建立每个人的blog、每日工作日志、学习心得、产品需求、项目进度、产品用户手册、团队活动、意见征求、样板代码…可以做的太多了，通过这样做，团队的每一个细节都是透明的，项目进度和质量自然也就能得到保障，团队气氛也能更加活跃。

jira是Atlassian公司出品的一款bug、任务管理的商业软件，其他bug跟踪管理软件怎么样，我不太了解，但我感觉jira在易用性，可扩展性上都非常不错，一个新手基本上不需要培训就能上手。
Web应用的系统，这与bugzilla等相同，它是基于Java实现的，可以安装在各种不同的操作平台下。
简单易用，而且扩展性非常强，这一点是本人认为该软件的最亮点。
规范的workflow，使用了OSWorkFlow作为工作流的引擎。
可对bug,feature,task等进行跟踪管理，而且能够与subversion进行关联。

项目管理最忌讳的是：给下级下达的任务没有明确的输出和期限。
很多领导寄托于下级能够充分理解领导的思路，岂知每个人的理解力和技术能力是有很大差异的，领导想到的未必下级能想到，下级有疑惑的地方也未必能及时主动和上级沟通，尤其是程序员大都比较内向，最后就是领导把任务分配下去后不闻不问，下级也闷头做事，最后到了领导突然想起来的时候一问才发现结果差之千里。
在一个团队里面，要听到反对意见其实很难。
对于领导来说，最可恶的是下级有问题不说，有困难也憋着，到了最后一刻才说，往往延误产品的交付期。
对于下级来说，最郁闷的是领导让做一件事情，可是什么也没说清楚，也没说要什么时候完成，最后就只能等着被训。
沟通能力应该是现代人最重要的能力之一，道理大家都明白，但要做起来却非常难。

上周五中午修改产品的一个bug时，突然发现任务栏中有多个ping进程，占用了大量的CPU，导致有时候系统运行会较慢。
关于这个问题，实际上以前自己早就发现，也想过要做一些改进，最终都因为时间原因（大部分都是托词）或者其他原因，一直拖着没有进行改进。
其实，很多问题就是这样，程序员的忍耐能力往往比用户要强，不到万不得已是很难自觉去改进的，尽管去改一个问题也许并不需要花太多的时间，而改进后的效果往往是非常明显的，最终都因为各种借口而没有去付诸行动。
就拿这个问题，花3个小时，我将原来的代码重构了一遍，通过重构，代码更加清晰，性能也提高很多，最重要的是再也不需要起大量的外部进程了。联想到元旦前重构一个模块也是如此，该模块是一个实习生编写的，现在已经离开公司，代码里面滥用了线程同步和缓存，导致缓存查询很慢，同步快过多导致代码的可维护性可伸缩性都不好，最终重构下来，并没有使用太多技巧就搞定，运行效果很不错。
代码重构，并不一定要在里面使用很多的编程技巧，使用过多的设计模式，也许你只是改了个变量名，加了行注释，将一个大函数分拆成几个小函数，也许带来的效果就大不一样，重构最重要的是要让代码更清晰简洁，降低维护成本，在代码变得清晰的时候，实际上做性能优化就更容易，更能发现隐藏很深的bug。
写代码不可能一下子就写得完美，也不可能一下子就完全设计到位，为了让我们的代码更加有效、优雅，程序员需要坚持持续重构，从小处到大处，不要非积累到一定的量之后才进行，“只争朝夕”是我们的一个信念。
程序员不愿意重构的一个原因可能是因为担心重构后的代码导致不能满足旧的需求，或者带来新的bug，如何避免这一问题了？我觉得最重要的是我们需要做好单元测试，并维护好一套随时可执行的测试用例，这也许就是敏捷开发中对测试驱动开发的一个驱动力吧。
那在一个团队中，如何让每个人都养成这种习惯了，要让大家都发扬主观能动性其实很难，我想一靠规矩，二靠氛围。规矩就是通过编码规范，并辅以定期的code review，让大家严格要求自己；氛围就是不断地将一些重构思想在团队中进行相互学习交流、渗透，大家一起提高。code review和重构不是让大家对自己或别人写的代码进行挑刺，而是为了真正提高代码质量，提升产品层次，所以一定要贯彻到底。
做任何事情都是如此，如果你想到了，别磨蹭了，立即去做吧，“只争朝夕”让你比别人更早一步成功。

最近想找一个wiki软件，这样即使不上网，在笔记本上也可以写blog或者wiki，将自己的一点思路及时记录下来，以免火花错误。
有几个需求最好能满足：
开放源代码，java实现，web展示。
能贴图片、代码、表格，有比较丰富的排版格式。
文章可以转化为pdf。
同时支持mysql或者文件存储。
能批量备份、导出。

有哪位达人知道符合要求的软件，可以在comments中给回复，本人不胜感激。

呵呵，明天亮宝结婚，猛贺一下，虽不能到场，但祝福一个都不能少。

Tree不是jdk中自带的标准数据结构，但是这个数据结构经常用到。
tree有很多种，比如典型有二叉树，红黑树等，jdk中TreeSet,TreeMap有部分实现，大家看一下代码便能搞清楚里面到底做了哪些工作。

最近的工作需要用到tree，不是简单的二叉树，而是每个节点下可能有n个子节点的树，这些子节点存放的元素还有一定的顺序，实现的tree最终还必须是一个Collection。
虽然思路不复杂，要写好还真不容易。
首先，tree是递归的，我们需要实现的类较多，包括Node，Collection，Iterator等。Node需要包含自身存储的对象，而且包含父亲，儿子，兄弟，本身是个递归结构。递归起来就要求思路必须清楚，调试要仔细，不然很容易出错。
其次，Iterator必须能实现前序，中序等各种遍历方式，一般来说，至少实现一种吧，呵呵。
再次，要实现addNode,removeNode,findNode等一系列操作接口，逻辑比List要复杂得多，尤其是每个节点还要排序，查找的时候需要使用二分法。

总算完成，也参考了KSS library的实现，这个库写得还可以，写出来的人java和数据结构基础不错。
通过实现tree，程序的可扩展性好了很多，原来实现使用了大量的if else语句，根据不同的条件来选择响应，现在每个节点都存储一个callback类，快速匹配到就call了，哈哈。

后记：
大家可以参考《Java数据结构和算法中文第二版》
最近2米国教授大肆批评当前计算机教育把java作为入门语言，而且很多人工作中也只用java，导致目前的程序员对很多基础，底层的东西了解甚少，本人甚是认同，如果不了解c，我觉得也很难写出优美高效的程序。毕竟c能够让你更了解程序是如何运行的，如果能了解一些汇编，就更好了，C++/Java都不适合作为第一个入门的语言。
当然，java是非常强大的。

1,ClassLoader的关键
我的目的就是实现一个java版本的plugin机制，能够动态从非classpath的文件目录加载class文件，从而提高程序的可扩展性。
比如：我们目前支持cisco,huawei等设备的信息获取，未来我们需要支持juniper等，那么在我们编写好juniper的信息获取程序文件后，只需要将juniper的class文件放在单独的目录，或者单独jar，而不用管这个jar、目录是否在之前设置的classpath中。
以前，在c程序中，都是通过dll/so的方式加载的，非常方便的，现在发现java的ClassLoader更加强大，呵呵。

载入一个class到内存，比如从网络,jar,zip,加密的文件等等
public Class<?> loadClass(String name) throws ClassNotFoundException
默认的处理：
如果已经加载过，则直接返回；
否则，如果有父classloader，则让父classloader进行加载，没有父就让Bootstrap进行加载；如果都加载失败，则调用自身这个ClassLoader的findClass方法。
所以覆写findClass是关键。

protected Class<?> findClass(String name) throws ClassNotFoundException
系统默认的ClassLoader的实现：直接抛异常，这就让你的子类必须实现这个类。呵呵

所以，如果要实现自己的ClassLoader，则findClass是关键。
这个可以参考java api中的ClassLoader说明。

2,如何编写一个ClassLoader
最简单的就是写一个findClass即可，比如我现在要写一个plugin式的应用，所有监控任务都在d:\temp下，我采用动态加载的方式加载这些任务，这些任务的class文件并没有配置在我们的启动classpath中，这就需要我们自己写一个classloader将这些class加载进来。
findClass很简单：
就是先将文件名解析成路径名（.换成/）。
然后从文件系统中读取这个class文件，存为byte[]
然后调用父类的defineClass方法。

MyClassLoader.java

上周回了趟湖南，回家前口腔溃疡，吃东西都是个问题，到了湖南后发现嘴唇又干，莫非是水土不服，不应该呀，以前都好好的，而且我在家乡生活了快20年。就说这个口腔溃疡吧，不知为什么，我隔上一段时间就会折腾上一次，书上说缺维C，就连仁仁也经常口腔溃疡，真是麻烦，你说一个一岁多的小孩怎么能承受这种痛楚，他一得上就烦躁得不行，喜欢用手指去抠，结果就是越高越糟，最后必须去医院打针才好些。

仁仁越来越大了，脾气也不小，除了小孩天生的可爱，他还有一份倔强。
南方的冬天虽然不然北方温度低，但有时候照样让人冷得不敢出门，最近就是如此，虽然每天有太阳照面。
仁仁最近晚上一点不安份，有时睡到半夜就从被子里面钻出来想睡在被子上面，把他抱到被子里面他还不依，这样反复几次，不感冒才怪，而且他妈妈也跟着感冒，真希望他们俩能早日康复。不过，即使感冒，他依然如故，每天能量无限，忙碌不已，大人们都很佩服他的敬业精神。

最近上海又新开了几条地铁线，对老百姓来说，新开地铁出行更方便了，房价更贵了，但是还有一个副作用就是上班时间更挤了，时间更长了。
为什么？因为人更多了，每站都会多停一会，把地铁里的人急得要死，每个人脾气都很不好，呵呵，可以理解。
看来，以后不指望造更多地铁了。

请小孩保护好你的眼睛。
请长期面对电脑的同学们保护好你的眼睛。

希望大家视力都不要继续下降，也希望仁仁的眼睛没大的问题。

1，确定范围：产品定位，此次需求调研的所有范围。
2，掌握几个原则：
从大功能到细节：这似乎符合中国人的习惯，老米们似乎喜欢从细节到抽象的东东。虽然有些限制我们的思维，但能够让我们能够集中思维在一些重要要点上。
从已有功能到已知缺陷：能够平滑升级，并能不断完善已有产品，让用户感受到产品的不断提升。
从用户反馈到竞争对手的信息：用户反馈的基本都是他们平时最关心的问题，一个脱离用户的需求分析报告毫无意义。同时，国内外竞争友商的同类产品也是我们必须考虑的，因为这会让我们不落入另类一族，同时要密切注意国际标准组织制定的一些规范，让自己的产品能按照国际规范来做，比如TMF、ITIL等。
用户体验与技术可行性并重：差劲的用户体验会被用户抛弃，为了实现好的用户体验和特性但是技术上不成熟则会导致你无法短期内提供合格的产品，这样就会错失占领市场的良机。
需求也要分步走：不断完善，逐步迭代，不断推出新特性，这样才能在市场上占领先机。
全民动员：团队里面不可能每个人都去做需求，但不能只让一个人去做需求，应该尽量让更多的人参与进来，每个人可以提点子，每个人参与需求的讨论、评审，这样才能找出需求中不明白的地方和漏洞。但不要所有问题都通过讨论解决，讨论前一定是讨论召集者先拿出一个方案来，否则需求讨论就漫无目标。
需求系统化：需求必须是有系统的，切忌零碎，不要想到一点就写入到文档，最终一定要系统化。
需求文档化：需求文档必须使用统一的格式，建议正式的文档只适用word，必须有明确的修改历史记录。建议提供如下文档：需求范围说明书，需求规格说明书（功能性与非功能性需求），功能点矩阵（excel，方便做开发计划和发布计划）。。。
3，需求分析的几个工具：
wiki,blog：需求前期整理的好工具，而且每个人都可以看到。
freemind：整理思路，需求的好东东。
照相机：能够及时将一些思路画在白板上，并拍照下来，作为编写需求和需求讨论的依据。

21个月了，继续写下仁仁的习性以做纪念：
越来越调皮了，别人不如他的意的时候就坐在地方，有时候还打滚。
不怕生人。
养成了早睡早起的习惯，中午也会睡2个小时。
喜欢吃零食，一天到晚没停过嘴，会自己开冰箱拿吃的。
会自己插插座开电视，喜欢拿话筒唱歌。
很多词语都会说，但是平时难开金口，一天到晚都乐呵呵。
自己会蹲着拉尿，大便前也会告诉大人。
喝水不再需要奶瓶，拿着和我们一样的杯子喝水。
吃饭也想自己搞定，但往往不成功，满地都是。

留个脚印。通过实行daily work log制度，感觉大家的工作效率很高，呵呵，见下面的图片。



图片结束。

concurrent介绍
java.util.concurrent是jdk1.5中提供的新特性，主要为线程并发提供了一个很高效的框架库。
目前thread pool的实现有很多种，我们也能很容易写出一个可用的thread pool来，但是写出来的东西可能bug较多,性能和扩展性也不如concurrent.
concurrent为我们提供了一个非常高效并发处理框架，而不仅仅是个thread pool,建议大家使用，不过使用前，大家需要对java内存模型，thread，并发处理有个基本的了解。
推荐一本书<<Java Concurrency in Practice>>,中文版<<Java并发编程实践>>.

里面的主要的接口和类：
Executor：具体Runnable任务的执行者。
ExecutorService:一个线程池管理者，其实现类有多种，比如普通线程池，定时调度线程池ScheduledExecutorService等，我们能把一个Runnable,Callable提交到池中让其调度。
Future：是与Runnable,Callable进行交互的接口，比如一个线程执行结束后取返回的结果等等，还提供了cancel终止线程。
BlockingQueue：阻塞队列，这个非常有用。
另外，
还包括一些lock-free的数据结构，比如ConcurrentHashMap,ConcurrentLinkedQueue等。
还包括同步，互斥用的Semaphore,Condition,CyclicBarrier,Lock,Mutex等。
还包括一些原子数据结构，比如AtomicInteger等。

concurrent在我们产品的使用：
scheduler/poling模块：
我们目前使用的Quartz库，它可以做到一些定时调度，我们用的非常简单，我想了一下，我们完全可以使用concurrent很容易地就办到。
首先，我们的schedule都是基于定时调度，一个任务执行结束后等待n秒后再执行下一轮，这种模式可以使用ScheduledExecutorService线程池。
作为调度器，要能够很容易将任务移走，或者加入新的任务，只需要new一个新的Runnable，将其放入到ScheduledExecutorService里面即能加入到调度队列中，而移除就更容易，只需要使用Future.cancel(true)就能将一个任务移除并终止掉。
另外，ScheduledExecutorService还支持按任务间隔周期来调度，而不仅仅是按照严格的周期调度。

xxx模块：
xxx轮询调度的类似polling模块，也可以使用这种方法代替。

一些定时操作，都可以用。

长期性能采集：也可以直接用concurrent。

一个demo:
SchedueTest.java

晚上，我小心翼翼地拨打查分电话，之前我以为今天查不到的，但是总想查查看，总感觉会有好消息，电话那头传来了很让人兴奋的声音，老婆的考试通过了，真让人高兴，努力总算没有白费，剩下的事情虽然还有很多，但总算是搬走了一座大山，应该好好庆贺一下。笑笑听到这个消息也一定非常非常高兴。

也许今天天生就是一个让人激动的日子，今天终于fixed掉所有bug，周一就能发布了，然后就是一个长达7个月新版本的设计和开发。只是有一个烂尾项目让人很闹心，很ft。

虽然很久没有更新blog了，但最近log可没少写，这2个月team实行组员daily work log，这个效果非常不错，每个人对自己的工作更加清楚，也慢慢习惯定一些个人计划，leader对员工的工作也掌握的很好，任务安排、绩效考核都能做到有凭有据。现在，work log成为我们team一个良好的沟通平台，同时也是一个很好的项目进度管理的平台，感谢conflucene、jira，是他们让我们的项目管理更加轻松，更加清晰明了。

弟弟高考终于尘埃落定,今天到学校报到去了,虽不是名牌大学,但总算是悬下来的心落地了,大家心里都非常高兴。
而今这高考,考的不仅是学生,还有学生的家长,从上学到高考,从录取到大学毕业,从大学毕业又要考虑就业或者考研,工作后还要考虑结婚买房...中国人的父母真是太辛苦了.

十年前我参加高考的时候倒没这么麻烦,考完估分填志愿(根本不会填,学校,专业都不甚了解,就凭感觉填),也许那时大家对这个残酷的竞争体会不深刻,或者说根本没意识到外面的竞争原来会如此激烈.

十年之后高考会是什么样子了?谁也不知道,毕竟变化太快,是不是压力会小些,也许高考会取消,呵呵(大概不大可能,压力越来越大倒是真的).

笑笑越来越调皮了,呵呵.
一不注意就爬上茶几,或者搭上小板凳站在上面拿更高的东西,非常令人担心.

有些好吃,胃口也棒,呵呵,每天在小区里玩的时候,他很讨人喜欢.也许喜欢笑吧,大家都喜欢给他东西吃,他一拿着就自己紧紧拿着不放手,坐地铁的时候也是和左右的人打招呼,一点都不认生,呵呵,当然,需要有父母在旁边罗.
不过,笑笑不是很强势的小朋友,不知道这是好还是不好?

笑笑回老家几天了,甚是想他,想念他的笑容.