可以达到处理乱码的效果

2.从请求中获得数据是出现的中文乱码处理方法有
(1) get请求有两种处理方法
方法1：
在tomcat的配置文件(conf)中的server.xml的

加入上面第4行代码即可。
方法2：也就是通常说的再编码的说法，

1<%
2   String name=request.getParameter("name");
3   byte []b = name.getBytes("GB2312");
4   name=new String(b);
5%>
6也可简化为：
7<%=new String(request.getParameter().getBytes("GB2312"))
8%>

(2)post请求
在jsp页面中加入也下代码

1<%request.setCharacterEncoding("gb2312");%>

需要注意的是这部分代码要放写在获得请求内容以前。

3.以上就是JSP页面中出现乱码的方法，最后我想说的就是如何确定发送的
  请求是GET 还是POST。
(1)一般表单(Form)提交中有method方法确定。
(2)通过URL链接传递为GET方法提交
(3)通过地址重写的为GET方法提交

谢谢阅读

ps:连接地址：http://neilbartlett.name/blog/osgibook/

    上次e4放出的基于web的IDE就使用flash作为代码展示和编辑的编辑器，看来Eclipse社团也感觉到纯的js基本上不能完成任务了。

Demo下载地址：http://www.innoopract.com/fileadmin/user_upload/Bilder/Films/draw2d_640x480.mp4

The Eclipse Project PMC is announcing a new component, called E4, as part of the Eclipse Project Incubator.

Component Description: 

During the Eclipse Project 3.4 release cycle, one of the important plan items was "Create the Eclipse 4.0 Plan". The intent of this work was to identify the most pressing issues that would impact the ongoing success of Eclipse, and come up with a plan to address them.  The result was the design of a new platform "e4", which will be the basis for Eclipse 4.0. 

The goal of the e4 component is to provide a public venue for the initial explorations that were done, leading up to the e4 design. We expect to continue to work in this area until we have reached consensus on how the full e4 effort will be structured.

We on the platform team care passionately about Eclipse. We know you do too. We want to see it live a long, healthy life. We want it to serve its community as best it can. When we can’t achieve that it makes us sad. It’s clear to us that for Eclipse as a platform to remain long lived, vibrant, and relevant, it must be able to change. But the weight of a zillion plug-ins, projects, and API means the path of least resistance is stagnation, and the effort to effect change given the current constraint system is becoming monumental.

Therefore, two things must happen:

1. A new space must be carved out in which experimentation can happen, leading to change.
   
2. New people must get involved, bringing with them their energy, ideas, requirements, knowledge, passion.

These two are intrinsically tied.

That is e4.

    问了错的问题，而导致错的答案，训练自己问出正确的问题！

    勉强自己接下不可能完成的任务，实在是以长痛代替短痛的做法，而且长痛的是整个团队，该拒绝的时候绝对不能含糊；

    不要为了讨好别人而伤害双方的工作进程，您永远要根据自己的目标，做适当的决策。

    必须保护项目不受外界的左右，尤其是当这种操控来自特权人物之手。

    副产品对公司或产品都没有策略上的价值，充其量只是一种消费者回馈。

    不值得开发的功能就不要做。

    软件产品的开发，不能只为了有趣、挑战性，或是够有个性够令人眩目。

    遵循标准重于一切，特别是关于使用者界面的部分。

    确定您所要求的报告真的值得属下暂停工作，花那么多时间去写。

    请注意定期会议的价值，确定它值得每个人放下手上的工作。

    召开任何会议之前，请确定本次会议的目的是什么，达成这个目的的条件是什么，然后，务必达到开会的目的。

    不要利用进程表来驱使项目的进行，这对小组的士气伤害太大了。

    让日程表维持适度的紧迫，但又是可以做到的，好让组员振奋、不松懈，专心致力于项目的推进。

    绝对不要草率定出不可能的期限，导致组员为了赶进度而损害产品的质量。

    把长期的大项目，分成几个完整而独立的小项目，各小项目必须有一个主题。

    为了保持创意的活力和团队士气，必须让每一个小项目都有令人兴奋的结果。

    不要让程序设计师的学习停滞不前，要让程序设计师有机会磨练不同领域的技术，培养十八般武艺样样精通的组员。

    训练新进程序设计师时，先培养他对整个公司所有项目都有价值的技术，然后才培养本项目独有的技术。

    不要舍不得放您最优秀的程序设计师到别的项目去。如果他在您的项目已经没有新的东西可学，为了公司和他个人的前途，您应该把他推荐到别的项目，让他的成长永不间断。

    确定每位组员、每两个月都有一项技术上进步。

    一发现某处需要改进，就立即采取更正的行动。

    Watch the ratio    注意人员的组成比例

    “基本原则是开发人员和品保人员的比例不超过2:1”这个是作者为我们提出的建议，而在SUN这个比例被修改为1:1，甚至是1:2，可见在项目中品保人员比开发人员更加重要！

   “其实真正负责软件如期完成的是品保人员。当进度落后时，我们第一个要看的是品保人员：人数够不够？有没有充分授权？有没有确实参与设计？进度上能不能跟开发人员配合良好？能不能一有问题出现就立刻提出警告？品保人员和开发人员的理念一致吗？是不是跟开发人员过度亲密而放水？”

    “一个健全的软件开发团队一定要符合上述的人数比例原则，平均每一位品保人员所支援的开发人员不超过两位。”能做到吗？至少在我们公司这个，基本上，很难！

法则七：

    Use feature teams    运用特色监督小组

     融入任务（I d e n t i t y） 充分的授权和责任感，使人具有控制权和影响力，愈能使自己与任务融为一体。

    建立共识（C o n s e n s u s） 共识是特色监督小组的气氛。

    地位平等（B a l a n c e） 由于特色监督小组的每一位成员都是不同的背景、专长，不同的工作角色和不同的观念，没有谁比谁优越的情形，所以每个人的地位都是平等的。

    权威是来自学识，而非职位。

    在一个理想的项目中，基本上有两种角色存在：创造者（c r e a t o r）和推动者（f ac i l i t a t o r）。创造者是一些专业人员，例如开发程序、行销、软件品保和文件撰写；而推动者则负责凝聚团队共识和维持最佳的开发环境。

法则八：

    Use program managers    项目经理的职责

    项目经理是软件开发团队的一份子，他的职责是：
      • 领导大家定义出一个成功的产品。
      • 引导大家对产品注入深切的期望和信念。
      • 带领团队将理想实现，变成可预见的产品诞生。

    项目经理应该要有技术的背景，而且必须在两种层面非常专精：一是对开发产品所使用的技术很熟悉，二是拥有建构软件的技术领导能力。项目经理必须精于哄骗、驱策、鼓励、要求他的团队做出最好的软件和表现出最好的工作效能，他清楚知道软件制作过程中每一项的投入和产出细节，他必须懂得用最好的方式定义产品和维持健全的技术。最后，项目经理还必须是团队的发言人，面对媒体、客户、以及整个组织。

    项目经理是软件开发的核心人物。

    你想了解这个团队？看看他们的软件就知道了，反之亦然。

团队精神：

1. 一群人同心协力，集合大家的脑力，共同创造一项智能财产。

2. 个人的创造力是一种神奇的东西，源自于潜在的人类心智潜能，它被情感丰富，而被技术束缚。

3. 一群人全心全意地贡献自己的创造力，结合成巨大的力量。结合的创造力由于这一群人的互动关系、彼此激荡，而更加复杂。

4. 这种复杂的情况之下，领导变成像是人际互动的交响乐指挥，辅助并疏导各种微妙的人际沟通。

5. 在团体中的沟通和互动是正确而健康时，能够使这一群人的力量完全结合，会产生相加相乘的效果，抵销互斥。沟通顺畅能使思想在团队中充分交流传达。

6. 团队工作的品质比时程更重要，而作品的伟大是需要对“团队精神”特别加强，才能达成。“团队精神”可视为个别成员精神的平均值，而个人的精神（ p s y c h e）则是使他能感觉、能思考、能推论的内在力量。

7. 倘若忽视了“团队精神”，则只会有平庸的成果。

法则九：

    Be an authority ， not an authority figure    要权威，不要霸权

    权威的目的是让每一位团队成员都有自己的专业权威，和团队的专业自信，这才是管理者真正的权威。

竞争

    创新无处不在，绝对不可以停滞不前！

    如果你无法时时掌握时代的脉搏，如果你怠于响应周围迅速而剧烈的变化，特别是竞争者的行动，如果你不能持续地创新原有的技术，永远保持领先，那么别人马上就会趁虚而入，取代你而成为市场上的优胜者，掳获顾客的心和他们的荷包。

    确定了你的情况之后，应该先考虑采取标准步法。

标准步法：

法则十：

   Alone? A market without a competitor ain't     没有竞争对手？未必是好事

（注：任何人都有敌人！）

法则十一：

    Dead beat? Break out of a feature shoot-out    竞争者紧追不舍？推出创新的功能特色（注：想法设法的压制你的敌人！）

法则十二：

    Behind? Ship more often with new stuffs    落后竞争对手？加大投入，更快推出新版本（注：沉下心来，夺回领地！）

法则十三：

    Ahead? Don't ever look back    领先竞争对手？不要回头（注：挑战自己，战胜自己！）

    准时地、经常地推出新产品是软件开发产业中最大的金科玉律。

法则十四:

    Take the Oxygen along    保持新鲜

    快速变迁的节奏是信息社会的常态，你必须快速前进，否则就落伍了。

顾客

    想方设法的让顾客迷恋上你的产品！

法则十五：

    Enrapture the customer    给顾客惊喜

    顾客最低的希望是你能够理解他所感受到的痛苦经验。

法则十六：

    Find the sweet spot    寻找靶心

法则十七：

    It's a relationship, not a sale    与顾客建立关系，而不是卖产品

法则十八：

    Cycle rapidly    加速产品推出的周期

    首先看一下《微软团队：成功秘诀》分别在china-pub和豆瓣上的书评把：

china-pub

豆瓣

法则一：

    Establish a shared vision    建立一个共同的目标

    在团队总建立共同的目标是非常重要的，团队中的成员只有当有了共同的目标之后才能有归属感，才能对憧憬中的产品产生荣誉感，才能在管理中更好的调动各个成员的积极性，从而将团队推向正轨，让产品如期发布！

   “团队中每一位成员都必须非常清楚我们要做什么、成品会是什么模样、基本的产品策略是什么、什么时候必须完成。凡是与共同目标相冲突的看法都必须转化成一致，而不是把它消音。和谐的共识是绝对必要的，否则软件不可能做得好，很多事会复杂化而难以收拾。”

    所谓目标是共同的希望，对未来的事情所描绘出来的景象，比方说作者在给VC++项目组开会时候的描述“Visual C++是最伟大、最值得骄傲的产品，你们难道不这么认为吗？我知道我们可以如期完成它，而且用它来给对手一个迎头痛击，不只我一个人这么想吧？我们将创造微软的明日世界，我们会大有作为的，不是吗？”其实他已经给VC++了一个很好的目标，他让成员们觉得，我们都是在伟大事情，一但在团队中形成了荣誉感，你会发现你的团队将会空前的团结！

法则二：

    Get their heads into the game    使大家主动投入

    “如果每个人都在认真思考如何使团队更有效率，这个团队自然就比较容易表现出高效率，反之亦然。”让每一个人都参与进来，需要管理者能够调动每一个人的积极性~让大家都主动的去思考问题，为产品主动的出谋划策。

    需要管理者去倾听每一个愿意说的成员的言论或者主意，需要判断的这些言论或者主意的能力，面对好的想法，也许它不切实际，但是也不要一棒子打死，而是要进行诱导，让他下次可以提出更好的更切实际的想法来。

    鼓励创新而非抹杀它！

为什么组员会怠于思考或是不敢说出想法？
    • 因为他们认为没有人会重视他的想法。
    • 因为他们认为该由别人告诉他该做什么事。
    • 因为他们认为这样做没有什么好处，只会使老板皱眉头罢了。
    • 管理者只管发号施令而已。

法则三：

    Create a multi-release technologyplan    建立开发多版本的技术规划

    授权共决，其实就是全民参与，无论是对待成员的新想法还是对待项目的技术规范时都使用全民参与。（这样好吗？安全吗？）

法则四：

    Don't flip the bozo bit    别做笨蛋

    软件产业中最重要的事情是“让大家思考！”。

    “在微软我们把这种人叫作b o z o，意思是笨蛋。永远没有人会注意笨蛋的所作所为，即使他真的有贡献，他也不会有任何份量。笨蛋当然是不可信任的，你对笨蛋惟一的期望是但愿他不要搞砸事情。

     在我的部门里，这种德行是不允许的。我要每一个人都全心全力地投入，每个人都得有贡献，每一个人都可以侃侃而谈我们的产品─如何在市场上竞争、何时出新版本等等，而且每个人对产品的看法都一致，不会众说纷云。

     将自己的意见强行加诸于他人者，其实是笨蛋。”

     需要随时防范组员出现“江郎才尽”病！

法则五：

    Use scouts    刺探敌情

    必须有一个人或者有一些人去观察未来的发展趋势，预言新技术。这个角色是非常重要的！

    “这次他们学乖了，事先派了两位最优秀的组员担任“侦察员”，做了一次彻底的技术调查和完善的规划，终于在危机爆发之前将之化解。”

    ““侦察员”就是为科技的改变而准备的，如果你决定永远停着不动，那你不需要“侦察员”。”软件公司中如果没有这个角色还叫软件公司吗？