1、介绍

流程图

流程说明：
2、具体实现
1）、安装apache、ssh、java、jboss等环境，略。
2）、生成服务证书和服务密码应用和身份验证页面放在一起，所以需要同时配置两个虚拟主机，同时监听80（处理http请求）、443（处理https请求）端口。

4)、代码片段


采集到花瓣 受限于证书的原因，以前经常不得已用IE打开一些应用。其实有一工具可以帮助我们导出IE证书，用于firefox，解决证书的困惑。

采集到花瓣 2010已成为历史，记忆里2010年变化很多、做的很多、收获也很多。2010是个转型期、创业期，从年初开始，就在新的Marking中努力耕耘。前半年，以新产品研发为主；后半年，结合客户使用产品后的反馈，不断的优化和改进产品功能，努力提升产品价值和用户体验。通过大家的努力，几款新产品还是彼受用户欢迎的，最欣喜的是我们提前完成了2010年的KPI目标。

过去的一年，有着太多的痛苦和艰辛，为了新产品的上线，晚上、周未都没了，唯一想的和做的就是确保产品如期上线。过程虽然很艰苦，但大家都努力坚持，齐心协力，确保任务如期完成，我们保持了一贯的说到做到、如期交付的作风。因为这样的磨练，我和我们的团队得到了更多成长。困难并不可怕，熬过去，明天的太阳会更加灿烂。

1、谈谈成长和不足：
1）、职业转型，开发到管理
虽然Team Leader已经做了几年了，但一直停留在项目上，多为管事不管人，对细节问题关注较多，所以之前谈不上管理，只能算是积累些项目管理经验。经过这一年的学习和发展，有了更多的管理意识，逐渐关注团队建设、团队成长，注意给小组成员更多的机会和空间，让他们得到锻炼和成长，承担更多团队或项目中的重要事项，而他们通过完成这些重要任务，不仅得到了磨练，同时在团队中建立了自己的影响力。
放在以前，我会认为有风险，或者自己做更快，更省事，或最有把握的人去。现在想来，以前认识太肤浅了，我们需要的团队战斗力，而不是个别人的能力，若平常不注重团队成员的培养，团队的战斗力永远不行，承担不了关键任务。
谈到成长和培养，团队需要什么样的人呢？作为互联网企业，同一般软件企业不同，产品在推出之前，谁也无法肯定是否会受用户欢迎，只能快速推出，让市场来验证，不断的改进和适应用户的需要。因而，需要我们技术人员也具备技术判断力，改变命令式管理体制下的工作习惯，充分发挥主观能动性和创新意识，共同做好产品。

2）、学会拥抱变化；
2010年变化很多，有些也许对个人、团队没有影响或影响很小，有些直接关系自己或团队，如团队的核心成员不断的被抽调、人员调整、KPI的271考评等，每次的变化都会带来不同的问题。持续输血，新人补允，使团队战斗力大打折扣，很长一段时间非常的纠结和无耐。事情总是具有两面性，往好处看，这对我、对团队也未必是件坏事，没有经验过挫折和磨练，又怎能成佛呢？既然是组织需要或Boss的决定，那就多些理解和支持，支持和协助上级完成也是每个下属的职责；况且，某些变化至少对于一些同学也是件好事，他们有更多的机会和更大的平台去一展才华。

大概人都是喜欢按习惯办事的缘故，每每有变化都觉的很痛苦。我觉的如何拥抱变化关键在于心态，我们需要理性看待变化，多往积极的方向思考，不仅更容易调整好心态，而且可以在变化中吸取经验和教训，鞭策我们成长。

3）、提升项目管理能力
虽然在项目管理知识上没有太多的时间和精力去系统的学习，但通过不断实践和总结，还是有了不少的积累和沉淀，对项目管理有了更多的理解和把握，对敏捷项目管理也有不同的认识，结合团队自身寻找适合我们的实践方式。在项目管理方面，还有很多需要去提升和学习，2011年希望安排更多的时间系统的学习项目管理知识及敏捷项目管理，并结合实际应用到工作中。

4）、提升向上沟通力
在拥抱变化的同时，同样需要理性的分析和积极的向上沟通。在过去，虽然会尽可能的去表达和反馈自己的想法和意见，但我重新审视下，总觉得表达还不够明确或不是那么的到位，或许在表达时还有更好的方式，至少还有提升的必要。向上沟通也是门学问，需要好好研究下。

5)、提升团队建设和辅导能力
相对来说，过去的一年所有的同学都会关注到，但领悟能力和基础较好的同学成长更快，基础稍弱的没有太大变化。显然，平常辅导工作没有做好或做到位，关注程度不够。越是基础差些的同学需要关注和帮助的点越多，需要帮助他们找到不足和问题所在，一起找改进办法，并给予必要的督促和检查，养成好的学习习惯，促进成长。2011年，这方面需要做的还有更多。

2、谈谈2011年的期望
1）、团队
解决目前团队新人多，有效资源少的问题；积极关注和帮助新人溶入团队，熟悉业务，以减少对项目开展的影响；
抓好梯队建设，关注和辅导基础较差同学的，共同制定改进计划和Action，做好必要的监督和指导，促进成长；
2）、能力
系统学习项目管理和敏捷软件开发方面的知识，并应用到项目管理实践中；同时积极参与相关方面的分享和讨论。
3）、影响
推动兴趣小组活动的开展，借开发工具的发展和分享，建立团队在部门或技术部的影响；
鼓励团队成员积极参与技术部的公共事务，提升影响力。

给力2010，加油2011!!!

1、什么是iteration和release？
iteration和release是两个不同的概念，但在敏捷实践活动中，我们往往认识的比较模糊，一个Iteration就是一次release，其实不然。那么，具体有什么区别和联系呢？
Iteration（迭代）：在固定的周期内，经过需求分析、设计、实现、测试等活动，完成计划的的业务需求，迭代结束提供一个可工作的产品。计划的业务需求，可能是一个完整的User Story，也可能是一个Story中的若干task。
Release(发布)：经过一个或若干个iteration后，完成计划中的所有User Story，经过测试后才release，最终真正交付给客户使用。
在我们的实践活动中，一个User Story所需的工作量超过我们的有效资源，无法安排在一个iteration内。我们就会想当然的会去延长迭代周期，增加有效资源以适应所需工作量。殊不知，这更象是形式上的迭代开发，无异于瀑布式项目开发过程。

2、建立固定的迭代周期，保持稳定的开发节奏
Scurm方法也非常强调稳定的迭代节奏，一个稳定的迭代节奏就如同项目的的心跳。Simon Baker描述说："就像心脏有规律地跳动来保持身体运行，固定的迭代长度提供了一个恒量，有助于建立开发和交付的节奏。根据我的经验，节奏是帮助取得不变的步幅的重要因素"（2004）。对于敏捷开发的团队而言，稳定的迭代节奏可以让产品保持更稳定的交付。

3、如何保持稳定的开发节奏？
当一个迭代期内可提供的有效资源无法实现一个User Story时，我们如何按排呢？ 在 谈迭代周期控制的困惑 中已谈到，这里不在细述。

4、如何选择适合自己团队的迭代周期？
一般需要考虑以下因素：
1）、整个项目周期长度（完成计划的商业需求所需时间）
较短的迭代周期将会有以下一些好处：更频繁的向客户展示/交付可用的软件；更频繁的度量开发进度；更频繁的取得反馈并改进；一般大的项目最好有多次(3次或以上)获取反馈、修正的机会，根据项目周期调整迭代周期长度。
2）、不确定性的多少
不确定性有多种形式，客户到底想要的是什么？小组的工作效率，时间？技术门槛等都不存在不确定性，不确定性越多，迭代就应该越短。
3）、获得反馈的难易程度
指小组获取反馈数量、频度和及时性，视所处的环境不同，选择合适的迭代长度；
4）、优先级要以多久保持不变
开发小组承诺在一次迭代中完成一组特定的功能，重要的是不要改变他们的目标方向，优先级不会被改变的时间长度是选择迭代长度时需要考虑的因素。
5）、迭代的系统开销
每次迭代的成本（时间），如迭代中进行的完整回归测试。最佳迭代周期的目标之一就是减少或近似消除每次迭代的系统开销。如每次回归时间成本很高，那决定周期长度时更倾向于长一些。
6）、团队成员的紧迫感
Niels Malotaux指出："只要项目的结束日期还在遥远的将来，我们就不会感到任何压力，并从容不迫的工作。当结束日期逼近时，我们才会开始更努力的工作"。意思指项目开始大家比较放松，而越临近结束，工作越忙压力越大。因此，选择一个合适的迭代周期长度，让团队成员在整个迭代过程中感受到的压力更平均，不是给团队更多的压力，而是压力总量平均分布在迭代过程中。

每个团队根据所在环境和条件确定一个合适的迭代长度，一般建议2~4周。在我们的实践中，以2周一次迭代的频率，保持相对稳定的开发和交付的节奏。

5、参考资料:
《敏捷估计与规划》 Mike Cohn
敏捷宣言中说到："最好的架构、需求和设计来自于自组织的团队"。在自组织团队中，我们每个人既是团队/项目的管理者，又是执行者，要取得优异的结果，必须加强自我管理。

如何做好自我管理呢？

1、平和的心态：我们会不断的遇到各类或好事或坏事、或成功或挫折，什么样的心态去对待决定了我们成长的方向及高度，"态度决定一切"。
2、目标感：大到个人职业规划，小到每件事的期望，对于目标(期望)的制定和管理，都需要我们认真的去对待；
3、执行力：目标是方向，不能执行就不会有结果，好的执行力是优秀个人或团队的必要条件。
4、时间管理：工作需要区分轻重缓急，不能对事情没有计划和按排，对事需要分析重要性和紧急程度，分别对待；
5、学习能力："学历代表过去，能力代表现在，学习能力代表将来。"，一个人的学习能力决定他将来的成绩；

任何人都不希望自己被人管着，但要想不被人管只有一种办法：时时严格要求自己，主动、出色的完成每项工作，努力学习，与团队共成长。
昨日PM小组例会，谈到了需求评估工作量远大于有效资源情况下，如何保证迭代周期稳定的问题。讨论的内容，对于PM如何控制、保持迭代周期稳定有较大的参考价值。

	有效资源	评估工作量
1	多	少
2	少	多
3	相同	相同

注：
有效资源：指迭代周期内，开发团队所能提供的有效工作日，单位人/天。
评估工作量：指迭代周期内，产品经理提供需要实现的业务需求所评估的工作量之和。

上表描述以固定周期为两周的迭代中，可能会出现的有效资源和评估工作量对比情况。其中，1、3两种情况因为评估工作量小于或等同能提供的有效资源，所以不会影响迭代周期。重点需讨论的是有效资源小于评估工作量时，如何保持固定周期？

例举：一迭代周期，能提供有效资源20人/天，需求评估工作量30人/天。
1、功能较独立，需求不能拆分发布；
安排一个release，两个iterative。这种情况需要在迭代2中附加一些技术改造或低优先级的小需求、bugfix，release日期相对会慢几天。

2、一个迭代中包括多个产品的需求(需要各位产品经理协商，决定需求优先级)；
a)、以保证质量为重：
忽略商业优先级，先处理一个迭代中就能全部完成的需求。

b)、保证价值
分两个迭代完成，一次release。

通常情况下，我们尽力保证迭代周期的稳定，但也允许例外，如：商业需求，产品上确定了发布时间点，或者节假期间团队请假比较多，一个迭代所能提供的有效资源相对比较少的情况。

保持迭代周期稳定，其核心是：固定Timebox和可提供的资源，让产品经理来决定需求的优先级，每迭代只接纳(开发/QA资源)可承受的需求。
对于互联网行业来说，快速推出产品占领市场、快速检验产品的价值和方向性、快速调整及优化是极期重要的。因此，采用小步快跑、持续迭代的敏捷实践一种不错的项目管理方法。我们团队在敏捷项目管理方面持续开展了二年多时间，在scrum、xp等敏捷最佳实践的基础上，结合团队自身的基础和条件，不断的偿试和优化，总结和积累了一些经验。目前，这些敏捷项目管理实践在项目组开展情况良好，得到了大多数团队成员的认同，特别是业务方、QA等合作方的认可。


上图描述了一个基本项目迭代流程，其中涉及三个角色，其职责同等于Scrum中的Product Owner、Scrum Master、Scrum Team。迭代流程中分别包含了以下敏捷实践：
1）、迭代计划会议，按商业优先级筛选需求列表，确定本项目需求范围；
2）、确认本次迭代需求、资源、时间的具体情况；
3）、简单设计，对关键技术点进行必要的设计；
4）、晨会；
5）、结对编程；
6）、持续集成；
7）、showcase；
8）、项目总结会；
9）、新迭代的开始... ...

以上具体实践活动内容及组织形式，后续将逐一介绍，敬请关注。

1、什么是java序列化

Java 序列化 API 提供一种处理对象序列化的标准机制。序列化（Serialization）是指将java对象用一连串字节描述的一个过程；反序列化（deserialization）是一种将这一串字节构建成一个对象的过程。

2、序列化的作用（必要性）

Java中，一切都是对象，在分布式环境中经常需要将对象从这一端网络或设备传递到另一端。Java 序列化机制就是一种解决在网络两端传输数据的问题而产生的协议。下图表示客户端/服务器之间通信，一个对象是从客户端传送到服务器通过序列化的视图。

3、如何序列化一个对象

为序列化一个对象，你需确保对象类实现Serializable接口。Serializable接口没有方法，只要实现了序列化接口，Class 就能被序列化机制处理。

示例代码，需序列化的java对象:

示例代码，把TestClassSerial对照象输出成 Byte 流，存储到 temp.out 文件里：
示例代码，从持久的文件中读取 Bytes 重建对象：

执行结果为：100.

4、对象的序列化格式

TestClassSerial对象序列化输出的 temp.out 文件，以 16 进制方式显示，内容如下：

这些二进制字节就是用来描述序列化以后的TestClassSerial对象的，我们注意到 TestSerial 类中只有两个域：

都是 byte 型，理论上存储这两个域只需要 2 个 byte ，但是实际上 temp.out 占据空间为 51bytes ，也就是说除了数据以外，还包括了对序列化对象的其他描述。

5、Java 的序列化算法

序列化算法一般会按步骤做如下事情：

1、将对象实例相关的类的元数据输出；
2、递归地输出类的超类元数据描述直到不再有超类；
3、类元数据完了以后，开始从最顶层的超类开始输出对象实例的实际数据值；
4、从上至下递归输出实例的数据；

更多序例化事例及二进制字节含义参考文档：http://my.oschina.net/god/blog/1291

1、员工激励
通过各种外部或内部的刺激，以激发员工的需要、动机、欲望，调动人的工作积极性，充分挖掘潜力，全力达到预期目标的过程。

2、激励形式、方法:
广义的分物质激励和精神激励（职务、荣誉、目标、信任、情感等）。

3、原则：
1）、精神激励为主；
2）、只激励该激励的人；
3）、只激励该激励的事；
4）、激励方法、手段因人而异，把握按需激励；
5）、鼓励公开竞争、和谐竞争；

4、案例：
1)、压力非常大的时候，采用激励手段 -- 目标激励
2)、当前员工不开心，采用的手段 -- 先沟通，明确原因
3）、表现好的员工 -- 信任激励，肯定
4）、推行新方法 -- 目标激励，竞赛

5、附：
马斯洛需求层次理论（Maslow's hierarchy of needs），亦称“基本需求层次理论”，是行为科学的理论之一，由美国心理学家亚伯拉罕·马斯洛于1943年在《人类激励理论》论文中所提出。



安全、生理需要属于物质性价值需求；社会需要、尊重需要、自我实现属于精神价值需求；

解决冲突的法则

1. 在不了解对方动机之前千万不要表明自己的立场
2. 准确把握自己的需求底线
3. 解决冲突的最好办法是谈判

决策的法则

1. 首先，以事实而后数据为依据，如果没有，
2. 以严密的逻辑推理为依据，如果没有，
3. 以民主评议，如果没有，
4. 以最终负责人来决断

奖惩制度

1. 在构建奖励制度的同时不要忘记处罚制度的建设
2. 物质与非物质的奖励(以非物质的奖励)
3. 侧重奖励行为还是结果？

表扬要及时(3天为限)、有理有据、真诚。
表扬是最不花钱最辞旧的激励手段，表扬是为下一个成功设立起点。
不要过度的物质奖励，在这种方式的激励下，员工永远得不到激励。
要注重精神上的奖励，只有精神是永存的。

垃圾收集的目的在于清除不再使用的对象，释放那些不再使用的对象所占用的内存。GC两种常用的方法是引用计数和对象引用遍历，早期的jvm使用引用计数，现在大多数jvm采用对象引用遍历。

1、对象引用计数：
当应用程序创建引用以及引用超出作用域(范围)时，jvm必须适当增减引用数。当某对象的引用数为0时，对象便可以进行垃圾收集。

2、对象引用遍历：
(1)、标记（marking）对象：从一组对象开始，沿着整个对象图上的引用链，递归确定可到达的对象，GC将标记这些可到达的对象。如果某对象不能从这些根对象的一个（至少一个）到达，则表示它可被收集。

(2)、清除（sweeping）对象：GC删除不可到达的对象，删除时，有些GC只是简单的扫描堆栈，删除未标记的对象，并释放它们的内存以生成新的对象。这种方法的问题在于内存会分成好多小段，而它们不足以用于新的对象，但是组合起来却很大。因此，许多gc可以重新组织内存中的对象，并进行压缩（compact），形成可利用的空间。
不一定要将所有的真话讲出来，但你讲的每一句真话必须是真话。(white lie)