本来是打算找一个模板直接使用的，没有找到到合适的，自己写好麻烦的啊！很早就知道960css的这个框架了，趁这个机会学学，找到一篇比较容易入门的基础，推荐阅读。 CSS框架已经出现很长时间了，关于这些框架的用处也被我们讨论了很多遍了。有人说，CSS框架不够先进，还有人说这些框架大大的节省了他们的开发时间。在此，我们将不再讨论这个问题。 前段时间，我了解到了CSS框架。经过对Malo、BluePrint和960做了实验对比后，我得出一个结论：我最喜欢960CSS框架。 本教程将解释这个框架的基本原理，这样你就可以用960来快速进入开发。 基本原理 你必须知道一些基本原理来“学习这个框架是如何工作的”。你可以通过实验（或者是用firebug）来学习它，不过我也将会在这里为你介绍它。让我们开始吧。 不要编辑960.css文件 首先是一个小提示：不要编辑960.css文件，否则，将来你将不能更新这个框架。因为尽管我们需要布局我们的HTML，我们将创建一个独立的CSS文件。 加载网格 因为我们可以使用一个外部文件的CSS代码，我们必须在我们的HTML网站中加载它们，我们可以通过以下代码来实现： <link rel=”stylesheet” type=”text/css” media=”all” href=”path/to/960/reset.css” /> <link rel=”stylesheet” type=”text/css” media=”all” href=”path/to/960/960.css” /> <link rel=”stylesheet” type=”text/css” media=”all” href=”path/to/960/text.css” /> 这些做好了之后，我们必须添加我们自己的CSS文件。例如，你可以叫这个文件为style.css或site.css或者其它任何名字。用下面代码引用这个文件： <link rel=”stylesheet” type=”text/css” media=”all” href=”path/to/style.css” /> 容器 在960框架中，你可以选择名为.container_12和.container_16的两个容器class。他们都是960px的宽度（这就是为什么叫960），它们的不同是分的列数不同。.container_12被分割为12列，.container_16被分割为16列。这些960px宽的容器是水平居中的。 网格/列 有很多列宽可供选择，而且在这两个容器里，这些宽度也不相同。你可以通过打开960.css文件来查看这些宽度。但是这对于设计一个网站来说是不必要的。有一个小技巧可以让这个框架更加易用。 比如，你想要在你的容器里建两列（叫sidebar/content）。你可以这样做： <div class=”container_12″> <div class=”grid_4″>sidebar</div> <div class=”grid_8″>main content</div> </div> 可以看到，你的第一列（grid_4）的数字加上第二列（grid_8）的数字正好是12。也就是说，你不必知道每一列的宽度，你可以选择列宽通过一些简单的数学计算。 如果我们要建一个4列的布局，代码可以是这样的： <div class=”container_12″> <div class=”grid_2″>sidebar</div> <div class=”grid_6″>main content</div> <div class=”grid_2″>photo’s</div> <div class=”grid_2″>advertisement</div> </div> 正如你所看到的那样，这个系统依然很完美。但是如果你想使用嵌套的列的话，你会发现它是有问题的。比如，如果后面三列都属于content列： <div class=”container_12″> <div class=”grid_2″>sidebar</div> <div class=”grid_10″> <div class=”grid_6″>main content</div> <div class=”grid_2″>photo’s</div> <div class=”grid_2″>advertisement</div> </div> </div> 你会发现这错位了，不过不用着急，这正是我们下一节要说的。 间距 默认情况下，每列之间都有间距。每一个grid_（这里代表数字）class左右都有10个像素的间距。也就是说，两列之间，总共有20px的间距。 20px间距对创建一个有足够宽的空白间距的布局来说是很棒的，它可以让一切看起来很自然。这也是我喜欢使用960的原因之一。 在上面的例子中，我们遇到了个问题，现在我们就来解决它。 问题是，每一列都有左右边距。而嵌套的三列中，第一列和最后一列是不需要边距的，解决方法是： <div class=”container_12″> <div class=”grid_2″>sidebar</div> <div class=”grid_10″> <div class=”grid_6 alpha”>main content</div> <div class=”grid_2″>photo’s</div> <div class=”grid_2 omega”>advertisement</div> </div> </div> 我们可以简单的添加”alpha“样式来去掉左边的间距，添加“omega”样式来去除右边的间距。这样我们刚刚创建的这个例子在任何浏览器里面就很完美了（当然包括IE6）。 样式 好了，你现在已经完全了解如果用960框架来创建一个网格布局的基本原理了。当然，我们也可以添加一些样式到我们的布局中。 <div class=”container_12″> <div id=”sidebar” class=”grid_2″>sidebar</div> <div id=”content” class=”grid_10″> <div id=”main_content” class=”grid_6 alpha”>main content</div> <div id=”photo” class=”grid_2″>photo’s</div> <div id=”advertise” class=”grid_2 omega”>advertisement</div> </div> </div> 因为CSS使用特性来确定哪一个样式声明具有高于其它样式的优先级。”id“比class更重要。 用这种方法，我们可以在自己的文件中重写那些被class设定的规则（比如宽度，padding，边框等）。 我也添加一些样式，它们整整花费了我5分钟来整理整个例子。查看示例的源代码和样式声明。. 搞定 就这样。你已经学习了如果使用960框架来建立跨浏览器兼容性和整洁的布局了。当你完全掌握了960框架后，你将大大地减少编写CSS的时间。 如果你还不理解，研究一下示例吧。 我留给你的问题： 你使用960CSS框架吗？或者你使用其它框架？你认为框架可以帮你提升你的代码吗？ Translate From: divitodesign 来源：http://www.qianduan.net/960css-the-framework-of-the-basic-principles-of.html
写很很透彻，把码农解决bug的过程都包含进去了，至少我就是这样的。下面的文章和《各种流行的编程方式》有异曲同工，请你不要理解错了。本文来源，翻译如下：——————————————————一个非常严重和困难的bug，能够成就一个饱经沧桑深受压力的有经验的专业程序员的职业生涯。经受这种考验的创伤程度，相当你受到了一次严重的身体伤害，离婚，或是家庭成为的离世。研究人员在研究了计算机编程心理学后，得出了一个程序员们在解决一个困难的bug时的心路里程。这些不同的境界，很像为大众所知的Kübler-Ross Stages of Grief（这个模型描述了人对待哀伤与灾难过程中的5个独立阶段（否认，愤怒，耍赖，抑郁，接受）。绝症患者被认为会经历这些阶段），而且原因都很相似。就好像死亡所伴随的悲伤一样，fix一个bug是一个过程其初始化了一个事件，一开始是拒绝相信，其造就了你苦闷的情绪并开始逐步影响你的心智。这种苦闷的情结果会让你纠结要努力忍受，最终会你会找到一个满意的结果。了解下面这几个bug-fixing的阶段，会让我们更好的生存下来，并持之以恒，最终带来……关闭我们所有的bug的结果。第一阶段：抵触本阶段的状态: 多疑 Skeptical. 生气 Offended. 易怒 Petulant.1. 不理睬也许这个bug会安静地离开。2. 标记上“不是bug”也许这是用户的错，或是本地配置有问题。是的，我确信就是那样，一会就会好的。3. 就是一次小故障我想这就是一次小故障，很奇怪地发生了一次，它不会再发生的，虽然没有搞清楚是为什么发生了，不过这就好像我们的数据库，网格，浏览器或别的什么打了几个嗝一样。一会就会好的，我确信。4. 躲藏.我要休几天病假，也许他们会把这个bug转给别人的。5. 标记为“修改需求中”你看，我是按照需求实现的。如果你们想要改这个行为和UI，就一定要修改需求。也许他们会决定就这样了。6. 需要更多的信息我不能确定这是一个bug，除非我能在错误日志中看到一条特定的报错信息。7. 转给其他人我调查这个bug中看到了其它模块中我看不懂的数据，问题很大。我应该把这个bug转给开发那个模块的人。我可以在我的模块中检查一下那个边边角角的情况，但是正确的fix应该是在别人的模块中。反正那个在别的国家，我见不着他。第二阶段：接受本阶段的状态: 认命 Resigned. 被打击 Defeated. 被激怒 Annoyed.1. 接受现实行了，行了，行了！这是我的bug，我会修正它的。2. 把这个bug放到最后也许，我可以在我需要fix这个bug之前找到一个新的工作。3. 和你的经理讨价还价好的，你看，我可以正确地fix这个问题，不过我需要一个月。也就是说，我可以给这个问题贴个创可贴，那不会真正的解决它，但是我们可以避免用户的抱怨，这可以为我们赢得几天的时间。4. 为这个bug标记一个无耻的时间上帝啊，我希望这时间够了。第三阶段： 投入和沮丧本阶段的状态: 眼花 Giddy. 头晕 Light-headed. 紧张 Nauseous.1. 开始调查我能搞定它，我能搞定它！只需要小小的调整一下，小小的关注一下，多一点咖啡因，再加上一点时间，我能搞定它。2. Befuddlement.Shit. 这太扯了。我居然没有一点进展。这代码真是乱。这样的代码居然能编译和运行，真TMD的神奇，我有机会能搞清楚它什么不正常吗？3. 再次躲藏你看，很对不起。我不得不要去切除我的阑尾。再一次，是的，既然你提到了它，我的确有两个阑尾。现在我一个也没有了，你高兴了吧？。4. 犯贱好吧，总之，你到底期望什么？想让我在一个没有高级调试器的环境下改这个BUG。我是什么？千里眼吗？我在我的Commodore 64上一个更好的调试器！5. 瞎搞看看我试试这么改？Kao，这样不行。要不然这样搞？也不行。那么那样搞呢？Shit，虽然再糟糕。6. 绝望我不可能fix这个bug了。我是个糟糕的程序员。我太笨了。我在这个满是聪明人的地方干什么？迟早他们会知道我的能力太差，那时我就玩完了，在这也混不下去了。7.耻辱我的经理问我为什么我用了一个月的时候来fix这个只需要两天就可以解决的bug？老实说，我不知道怎么去读日志信息，我搞坏了我们的编译脚本。现在，我不敢去让别人来帮我，因为这样只会让我显得更愚蠢。8. 恐慌！这事变得比我相像的要复杂！而我开始觉得复杂的事变得简单……而我觉得简单的事变成需要重定半打的类。为什么我以前在我的经理前拍着胸说我可以搞定这个事？9. 通宵工作，远离朋友和家人(语无论次的喃喃自语，一阵一阵地大声咒骂)第四个阶段：愚蠢的快感本阶段的状态: 感恩 Grateful. 安心 Relieved. 极端地自我欣赏 Awfully Impressed with Yourself.1. 醒悟哦！我终于明白怎么搞定它了……2. 写正确的代码我真NB，我是编码机器！3. 测试牛！通过一个测试。真牛！又通过一个测试了。靠！有测试失败了。这是为什么……4. 隐藏测试失败反正这完全是一个不重要的测试案例。没有人会检查它，这个测试真是毫无意义。5. 提交代码我太牛了，厨房里有个馅饼可以庆祝一下吗？6. 关闭 bug.我听说那里有个馅饼可以庆祝一下第五个阶段： 与“完成”肉搏本阶段的状态: 焦燥不安 Twitchy. 神经过敏 Nervous. 迷信 Superstitious.1. 有人reopen了这个 Bug真的？他们发现了你引入了另一个bug？ Shit – 那只是一个不重要的案例永远不会发生的。2. 修正以前的修正是的，我甚至检查了员工的年龄是一个虚数的情况，就是为了防止出错。3. 关闭 bug是的，贱货，你被关闭了。全部都关了，再也不用心烦了。4. 发誓以后再也不干这种事了5. 大家都意识到你现在是那个模块的专家了哦，不！现在他们又给了我三个那个模块的新bug没关系，现在你只需要GOTO 第一个阶段。此外，作为一个工作中的程序员，你会永远经历这些烂事，直到你——死亡，退休，或是被升到管理层。（全文完）原文网址：http://coolshell.cn/articles/4045.html
这里我并不说是axis1和axis2的什么不同，只是最近接触到了axis1和axis2的应用而已。 情况是这样滴。 公司的系统架构是公司外部系统的接口交互都要走公司的接口层，再由接口层将信息透传给公司内部的各个系统。 接口层使用axis2来架构，我这块的接口部分是使用axis1架构的，这个框架用了好几年，相当的成熟，看代码中的注释，最早的有02年写的代码，听说是很早那一批海归写的。 按理来说，高版本一般都会是兼容低版本的，况且对于axis来说，只要是标准的wsdl就可以，可还是有些区别的。 我使用axis1可以正常调用和返回，接口层可以调用也可以返回，看日志，调用的输入和输出都是正常，可在接口层那边就是取不到数据。同事和我整整查了一中午问题，公司对接口很厉害的高手也没有个办法。 最后，还是用最底层的办法来查，webService的本质还是xml，查看输入和输出的xml，输入没有什么问题，输出还是发现了一些端倪。 作为一个返回对象，属性内容是包含在ns的标签中的，在我们输出的xml文件中，ns标签标签中出现的是mutilhref="#01" ，在ns的标签外面，有个#01的标签，在#01中包含着输出的内容。接口层使用的是axis2取数据是从ns的标签中取的，当然是取不到标签外的值，axis1是可以取到的。 让接口层改用axis1，为了保持整个框架的统一，肯定不能改，我们改成axis2，时间不允许。有问题就google、baidu了，最近google搜索，都是搜索的繁体或者英文，简体的好些不是很方便，有时google还打不开，有些厌恶baidu的搜索了，现在用有道多一些。对于axis1和axis2的这个问题，整个网络上面，就只有一个09年的帖子提到，让关闭一些wsdd中globalConfiguration的sendMultiRefs设置为flase。 设置为false之后，再次调用，ns标签外的对象就被包含在ns中，不会采用引用的方式了。 在http://axis.apache.org/axis/java/reference.html有几个配置的解释，没看到有中文的解释，按照我自己的理解，意译下。 sendMultiRefs true/false flag to control whether multirefs are sent or not. 是否使用引用对象的方式 sendXMLDeclaration true/false flag to control whether the <?xml?> declaration is sent in messages 是否包含xml头文件的信息 sendXsiTypes true/false flag to enable/disable sending the type of every value sent over the wire. Defaults to true. 是否在每个值中都标注值的类型参数
最近公司在搞封闭开发，其实也就是把相关的几个部门的人集中在一起做开发，这样很便于交流。公司要求加班，这次的加班的报酬还算不错，让人有些能加班就有钱的欲望。不过，这钱是一方面，另外一方面是要有干活的激情。这一方面，我觉得公司很差劲，让人觉得是这就是一场买卖，我干活，你给我钱，给不了人一种归属感，有谁会很有心的用干啊！ 我很佩服之前公司的老板，本来就是做销售出身，换了好几十个工作，阅历丰富。和他聊天，如果脑子不清晰点，就会被他进去，但说的都是很有道理，而且，说起来，会让人很兴奋。在公司打硬仗的时候，他的勇气论很受用，每个人都能拼了命的去做，这点也就是现在我所在公司缺少，我现在还没发现有哪个人有这样的能力。 这几天每天都是2点了才睡觉，每天我都是想着早点睡的。晚上回来都快10点了，再稍微先乱整一下，就11点了，再想看点东西、写点东西，就过12点了。现在有点自己的想法，就想快点去做，每天都在逼自己，先把这段时间忙过完吧！忙完，一定要出去转转。前几天在看TYPECHO的源码，其中有说到，采用组件的模式，在基本完整的看完TYPECHO的源码后，需要纠正一下我的观点，TYPECHO采用的WIDGET的方式，MVC的模式在主题中还是使用的，一个稍有架构的系统，最起码的要求应该就是UI层和逻辑层的分离。本来是打算自己用PHP写一套适用于自己的框架的，在研究TYPECHO后，这个对我这个半路出家的PHPER来说，还是有相当的难度的，考虑后，决定使用一些框架来做吧！看过一些PHP的框架，thinkphp、 codeigniter、zend framework还有一些其他的，各有特色吧！我的选择是简单、能快速上手、扩充性好的，如果能在性能上也有优势，那就更好了！
现在在IT这个行业里面，做一点点东西出来，就出来谈架构，所以我也出来溜溜了！哈哈！已经写过一次了，没保存，给没有了，这次是重新写的，之前那次的灵感没有了啊！我参与过一个大型的项目，采用的是JAVA开发，使用的是MVC的模式，用流行的SSH来架构，项目的特色是引入了中间件。最近我研究的就是typecho，用PHP开发，我特别看好的采用的是WIDGET（组件）的模式，任何一个功能都是一个WIDGET。我就准备在下次做开发的时候，就使用WIDGET的模式，MVC的模式太流行了。MVC的模式也真的很不错，但真的很适合每一个项目，不一定吧！一种模式的使用，总有他的适合的场景，看一下现在到处都是的项目，基本全是MVC。最近准备做个小系统，我的本行是JAVA，如果用JAVA来做，在加上快速的MVC的话，我也能玩得转，不过，我想换换，毕竟，作为一个码农，专一一种语言是好事，换一种语言、换一种模式，是一种挑战，这样才好玩嘛！现在还在继续研究中，对于WIDGET的方式，还不是很懂，虽然TYPECHO是开源的，而且注释写的很好，我还是很多的不明白。我研究的方式就是从index.php来跟踪，一行一行的把代码重新写一次，继续研究吧！希望自己能尽快写出这样的代码啊！
讲的还算是很形象，作为一个项目管理的寓言还不错。原文地址：http://www.otakustay.com/mario-project-management/超级玛丽奥，一个无比经典的游戏，在红白机上的受欢迎程度无出其右，游戏的设计必有其出色之处，才导致那么多人的痴迷。本篇文章试图将超级玛丽的游戏设计的部分理念和细节转换为项目管理的方案，使用游戏的方式去管理项目，找寻一条快乐的管理之道。游戏的组成超级玛丽的游戏组成非常简单，只有几个必要的概念，但是可以玩出无数的花样：主角一个水管工，名叫玛丽奥，某天他的公主被邪恶的大魔王抓走了，于是开始了拯救公主的征途……在项目中，主角无疑是整个团队，首先保证整个团队的一致性和不可分割性，使其成为一个单独的个体，而非若干个个体组合起来的松散的组织。当团队拿到项目的这一刻，就如同站在屏幕左边的玛丽奥，一段征程就此开始。关卡游戏的最基本组成是一个一个的关卡，每一个关卡最后都有已知的惊喜（不是一个城堡就是一只公主），正因为关卡这个概念的存在，才造就了游戏的多样化和挑战性。相对项目来说，一个关卡可以变成一个里程碑，每一个里程碑最后也都有着预先准备的“惊喜”。每一个里程碑成功交付之时，作为管理者，必须让所有成员意识到我们又突破了一个关卡，这是值得庆祝的事，并且要让每一个成员都认可这是团队一起努力后应得的结果。坑出于游戏中怪物智商普遍低于平均线，“坑”这一事物反而成了游戏中的一大障碍。跑着跳着欢快着，一不小心掉进个坑里，是多么没有面子的事情。对于项目，所谓的坑，自然是一个又一个的困难。在一个里程碑开始之初，就应当规划好整个头上的“场景”，整个团队有权利也有义务知道，按照小小主人公的奔跑速度，在什么时候会遇上坑，是一个怎么样的坑，以便团队事先做好应对的措施。而坑也是游戏中极富多样性的一个元素，也许玩的时候并没有仔细地分析，坑的各类其实是很多的：标准坑大量存在于各个关卡之中，只要按标准的速度“走”过去，在适当的里面起跳就可以轻松地跃过。但是永远也不要小看这样的坑，当地形变得复杂，一个又一个的标准坑连在一起，中间只剩一个人的容身之所，就会让游戏的难度大大增加。同样，在项目中，最常遇上的困难也就是如此简单的标准坑，只要团队按着计划的步调前进，在适当的时候给予一次小小的冲刺，就可以安全地度过。但是当这类不大不小的困难连续出现，在解决一个问题之后又紧接着出现另一个问题，之间只留下勉强喘息的时间之时，就是对项目组的一个考验。如果在项目开始之初就对关卡的地形了如指掌，事先做好全面的心理准备，在通过的过程中调整好自己的步调，相信绝大多数的“玩家”还是不会败在这种环境之下的。大坑大坑的跨度之大，足以让没有充分助跑就随意起跳的玛丽奥同志坠入无限的深渊。在初代的游戏中，最大的一个坑甚至需要足够的助跑，在平地的边缘起跑，才可以勉强地落到对岸。大坑对项目来说绝对是一种挑战，在这段时间内，项目组将不可避免地出现火力全开的情况，甚至要为此加班加点。但即便如此，如果没有之前的助跑，无论你的弹跳力多么超群，在大坑面前都无法避免跌入地狱的结局。因此作为项目进度制定者，对于大坑必须有明确的标识，提前一定的时间知会整个项目组。此时项目组需要开始调整自己的节奏，为即将到来的攻坚战作好准备，以最大的冲刺速度突前，直到坑的边缘，决然地起跳。每一次跃过大坑，都会给玩家带来成就和喜悦之感，往往项目也正是通过对困难的征服所带来的成就感，才得以保持整个团队的士气，一直向着最后的终点冲刺。碎坑碎坑是一种很特殊的坑，他由非常多但非常窄的坑组成，每2个坑之间仅容下一个身位的立足之所。在项目的进行过程中，遇上这样的情况也是不可避免的。小小的麻烦总是不断地骚扰，当一个函数出现了点问题、当客户来电说需要有一个小小的修改、当有同仁身体不适需要休息……而当这些细碎的问题撞在一起时，一个典型的“碎坑地形”就出现了。那么如何去应对矿坑地带呢？玩过游戏的人都知道，面对这样的地形，与其小心翼翼地从每一个坑上跳过、屏住呼吸随时注意自己的下一个落点、提心掉胆有惊无险地通过，不如在不远处开始加速，以飞奔的速度从上面通过，碎坑是可以直接跑过去的，而不需要起跳这样笨拙的动作。同样映射到项目之中，当面对一个碎坑地形的时候，如果管理者可以及早地发现问题，并通告整个团队。那么团队只需要一鼓作气，加快自己的节奏，哪怕无可避免地有一些加班加点的情况，但只要拥有足够的速度，碎坑将如同平地，无法给项目的进度造成任何的阻挠。砖砖也是游戏场景中无处不在的重要元素，主角可以拿他那比金子还硬的拳头（绝对不明脑袋）去敲一下砖头，至于砖头里有什么，那就另当别论了。当然可以肯定的是，不会敲出一个BOSS来：）在项目中，砖可以是一些起眼或者不起眼的小细节，而是不是去敲这个砖，并不会影响到项目整体，即便一个砖都不敲，项目最终也是可以交付的。只是砖作为一种额外的收益，如果花些心思去敲了，往往能得到一点什么。同样的，砖也有很多种：普通砖普通砖遍地都是，稍微敲一下就会碎裂，但往往不会给出什么东西。当然也存在极少数的情况，会出来一个蘑菇或者一朵鲜花，当然也有敲不完的金币。总得来说，普通砖里充满了机遇，但过分追求的结果往往是失望。对于项目，我们也经常能看到这样的现象，一个小小的元件摆放在那边，从各个角度看都有让人重构的冲动。但是对于管理者来说，这样的重构是不是值得，敲下这块砖会不会出现自己需要的收益，却是一个非常需要关注的事情。在大多数的情况下，我们并不反对去敲每一块砖；但是如果希望项目在绝对最短的时间内完成交付，是不是也同样可以选择忽略那些平凡的“砖”，用这一跳的时间去做更值得关注的事？方砖如果不是因为这东西不能拿去砸怪物的话，我很乐意称之为“板砖”。这是何等坑爹的一种砖，他就是那么一个广场，无论你怎么敲他，他都不会碎裂，也不会挤出哪怕是那么一丝的分数给你。当然项目中这样的情况也不少，当你从一开始就走在一条错误的道路上尝试，无论怎么努力也得不到回报。但是请不要气馁不要绝望，正是因为有这样无数的尝试，你的团队才能确定这块砖是不是真正的方砖，是不是绝对不会产出任何的收效，这样团队才可以在日后遇上类似情况时避免进入一个无谓的圈套去挣扎不休，而是直接忽略那个看起来充满诱惑的炸弹，直接冲向目标。要相信项目中每一分投入都会有相应的回报，每一次努力都有其应有的价值。问号砖问号砖太显眼了，除了上面有个大大的问号，还会不断地闪烁着光芒提示你来敲。而且，问号砖是不会不给你东西的，少则一只蘑菇，甚至有可能是一个无敌的星星。唯一的遗憾是，问号砖的数量还是比较稀少的。项目中，把握好每一个问号砖是非常关键的，一个砖带来的收益往往能起到决定性的作用，正如一个无敌星星能让你在以后很长的一段路程中平安无事（前提是别傻到掉坑里）。一但发现有一个如此闪亮的砖头，即刻组织一定的人力物力去敲掉，收益绝对能大于成本。这样的砖往往是一个全新进入视野的第三方组件、或者一位有意合作的资深人士、或者一款制作精良的工具，他将为项目接下去的进度提供足够的推力，不仅仅是对项目执行的帮助，也是整个团队士气振奋的关键所在。最终BOSS最后的BOSS，抢走我们（一点也不）可爱的公主的大魔王，库巴老乌龟，他始终那么耐心地将公主绑起来放在自己的房间里，然后站在一座桥上面等着主人公的来到。从剧情的角度看，库巴实在是无比可爱，无论是哪一个关卡，都会充满耐心地迎接剧情……对项目来说的最终BOSS，那无疑就是项目的交付了，虽然说交付往往并不是终点，但是对于项目来说，至少是很大很大的一步，称其为BOSS也没有任何的过错。玩游戏的都知道，库巴有2种打法，其一是慢慢地虐死他，其二是跳到他身后碰一下那个斧头，然后咔嚓一下库巴就掉火里去了……相对的，项目的交付也有两种方法：其一，简单地完成项目的需求，给予一个最低限度可运行的成果，完成基本的交付工作，获得项目的相应报酬。这算是一种皆大欢喜的结果，项目组使用了最合理的人力物力，完成了项目的需求；客户也拿到了其所希望的产品，并为此支付合理的报酬。其二，深入地理解客户的需求，不断挖掘出潜在的需求，完成良好的设计，构架起精美的实现，最后交付一个超出客户期望的产品。也许对于项目组来说，投入了更多的人力物力，却最终只得到合同中协议的报酬，就好像费劲力气折腾死了库巴，最后也就和（一点也不）可爱的公主说上一句话。但是玩游戏的人能从中体会到更大的乐趣，项目也是一样，在收获合同规定的报酬之余，项目组也获得了客户更好的认同，以及客户的忠诚度，为未来的发展打下了一个基础，在将来的某一时机，会得到应有的回报。项目过程在“超级玛丽式项目管理”中，我们将游戏的元素运用到项目，让所有成员可以更直观（相信多数人玩过超级玛丽，也知道这些概念）地理解项目的整个过程，以达到更紧密的团队合作。项目启动之初，项目经理必须能够根据项目的进度安排，与技术经理一起制作出“关卡”和“地图”，一个关卡即一个里程碑，在每个关卡的地图中，要明确标识出“坑”的位置以及大小。随着项目的启动，我们的主角玛丽奥先生将会出现在地图之上。随着项目的推进，先生也不断前进着。从地图上可以轻松地看出，项目是不是快要遇上“坑”了，会是一个怎么样的坑，全团队都可以直观地对项目的现阶段进展进行理解，当有“大坑”出现时，提前作好冲刺准备，当“碎坑地形”出现时，鼓足干劲通往直前……当然，项目并不是游戏那样有着最初静态的设定的。项目必须随着时间的推移不断地拥抱变化，地图也需要实时地进行修改，甚至加入一些通过下水道进入的特殊关卡，甚至是下水、上天等特殊情况。相信熟练玩游戏的开发者们，不会面对游戏的变化产生任何害怕的情绪，相反，也许会激起他们的好胜之心，更加投入地去解决困难。最后，当我们的主角站在桥上，面对着最后的大魔王库巴老好人的时候，团队作出最后的努力，战胜BOSS，解救公主，然后是盛大的庆祝，一个项目圆满落幕……如何让成员更有干劲至此，一个项目的元素基本齐全，项目可以稳步地进行。但是过于稳定的环境，会逐渐让项目成员产生疲倦的心态，效率也会按一定的曲线开始下降。这对于管理者来说，自然是不愿意看到的现象，因此，必须有一定的激励机制，让成员可以随时处在一个较好的心理状态。在游戏中也有一些这样额外的元素，可以引申到项目之中，对成员士气的激励有着非常好的效果：生命蘑菇游戏中最充满传奇色彩的元素，怎么看都不能吃的绿色蘑菇，却有着生命+1的效果。生命蘑菇永远出现在不可见的地方，当你在特定的位置停下脚本，轻轻地起跳，突然就出现了一块砖，一只漂亮的蘑菇落在你的脚边……对于项目来说，生命蘑菇就是对成员额外的努力的奖励，每一个成员都有完成本职工作的义务，但是在义务之外，如果对项目有着卓越的贡献，自然需要给予相应的奖赏，以至最后形成一个良好的循环，每一个成员都会自发地从项目的角度寻找突破口，并自觉地给予更大的产出。生命蘑菇的哲理是“你永远看不到他，但他就在那儿”，只要自身足够努力，他不会离你太远。怪物（们）怪物在游戏中几乎以弱智的形态出现，对玩家没有太大的威胁，但是当一脚踩扁一只蘑菇，一下踢飞一只乌龟，这种快感也是游戏吸引人的重要因素。因此在项目中，作为项目正常进行之余，定期进行总结、交流，提出一些更具挑战性的“子项目”来“玩玩”，确实有助于保持住团队成员的状态。同时，怪物是多样性的，技术的攻关也要具备多元化的特点，让不同职位、不同专长的人都可以平均地得到表现的机会。其他元素游戏中还有很多其他的细节，每一样都能映射到项目中的某个方面，比如：超级玛丽的任何一关，只要按住奔跑键和向前键，在适当的地方起跳，绝对可以毫不停留的冲到终点。但是一但有一处的停留，后面的进程反而会遇到种种麻烦，不是躲避满身是刺的怪物，就是各种大坑需要计算距离来助跑……除了库巴老同志外，每一关卡的最后都有一根旗杆。其实拿到旗杆的满分非常容易，但是无数玩家为了能跑过杆子而孜孜不倦地努力着。但其实这根杆子是跳不过去的……玩家只是看到了这么一丝希望，他们就会不断去努力。初代的超级玛丽不够刺激，变因不够多，用作充满变化的项目不适合？那么看看这个变态版的超级玛丽，想办法再用到项目中去？
我在项目中的笔记1【开篇】 工作也很久了，说大点，给别人还能吹吹，说自己还带过团队，管过项目，可实际肚子里面装了多少，自己最清楚，能骗了别人，骗不了自己，所以啊，就把自己在项目中的经历记下来，或许是经验，也有可能是教训，还有可能记录的是失败。很阿Q的说，是比不小的财富。 笔记的内容会很杂，围绕的主题是自己的项目经历，其中我会找些项目方面的资料，也会加进来，做为自己的学习笔记。 作为开篇，做个卷首语。
2011年初的记事 2010年的总结其实蛮多的，现在总觉得缺少时间，也就意思意思一下了。活在当下，还是个很流行的概念，重点还是放在现在吧！ 对我来说2009年，是个拼的年，2010年是个放松的一年，2011年，是个决战年。2011年之前，我还能混，还能任意而为的，今年还行吗？我只能说，现实真的很残酷，我必须做出一些选择出来。我现在能做的选择也就是暂时的工作方向，其他，真的好难，迷茫了。 说说最近的事情吧！ 一个是我的空间因为年前放进去了MP3，MP3被百度收录了，我空间了流量，没几天，就超标了，现在一因为是月初了，空间的流量做了重新统计，我也才开始写的，乘着现在的才思敏捷，多写几篇了。 另个一个是比较高兴的事，麦库送我了额VIP用户，不过，现在麦库做的还没有EVERNOTE好，所以用的还是EN，等麦库做的好一些了， 在转吧！其实麦库还有一些事情，透露一下，因为麦库没有linux的版本，我联系的麦库，准备开发linux版本的麦库，不过，最近麦库的开发人员说，他们经理请假不在，等经理回来了，才继续谈谈。这个，是我的个人兴趣吧！不过，也不一定会做，毕竟，我还有其他的事情来做的。 在就一个，说实话，我今年是打算放弃这边的一切发展，另谋出路的，因为老大给我说的，要有“要”的意识后，我决定留下来“要”了。老大的意思是，当到一定程度的时候，就需要去“要”东西，不能去等，这次和我一向的做法不一样的。其实我也想有那些东西，只是我觉得，做的能到那个层次了，那些东西自然而然就是你的了。要和抢，不是我的作风。 具体我要到了什么东西，或者是别人帮我争取到的，下篇再提。
用两种方式实现第一种，使用timertask实现，timertask，可以比较精确的实现定时任务。在这里插一句，java的实时性是很差的，timertask也就是大概的可以实现看代码：Producer.javapackage me.dapeng.timer;import java.util.concurrent.LinkedBlockingQueue;public class Producer extends Thread { private LinkedBlockingQueue queue; public Producer(LinkedBlockingQueue queue) { this.queue = queue; } @Override public void run() { int i = 0; while (true) { queue.offer("string" + i); // System.err.println("[Producer]queue size:" + queue.size()); i++; } }}Consumer.javapackage me.dapeng.timer;import java.text.SimpleDateFormat;import java.util.Date;import java.util.TimerTask;import java.util.concurrent.LinkedBlockingQueue;public class Consumer extends TimerTask { private LinkedBlockingQueue queue; public Consumer(LinkedBlockingQueue queue) { this.queue = queue; } @Override public void run() { SimpleDateFormat formatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); String date = formatter.format(new Date()); int size = queue.size(); try { if (size > 0) {…