Behind the Code

有没有遇到过这样的时候，一个手欠，或者没注意，一个还没有完全写好的功能就放到主分支上了，而且还很幸运的打到release里面。好吧，你没那么幸运，但是几个经验不是很丰富的小弟把代码随便传上来，你总得看一下吧。 这个怎么搞呢？难道你跑去每个人的地方看看？看着他们跑测试用例？跟着他们做Code Review？一两个人还行，人多呢？要是人不在你身边呢？比如远程开发？如果组织结构更大一点呢？开发团队在开发，测试团队在测试，这样很可能一个没有经过充分测试、检查过的代码版本，就被测试团队抓走了，然后可能就是一堆的问题咯。其实有问题还好，要是有问题没检查出来，那就更麻烦了。 所以，利用bzr的这种天然的DVCS的优势，添加了一个叫做Gatekeeper，看门人的概念。这个概念说起来是很简单的，就是所有的代码，该提交提交，该搞啥搞啥，但是呢，不是提交到主开发分支哪里，而是提交到看门人负责的一个分支上，由他来进行统一的测试审查等等。等完事OK了，他（只有他）再提交到主分支上就好了。这样就保证了所有的问题，低质量的代码，都被看门人挡住了。 看门人可以是一个人，也可以是一个团队，只要能够保证产品的质量就可以了。 比如在服务器，代码都是放在/repo/main上面的，哪么现在根据main生成一个dev.main的分支，所有的人都是基于dev.main进行开发。而测试团队则选择main进行测试，这样开发和测试就已经分开了。然后看门人保证dev.main的质量，当质量达到一定的水平之后，并且代码稳定了，就可以把dev.main merge到main上面了。

bzr 是一个分布式的版本控制工具，如果我们还那他当svn使用，那就有点暴敛天物了。 所以我们就得按照bzr的方式办事。 svn方式开发最大的问题就是当n个人开发不同的feature，又来回影响时候，基本上就只能使用branch了，否则就玩完了。这时候就得靠DVCS了。而对于所有的DVCS，都是天然的支持轻量级分支，或者天然的就应该按照分支进行开发。 我们可以按照如下的方法开发假设服务器是  /server/repo我们在开发的时候不是想svn一样使用checkout来创建本地工作区，而是在本地做一个服务器代码库的分支，然后进行本地开发。以bzr为例子就是bzr branch /server/repo [local_proj_name]这时候这个local_proj_name是一个服务器工作区的分支，可以进行开发了，并且所有的提交都是本地的，不会影响到服务器的工作区。 如果你和别人一起共享一个服务器的代码库，随时获取最新的代码，在svn里面是使用update，在这里是使用pull，如果出现了和本地的冲突，哪么就需要使用merge来进行合并了。等你在本地工作区都开发好了，也本地提交好了，哪么使用push在传回服务器的代码库就可以了。 这里我想说一下pull和merge的区别。pull的意思是把代码同步成为服务器代码库的代码，并且版本号也发生变化。pull操作成功后，本地就是一个提交后的状态。merge的意思是把服务器代码库的代码，合并到本地，此时仅仅是内容的变化，版本是不会发生变化的。所以merge之后，本地是一个修改后的状态，还需要提交一次，本地才是一个提交后的状态。 比如服务器代码库只有一个文件，叫做readme.txt，在版本是9的时候，readme.txt的内容是No。版本号码是10的时候，内容是Yes。 如果我本地的工作区，是从版本号码为9做的本地分支。我现在pull下来，哪么我本地readme.txt的文件的内容是Yes，本地分支版本号码是10，处于以提交状态。如果是merge下来，哪么本地readme.txt的内容是Yes，本地分支版本号码是9，处于已修改状态，需要自己提交以下，是本地的版本号码达到10。

Apache的认证体系很不错，但是他并不是和操作系统天然结合的。如果想要让Apache使用操作系统的用户进行认证，可以使用 mod_auth_shadow 或者 mod_authnz_external 来进行。 我使用的是 mod_auth_shadow，因为简单嘛。 下载之后自己进行编译，会有两个有用的文件，mod_auth_shadow.so 和 validate 。 配置Apache，我使用的是Apache 2.2 加载module，LoadModule auth_shadow_module /path-to/mod_auth_shadow.so 配置 VirtualHost添加如下几行       AuthName what-ever-you-like       AuthShadow on       AuthType Basic       require valid-user 还可以使用 require user/grouprequire user user1 user2require group group1 group2 这样你就可以使用了。 注意， 其中的 validate 是进行真正认证的程序， mod_auth_shadow 是会通过 pipe 和 validate 进行交互的。 validate [...]

本来是要给公司写的一个文档，但是觉得很有用，所以拿出来和大家分享一下。 趁热尝尝，还冒热气呢。 鉴于我实在是不想在折腾一次了，大家凑合着看这个语法错误百出的英文文档吧 ===================文章的分割线，耶耶===================== Build Up Full Performance Model From Scratch Performance Issues are the big thing for a system. Lots of time, we need a performance model to get the detail performance information. This document is talking about how to build up a performance model from scratch. Checkpoint First of all, the goal of [...]

网上的评价已经说烂了。 我说说我的想法。 和谁竞争？没人，如果有，那可能是Opera Mini。 为什么是WebKit？因为WebKit在嵌入式系统表现非常良好。 Google产品的一贯作风？让你在浏览器中就获得了应用程序的体验。 哪么？ 当你拿着一个手机，里面没有操作系统，只有一个固化的Google出品的浏览器，开机就启动这个浏览器，然后就可以使用一些看上去就是应用程序式样的网站。你觉得如何？ 为什么每一个Tab都是一个进程？你总不想在手机上因为访问了一个网站Crash掉了，而重启手机吧。 所以，在下不才，认为Google浏览器的终极目标实在嵌入式系统。 特此留证。

今天下午发现了一个大BUG，好大啊，是我自己的一个DataModel组件不支持数据库的联合主键（composite-id）。然后为了修正这个Bug，我必须要对代码的设计进行改动，这时候，如何保证我的代码修改完了是正确的呢？再次感受了TDD。 好在我人品不错，以前一直有写TestCase的习惯，虽然不多也不全面吧，但是聊胜于无，多胜于聊嘛。在对现有的TestCase进行了简单的修改之后，使得在使用的时候可以使用上联合主键了。也就是从TestCase，使用，设计的角度，DataModel 开始支持联合主键了。然后就是编码，修改，重构，跑TestCase。 今天让我感觉很爽的就是，其中有几个比较诡异的Bug，如果没有TestCase的帮助，我真的是自己想不到的，毕竟这个东西已经有月记没有进行这么深层的改动了。看着一次一次的大红线，大红块，逐渐的变成绿色的，感觉真的是很爽的。最爽的就是，我基本上是可以比较自信的告诉别人，这个东西是可用的，而不是颤颤巍巍的告诉他们，这个，嗯，没测试过，你们包涵吧。

今天继续很早睡了，凌晨4点，够早吧。 完成了第一版的几乎所有功能，当然仅仅是完成了功能。在使用ScrumWorks进行自我管理的时候还是可以的，但是自己一个人就有一个大问题，就是基本上想到了什么任务就做什么任务，而没有从最初就设定一系列的任务然后自我分配，这就是项目管理的最大的问题。我想也许是因为一个人的缘故吧。但是这里面存在的一个问题就是，这样干到哪想到哪的方式，是很混乱的，几乎就是没有管理嘛。要非说有，也是存在于一个自己脑子里面的一时干不完的TODO list。 为了改变这个龌龊的做法，我对自己进行了如下的要求。 设定最终完成要达到的状态，也就是做的这个东西要满足什么需求 根据这些需求拆分功能和组件 设定Milestone，每一个Milestone要完成什么东西 根据情况设定工作时长，每一个Milestone的完成时间（这个可以酌情） 使用一个工具记录下来这些 Just Do It 这里面的几个难点 针对上面的要求1，很多时候我们是做不到的，也就是我们在做一个东西的时候，大多的时候只有一个笼统的想法，和最后我要把这个东西做成一个什么样子。但是具体的是什么，也许我们并说不清楚。这个东西越大，越说不清楚。所以，我要求自己停下来，好好的想，我到底要一个什么东西，我要干什么，要实现什么功能，要满足我什么需求，这个一定要想清楚。 针对上面的要求2，我们大多时候，是不能非常好的进行拆分的，我们缺乏的是经验，没办法，多做吧。 针对上面的5，一定要用一个工具记录下来，因为你不记录下来，没有监督，那不就是自我安慰了么。现在的工具很多，Trac，Redmine，很多很多的。最不济的，记事本你总有吧，纸笔你总有吧。 在这个为期两天的一个土鳖小项目里面，我发现工具的重要性，我现在是Bug，REF，什么的都放在Trac上面，但是我的Task，时间管理都是使用ScrumWorks（而且这个还是一个试用版）。我没有找到一个能够把他们都管理起来并且很容易结合的东西。对了，Trac 还不支持bzr。 看来没办法，只能自己写了。现在正在缓慢的进行一个项目，就是做一个完整的 Ticket，代码，时间管理的工具，最好天然的支持Scrum。

现在在给一个自己的网站 http://www.yes7080.com 写一个类似于百度贴吧的功能。当前合作者出去和老婆Happy了，暂时项目只有我自己一个人。想想，也不能瞎写，就使用一些东西把自己管理起来吧。 刚刚看完Scrum，发现和我平常期望的，理想的，使用的方法很像很像（看来我有慧根）。所以打算自己一个人试试看。并结合TDD等方法，把自己管起来。 毕竟，刚刚入门，而且一个人，难免有东施效颦，丢三落四的情况出现。 第一天，也就是今天凌晨1，项目初创开始新项目，使用bzr开启一个新的repository，开工。采用TDD，构建一个最简单的，最土鳖的测试用例，不要求很完整，只是一个对大多数常用功能的简单使用，目的是为了尽快的搭建出项目原型和框架。遵照Uncle Bob的谆谆教诲，在完成一个土鳖测试用例之后，成功的让Eclipse画出来一坨坨的小红线（编译不过嘛）。然后撰写真正的Interface，还有Abstract Class，真不错，终于编译成功。 收获：这个过程并不是一个浪费时间的过程，而是结合了思考，设计，具体请参见我的《初涉敏捷编程》。这过程中出现了很多的对API的推敲，对类的职能的思考。而且，在写真正的接口的时候，可以不用过多的考虑用不到的方法，也就是我总说的，关注一个类的职能。Duty Oriented. 2，开始功能实现有了用例和接口，就可以写实现了。因为项目的特性，一个只读的数据存储结构是最合适的。但是无奈项目时间紧迫，所以我没有这么充裕的时间去选型，甚至设计实现一个适合这个场景的存储结构。所以我把实现分成了多个部分，第一部分，也就是使用传统的数据库作为存储，这样可以最快的实现功能，并且满足现在访问量并不大的情况。以后随着访问量的增加以及时间的充裕，可以继续完善甚至更改存储体系。 醒目的目录结构是这样的./src./src/com/yes7080/saybar （存放所有的接口，并且这是使用时候的统一入口）./src/com/yes7080/saybar/impl （存放实现）./src/com/yes7080/saybar/impl/datamodel （存放使用datamodel，亦即使用数据库的实现）./test./test/src./test/src/com/yes7080/test/saybar （测试代码）实现使用了二级目录结构，也就是使用impl/datamodel，这样的目的就是因为以后可能出现其他的存储方式。而且，正因为这样从目录解耦，就可以更好的进行设计了（具体的设计思想，我以后会撰文解说的）。 很爽的写了很多，很土鳖的没有采用任何的项目管理。工具使用Trac，但是更多的是一个用于文档和Ticket跟踪。所以我决定对自己采用Scrum进行管理。也对自己有一个监控。 最开始，实话实说，我真的忘记了Scrum具体应该怎么开始了，但是非常简单，用户故事（是这样么说么）只有一个，就是实现一个用数据库的存储。我给自己两天的时间，也就是后天天亮之前完成，大约是还有10-16小时的工作时间。然后在看情况进行修改吧。嘿嘿~暂时给自己定一个时间，然后，继续工作鸟~~