mkblog 0.0.1

data/templates/_site/atom.xml

@@ -0,0 +1,936 @@
+<?xml version="1.0" encoding="utf-8"?>
+<feed xmlns="http://www.w3.org/2005/Atom">
+ 
+ <title>Larry Cai</title>
+ <link href="http://larrycai.github.com/atom.xml" rel="self"/>
+ <link href="http://larrycai.github.com"/>
+ <updated>2012-03-06T17:09:09+08:00</updated>
+ <id>larrycai.github.com</id>
+ <author>
+   <name>Larry Cai</name>
+   <email>larry.caiyu@gmail.com</email>
+ </author>
+ 
+ 
+ <entry>
+   <title>Travis CI会替代Jenkins吗？</title>
+   <link href="http://larrycai.github.com/2012/03/06/travis-ci-is-evolution.html"/>
+   <updated>2012-03-06T00:00:00+08:00</updated>
+   <id>http://larrycai.github.com/2012/03/06/travis-ci-is-evolution</id>
+   <content type="html">&lt;h1&gt;介绍&lt;/h1&gt;
+
+&lt;p&gt;你可能用Github了。但是你是怎么自动构建你的开源项目的呢？你的Github项目有“构建状态”标签吗？&lt;/p&gt;
+
+&lt;p&gt;&lt;img src=&quot;http://larrycai.github.com/images/building-status-tag.png&quot; alt=&quot;Github上的项目构建状态&quot; /&gt;&lt;/p&gt;
+
+&lt;p&gt;如果你还不知道这个，你就有些落伍了，因为这是Travis CI带来的持续集成的革新，它可能会替代Jenkins现在的地位。&lt;/p&gt;
+
+&lt;p&gt;让我们一起来看看Travis-ci到底带来了什么，先从Jenkins说起。&lt;/p&gt;
+
+&lt;p&gt;在写这篇博客时，发现好友晓斌也写了一篇&lt;a href=&quot;http://www.juvenxu.com/2012/03/06/travis-ci/&quot;&gt;Travis CI，翩翩而至的CI云&lt;/a&gt;，可以参考阅读。&lt;/p&gt;
+
+&lt;h2&gt;Jenkins介绍&lt;/h2&gt;
+
+&lt;p&gt;持续集成是敏捷软件开发的一个重要工具，开源工具&lt;a href=&quot;http://jenkins-ci.org/&quot;&gt;Jenkins&lt;/a&gt;是实施持续集成首选，大概占据了半壁江山。&lt;/p&gt;
+
+&lt;p&gt;&lt;img src=&quot;http://larrycai.github.com//images/jenkins-jobs.jpg&quot; alt=&quot;Jenkins界面&quot; /&gt;&lt;/p&gt;
+
+&lt;p&gt;Jenkins以前叫Hudson，后来由于Oracle收购了Sun公司，Oracle与开源软件社区谈崩了。Hudson创始人Kohsuke Kawaguchi(简称 KK)一怒之下，和社区的人其他人重起炉灶，建立了Jenkins社区。详细可以看看InfoQ的文章&lt;a href=&quot;http://www.infoq.com/cn/news/2011/01/hudson-jenkins2&quot;&gt;Hudson社区提议将项目更名为Jenkins&lt;/a&gt;。&lt;/p&gt;
+
+&lt;h3&gt;Jenkins功能&lt;/h3&gt;
+
+&lt;p&gt;它有很多极佳的特性：&lt;/p&gt;
+
+&lt;ol&gt;
+&lt;li&gt;易于安装：一个命令就可启动，也方便部署到各种Web容器中（如tomcat)。&lt;/li&gt;
+&lt;li&gt;易于配置：所有的配置都在Web界面实现，权限控制得也不错。&lt;/li&gt;
+&lt;li&gt;插件支持：基本上所有的扩展都是有插件完成的，开发插件也很方便，由此产生了庞大的社区。&lt;/li&gt;
+&lt;li&gt;支持分布式构建：Jenkins能够让通过主从模式（master/slave）多台机器一起构建。&lt;/li&gt;
+&lt;/ol&gt;
+
+
+&lt;h3&gt;Jenkins在企业中常见步骤&lt;/h3&gt;
+
+&lt;p&gt;Jenkins服务器一般先架设在一台服务器上，有配置管理人员管理。&lt;/p&gt;
+
+&lt;p&gt;产品有构建需求后，配置管理人员就新建一个任务，配好源码仓库，设置构建时间，指定运行脚本来编译测试产品，并且设置报告输出。一切都可以在Web界面中运行。&lt;/p&gt;
+
+&lt;h2&gt;Jenkins的一些弊端&lt;/h2&gt;
+
+&lt;p&gt;Jenkins虽然非常好用，但还是有些弊端。&lt;/p&gt;
+
+&lt;h3&gt;多平台或依赖的包&lt;/h3&gt;
+
+&lt;p&gt;如果你的软件想在不同的操作系统软件构建并验​​证，这将是相当有难度和技巧性，一般主要是准备不同的操作系统的机器，然后使用主/从模式进行分布式构建。&lt;/p&gt;
+
+&lt;p&gt;在C++中你可以使用有关的交叉编译器，一个不错的解决方案。&lt;/p&gt;
+
+&lt;p&gt;但是再进一步如果你的第三方软件和不同的依赖比较多，那么这个环境的准备是非常困难的，因为这个组合将很大。&lt;/p&gt;
+
+&lt;p&gt;当然你可有使用虚拟机的技术vagrant/virtualbox，参见&lt;a href=&quot;http://larrycai.github.com/2011/10/25/vagrant-jenkins-ci.html&quot;&gt;使用vagrant+jenkins来管理虚拟机的技巧&lt;/a&gt;。可以工作，不太优雅。因为它不是原生的，有点复杂。&lt;/p&gt;
+
+&lt;h3&gt;配置管理人员的工作&lt;/h3&gt;
+
+&lt;p&gt;一般来说Jenkins的构建任务，它是集中控制的。大多来说都是有专职的配置管理人员来管理，否者权限会混乱。&lt;/p&gt;
+
+&lt;p&gt;当有需求时，他们负责在CI服务器创建任务（记住：这些配置文件不是有版本控制的）。这个就涉及到了沟通成本，你有变化需求，很难及时满足。&lt;/p&gt;
+
+&lt;p&gt;由于服务器是有限的，它主要构建重要分支的内容。在你自己的私有分支上运行CI是比较奢侈的，而且环境不一样，也不推荐。&lt;/p&gt;
+
+&lt;p&gt;你可以想象如果在一个C/C++产品的公司，你要为一个Lisp的项目创建CI要花多久？&lt;/p&gt;
+
+&lt;p&gt;作为开发者，为什么不能随时构建你想要的东西呢？这就是Travis CI想做的。&lt;/p&gt;
+
+&lt;h2&gt;Travis CI 介绍&lt;/h2&gt;
+
+&lt;p&gt;Travis CI 这里就不介绍怎么使用了具体可以先看&lt;a href=&quot;http://www.juvenxu.com/2012/03/06/travis-ci/&quot;&gt;晓斌的博客&lt;/a&gt;和&lt;a href=&quot;http://saberma.me/other/2011/11/29/travis-ci-is-a-free-continuous-integration-test-server.html&quot;&gt;免费的持续集成测试服务&lt;/a&gt;，强烈建议你先试一下。&lt;/p&gt;
+
+&lt;p&gt;初看Travis CI象和Jenkins没啥区别，指定你Github中的项目，然后他帮你编译，而且它使用的也是Vagrant/Virtualbox技术。但实际上里面有很多好点子。&lt;/p&gt;
+
+&lt;h2&gt;Travis CI带来的变革&lt;/h2&gt;
+
+&lt;h3&gt;配置本地化和可读性&lt;/h3&gt;
+
+&lt;p&gt;不像以前，构建的任务是在Jenkins服务器上的，现在构建的配置文件直接就和源码放在一起，而且配置文件使用DSL写的，可读性更高。&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;before_script:
+  - sudo apt-get install pandoc
+  - sudo apt-get install ttf-arphic-gbsn00lp ttf-arphic-ukai ttf-wqy-microhei ttf-wqy-zenhei
+  - sudo apt-get install texlive-xetex texlive-latex-recommended texlive-latex-extra
+  - gem install mkbok
+
+rvm:
+  - 1.9.3
+  - 1.8.7
+script: mkbok --lang zh --build pdf
+
+after_script: 
+    - which curl ; curl -v --upload-file sdcamp.zh.pdf http://blobs.ge.tt/3iBcNNC/sdcamp.zh.pdf?sig=-TY5O1GAx8xHwWiCqd8aySlQiroFAnHK2o4
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;p&gt;作为用户，关心的是要哪些依赖包，然后怎么构建就行了，上面的配置每一行都没有浪费。&lt;/p&gt;
+
+&lt;h3&gt;多版本支持&lt;/h3&gt;
+
+&lt;p&gt;像上面的例子中，我要求在两个Ruby环境中运行，它就帮我做到了，我并不关心它是怎么切换的。&lt;/p&gt;
+
+&lt;p&gt;&lt;img src=&quot;http://larrycai.github.com/images/build-matrix.png&quot; alt=&quot;多版本构建结果&quot; /&gt;&lt;/p&gt;
+
+&lt;h3&gt;原生的云技术来分布式构建&lt;/h3&gt;
+
+&lt;p&gt;Travis CI使用的Ruby语言，一开始考虑的就是分布式构建，比Jenkins的插件式进了一步。&lt;/p&gt;
+
+&lt;p&gt;虽然Travis CI并不是直接用到了云机器，它的虚拟机部分只是Vagrant/Virtualbox，但是这一块是很容易迁移到其他的技术的。&lt;/p&gt;
+
+&lt;h1&gt;总结&lt;/h1&gt;
+
+&lt;p&gt;Jenkins有点可惜，改了名字以后，功能上面并没有突破。当然这就是开源竞争的好处，总有新的理念，新的工具产生。你不前进，别人就迎头赶上。&lt;/p&gt;
+
+&lt;p&gt;Travis CI现在只是支持Github的公开项目，但已经爆发出它的优点了。要不了多久，我相信就能运行在你公司内部了。&lt;/p&gt;
+
+&lt;p&gt;让我们一起期待这个革新吧！&lt;/p&gt;
+
+&lt;h1&gt;相关阅读&lt;/h1&gt;
+
+&lt;ol&gt;
+&lt;li&gt;Juven Xu的“Travis CI，翩翩而至的CI云” &lt;a href=&quot;http://www.juvenxu.com/2012/03/06/travis-ci/&quot;&gt;http://www.juvenxu.com/2012/03/06/travis-ci/&lt;/a&gt;&lt;/li&gt;
+&lt;li&gt;免费的持续集成测试服务 &lt;a href=&quot;http://saberma.me/other/2011/11/29/travis-ci-is-a-free-continuous-integration-test-server.html&quot;&gt;http://saberma.me/other/2011/11/29/travis-ci-is-a-free-continuous-integration-test-server.html&lt;/a&gt;&lt;/li&gt;
+&lt;/ol&gt;
+
+</content>
+ </entry>
+ 
+ <entry>
+   <title>开源书和开源技术-PDF中蛋疼的中文字体</title>
+   <link href="http://larrycai.github.com/2012/01/13/ebook-chinese-fonts.html"/>
+   <updated>2012-01-13T00:00:00+08:00</updated>
+   <id>http://larrycai.github.com/2012/01/13/ebook-chinese-fonts</id>
+   <content type="html">Liquid error: invalid byte sequence in UTF-8</content>
+ </entry>
+ 
+ <entry>
+   <title>开源书和开源技术-Markdown篇</title>
+   <link href="http://larrycai.github.com/2011/12/31/ebook-by-markdown.html"/>
+   <updated>2011-12-31T00:00:00+08:00</updated>
+   <id>http://larrycai.github.com/2011/12/31/ebook-by-markdown</id>
+   <content type="html">&lt;h1&gt;开源书和开源技术-Markdown篇&lt;/h1&gt;
+
+&lt;h1&gt;背景&lt;/h1&gt;
+
+&lt;p&gt;看到&lt;a href=&quot;http://weibo.com/1404949082/xDeyDEaDq&quot;&gt;霍泰稳关于infoq的架构师电子书问题的微博&lt;/a&gt;和图灵社区的文章&lt;a href=&quot;http://www.ituring.com.cn/article/details/764&quot;&gt;为什么写作自由书籍？&lt;/a&gt;，我就想通过一个用Markdown格式写的&lt;a href=&quot;http://progit.org/&quot;&gt;Pro Git&lt;/a&gt;开源书 的例子来介绍其中用到的技术。希望能借此机会推动国内电子书，特别是开源电子书的发展。&lt;/p&gt;
+
+&lt;p&gt;【声明】我并没有写书的经历，这里只是对电子书出版技术的入门介绍而已。&lt;/p&gt;
+
+&lt;h1&gt;从Pro Git说起&lt;/h1&gt;
+
+&lt;p&gt;如果你了解Git，或者想了解Git。那么你就应该知道&lt;a href=&quot;http://progit.org/&quot;&gt;Pro Git&lt;/a&gt;，它是Git的书中写得最好的一本（至少是之一），可是你是否知道它有网络中文版，而且能在iPad上极其漂亮得阅读。并且是免费的，不是盗版的免费！如果你想要最新的，你甚至可以自己生成它。哈哈，我就是这么干的。&lt;/p&gt;
+
+&lt;p&gt;这一切就归功于开源社区和它后面用到的技术。&lt;/p&gt;
+
+&lt;h1&gt;开源书&lt;/h1&gt;
+
+&lt;p&gt;这里我不用多讲，开源书就像其他的开源产品（如维基百科）一样，只要是开放的，社区就有人会贡献。&lt;a href=&quot;http://progit.org/&quot;&gt;Pro Git&lt;/a&gt;的作者Scott很慷慨得把书的内容全部共享在&lt;a href=&quot;http://github.com/progit/progit&quot;&gt;github/progit&lt;/a&gt;库中，使用得是&lt;a href=&quot;http://creativecommons.org/licenses/by-nc-sa/3.0/us/&quot;&gt;CC BY-NC-SA 3.0&lt;/a&gt;。&lt;/p&gt;
+
+&lt;p&gt;Scott只负责英文版，其他许许多多语言的翻译都是社区贡献的，中国翻译相当有质量，你可以在线读&lt;a href=&quot;http://progit.org/book/zh/&quot;&gt;Pro Git中文版&lt;/a&gt;。&lt;/p&gt;
+
+&lt;h1&gt;开源技术生成电子书&lt;/h1&gt;
+
+&lt;p&gt;这本书不仅仅开源了内容，使用的技术也是开源的。让我们看看他是怎么做的。&lt;/p&gt;
+
+&lt;h2&gt;markdown原始文件&lt;/h2&gt;
+
+&lt;p&gt;首先书的内容是用markdown格式写的。markdown格式的普及要归功于&lt;a href=&quot;github.com&quot;&gt;Github&lt;/a&gt;和&lt;a href=&quot;http://stackoverflow.com/&quot;&gt;StackOverflow&lt;/a&gt;。因为它们越来越流行，它们支持markdown格式也越来越流行。这里要赞一个的是，国内的&lt;a href=&quot;http://www.ituring.com.cn/&quot;&gt;图灵社区&lt;/a&gt;也支持markdown，用起来超级方便。&lt;/p&gt;
+
+&lt;p&gt;简单来说，markdown格式的文件看着像一般的文本文件，里面只是加了很少的格式标记，因此看文本文件也不影响理解，这种格式也有很多工具帮你去转化，而且很容自动化解决。并且这些技术大多数是开源或免费的。&lt;/p&gt;
+
+&lt;p&gt;你可以直接看一下【Pro Git】的&lt;a href=&quot;https://raw.github.com/progit/progit/master/zh/01-introduction/01-chapter1.markdown&quot;&gt;“第一章 介绍” 的markdown原始文件&lt;/a&gt;，顺便看看github自动生成的简单&lt;a href=&quot;https://github.com/progit/progit/blob/master/zh/01-introduction/01-chapter1.markdown&quot;&gt;“第一章 介绍” 的html&lt;/a&gt;。&lt;/p&gt;
+
+&lt;h2&gt;产生电子书&lt;/h2&gt;
+
+&lt;h3&gt;epub/mobi格式&lt;/h3&gt;
+
+&lt;p&gt;Ruby的&lt;a href=&quot;https://github.com/rtomayko/rdiscount&quot;&gt;rdiscount&lt;/a&gt;帮你从markdown转成html格式，然后有&lt;a href=&quot;calibre&quot;&gt;Calibre&lt;/a&gt;附带的命令&lt;code&gt;ebook-convert&lt;/code&gt;生成最终的&lt;code&gt;.mobi&lt;/code&gt; (Kindle) 和 &lt;code&gt;.epub&lt;/code&gt; (iPad)。&lt;/p&gt;
+
+&lt;h3&gt;PDF格式&lt;/h3&gt;
+
+&lt;p&gt;为了能达到出版的质量，Latex是一个常用的格式，PDF也能很容易的产生出来，有关Latex，自己看看参考链接学习吧。&lt;/p&gt;
+
+&lt;p&gt;&lt;a href=&quot;http://johnmacfarlane.net/pandoc/&quot;&gt;pandoc&lt;/a&gt;能帮着从markdown转换出latex格式，然后&lt;a href=&quot;http://www.tug.org/texlive/&quot;&gt;TexLive&lt;/a&gt;软件中的&lt;code&gt;xelatex&lt;/code&gt;再转成PDF格式。&lt;/p&gt;
+
+&lt;h2&gt;试验环境&lt;/h2&gt;
+
+&lt;p&gt;你只需要一台Linux机器（虚拟机就可以了）和简单的Linux命令就可以试验了。有git和ruby的知识那就更方便了。&lt;/p&gt;
+
+&lt;p&gt;我用的试验环境是Ubuntu 11.04 (Natty)&lt;/p&gt;
+
+&lt;h3&gt;下载Pro Git开源书&lt;/h3&gt;
+
+&lt;p&gt;很简单，&lt;code&gt;git clone&lt;/code&gt;一下就可以了，下载它的源文件包我觉得还是烦了点。&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;$ git clone https://github.com/progit/progit.git
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;h3&gt;epub/mobi格式&lt;/h3&gt;
+
+&lt;p&gt;做电子书相对简单一点，因为要求没有PDF的高，&lt;a href=&quot;http://calibre-ebook.com/&quot;&gt;calibre&lt;/a&gt;就可以满足了。&lt;/p&gt;
+
+&lt;p&gt;如果装的Ubuntu是服务器版的（没有X-Windows），建议安装&lt;a href=&quot;http://en.wikipedia.org/wiki/Xvfb&quot;&gt;xvfb&lt;/a&gt;无头(headless)X服务器，因为不知道什么原因有几个命令需要。XMing还不行，因为需要&lt;code&gt;X-Input&lt;/code&gt;&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;$ sudo apt-get install ruby rubygems # ruby 1.8.7 is used
+$ sudo apt-get install calibre # calibre 0.7.44 for ubuntu 11.04
+$ gem install rdiscount ruby-debug 
+$ xvfb-run ./makeebooks zh  # 缺省.mobi格式
+$ export FORMAT=epub
+$ xvfb-run ./makeebooks zh # .epub格式
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;h3&gt;PDF格式&lt;/h3&gt;
+
+&lt;p&gt;生成PDF是一个比较复杂的东西，&lt;a href=&quot;http://johnmacfarlane.net/pandoc/&quot;&gt;pandoc&lt;/a&gt;用Ubuntu库里的，TexLive建议下载最新的&lt;a href=&quot;http://www.tug.org/texlive/&quot;&gt;TexLive&lt;/a&gt;包安装，并配置到搜索路径中。&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;$ sudo apt-get install pandoc 
+$ # 安装texlive 2011
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;p&gt;因为是中文PDF，需要把字体嵌入在文件中，因此需要安装字体文件（如果不是Ubuntu中文版）&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;$ sudo apt-get install language-support-fonts-zh-hans
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;p&gt;现在你就可以生成pdf文件了。&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;$ ./makepdfs zh 
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;h1&gt;其他常用的格式&lt;/h1&gt;
+
+&lt;p&gt;计算机类图书对格式要求不是很多，图文、章节、源代码基本就够了，就算有些复杂公式，也可用图来显示。这也从理论上说明，它不需要复杂的格式。现在对这类技术书出版我的理解主要有几种：&lt;/p&gt;
+
+&lt;ol&gt;
+&lt;li&gt;Microsoft的Word格式，虽然国内出版界如日中天，缺省就认它（对技术没追求，鄙视）。简单好学，但是不擅长自动化，是开源的死敌。&lt;/li&gt;
+&lt;li&gt;Latex格式（就是Donald E. Knuth（高德纳）发明的，这是很棒的东西，特别适合学术类的各种复杂的公式等，不过学习曲线很高，国内也只有几家学术期刊使用。&lt;/li&gt;
+&lt;li&gt;docbook格式是最有名的（从SGML演化过来？），Orielly和Pragmatic出版社缺省就用它，它能    很方便的转化出出版要的各种样式。如&lt;a href=&quot;http://www.wakaleo.com/books/jenkins-the-definitive-guide&quot;&gt;Jenkins - the definition guide&lt;/a&gt;开源书就是采用docbook。但由于是XML格式，很多人不习惯，而且多人网上协作不是很方便。&lt;/li&gt;
+&lt;li&gt;通过蒋鑫的&lt;a href=&quot;http://www.worldhello.net/gotgithub/&quot;&gt;Got Github&lt;/a&gt;开源书，我也了解reStructureText也是和markdown差不多纯文本（plain text)的，也是蛮流行的。&lt;/li&gt;
+&lt;/ol&gt;
+
+
+&lt;p&gt;如果有机会，我再介绍一下docbook和reStructureText的相关技术。&lt;/p&gt;
+
+&lt;h1&gt;其他&lt;/h1&gt;
+
+&lt;p&gt;本文也是我用git记录在&lt;a href=&quot;https://github.com/larrycai/larrycai.github.com&quot;&gt;github&lt;/a&gt;上的，你可以看到每次的变化。&lt;/p&gt;
+
+&lt;p&gt;如果对此文有兴趣，帮忙顶一下，别忘了 &lt;a href=&quot;http://weibo.com/larrycaiyu&quot;&gt;@larrycaiyu&lt;/a&gt;。&lt;/p&gt;
+
+&lt;h1&gt;Latex的参考&lt;/h1&gt;
+
+&lt;ol&gt;
+&lt;li&gt;http://share.chinatex.org/&lt;/li&gt;
+&lt;li&gt;http://manual.calibre-ebook.com/conversion.html&lt;/li&gt;
+&lt;li&gt;http://calibre-ebook.com/download_linux&lt;/li&gt;
+&lt;li&gt;http://johnmacfarlane.net/pandoc/&lt;/li&gt;
+&lt;li&gt;http://latex.yo2.cn/articles/latex-introduction0.html&lt;/li&gt;
+&lt;li&gt;http://product.china-pub.com/54569&lt;/li&gt;
+&lt;/ol&gt;
+
+</content>
+ </entry>
+ 
+ <entry>
+   <title>企业C++大型系统遗留代码变迁的布道之旅</title>
+   <link href="http://larrycai.github.com/2011/12/16/visualize-quality-4-cxx-legacycode.html"/>
+   <updated>2011-12-16T00:00:00+08:00</updated>
+   <id>http://larrycai.github.com/2011/12/16/visualize-quality-4-cxx-legacycode</id>
+   <content type="html">&lt;h1&gt;企业C++大型系统遗留代码变迁的布道之旅&lt;/h1&gt;
+
+&lt;h1&gt;前沿&lt;/h1&gt;
+
+&lt;p&gt;特别声明：本文专为&lt;a href=&quot;http://www.ituring.com.cn/activity/details/696&quot;&gt;图灵社区活动“唤醒你心中的布道师”&lt;/a&gt;而写，欢迎大家积极参与！&lt;/p&gt;
+
+&lt;p&gt;&lt;a href=&quot;http://www.programmer.com.cn/9072/&quot;&gt;程序员杂志第十二期&lt;/a&gt;中讲到了企业开发的困境，其中有一点就是企业有很多的遗留代码，而且是C/C++的大型系统。怎么处理一直是推动软件开发中的头疼问题，为什么头疼呢？&lt;/p&gt;
+
+&lt;ol&gt;
+&lt;li&gt;旧代码，又大，怎么下手，时间在哪里？&lt;/li&gt;
+&lt;li&gt;C/C++代码，和java比起来没有统一的单元测试工具，又难改造，怎么办？&lt;/li&gt;
+&lt;/ol&gt;
+
+
+&lt;p&gt;现在我们已经基本完成了这个转变，主要代码覆盖率在60%以上，很好得支持了敏捷开发（如持续集成）。&lt;/p&gt;
+
+&lt;p&gt;在看了&lt;a href=&quot;http://www.ituring.com.cn/book/736&quot;&gt;布道之道&lt;/a&gt;一书后，把我们用的一些技巧和策略用实际例子和大家一起来探讨一下。&lt;/p&gt;
+
+&lt;h1&gt;背景介绍&lt;/h1&gt;
+
+&lt;p&gt;变革开始于2007年左右，那时，这是一个有几十万行代码的C++产品，始于上个世纪末，基于Corba，XML，组件（component）的技术，由于架构的关系，没有单元测试，只有集成测试。&lt;/p&gt;
+
+&lt;p&gt;功能持续增加，开发者交付压力大。质量开始有下降、维护成本有提高的苗头。&lt;/p&gt;
+
+&lt;p&gt;我们就想通过提高C++的代码测试覆盖率来解决这些问题；这就需要把单元测试从无到有，再到一个高度。&lt;/p&gt;
+
+&lt;p&gt;基础这么差，不得不需要布道！&lt;/p&gt;
+
+&lt;h1&gt;什么样的怀疑者&lt;/h1&gt;
+
+&lt;p&gt;在推动这个变革前，先看看有什么样的怀疑者会阻碍你。&lt;/p&gt;
+
+&lt;p&gt;在大公司里最多的还是孤陋寡闻型，时间紧迫型。&lt;/p&gt;
+
+&lt;p&gt;&lt;strong&gt;孤陋寡闻型&lt;/strong&gt;：主要是开发者，我又想叫他们埋头苦干型。因为他们干活踏踏实实，只是由于项目压力的关系，没有额外的时间去看看外面的新技术，习惯了按步就班。&lt;/p&gt;
+
+&lt;p&gt;他们早已经习惯了用集成测试来替代单元测试。猛然间听说要上单元测试，一下子就觉得不行。Java么还可以考虑考虑，C++的产品需要搞单元测试吗？而且这种复杂的架构，能搞成功吗？就算能成，代价也太大了，那么多旧的代码，不可能！&lt;/p&gt;
+
+&lt;p&gt;&lt;strong&gt;时间紧迫型&lt;/strong&gt;：主要就是项目管理者，他们最大的愿望是项目准时完成，质量达到要求，项目完成后，他们基本就会转战到另一个战场。&lt;/p&gt;
+
+&lt;p&gt;所以一听说想在项目里面加点东西，还不知道干嘛呢，就问多少时间？问为什么在这个项目做（潜台词就是别在我这儿捣乱）。等到一听说要做以前都不做的单元测试，头摇得就像拨浪鼓一样，死活都不肯。&lt;/p&gt;
+
+&lt;h1&gt;对症下药：采用合适的技术&lt;/h1&gt;
+
+&lt;p&gt;对上面两种人和我们要解决的问题，我们采用了好多种方法，下面介绍主要的两种：展示技术和适当妥协&lt;/p&gt;
+
+&lt;p&gt;&lt;strong&gt;展示技术&lt;/strong&gt;：你要告诉他们，你要推动的变革是可以做到的，这样来消除他们的疑惑。&lt;/p&gt;
+
+&lt;p&gt;这是对付孤陋寡闻型的最好办法，告诉他们这个能做到，也没有想象中的难。&lt;/p&gt;
+
+&lt;p&gt;我记得我花了两周的时间找了一个最典型的组件，采用了CppUnit这个单元测试框架，并应用了虚函数（java中的接口）的方式把对平台架构的依赖全部隔离掉，顺利地跑通了几个测试。并且我还准备了ppt，召集大家一起来探讨确认这是一个可以工作的方式。&lt;/p&gt;
+
+&lt;p&gt;就象书上说的，孤陋寡闻型的人看到了, 了解了以后，就很容易得接受你的建议了。&lt;/p&gt;
+
+&lt;p&gt;&lt;strong&gt;适当妥协&lt;/strong&gt;：就是要找到折中方案，让大家都能过的去。&lt;/p&gt;
+
+&lt;p&gt;这是对付时间紧迫型的一个好办法，要求不能太高，把一下子想做的东西放在一个地方。&lt;/p&gt;
+
+&lt;p&gt;我们决定用循序渐进的方式，提出一个中肯的方案：&lt;/p&gt;
+
+&lt;ol&gt;
+&lt;li&gt;新代码必须要用单元测试，这个没话可说，因为从项目质量上这个是可以要求的。当然怎么做单元测试，由于是新的，会有人提供培训和帮助。&lt;/li&gt;
+&lt;li&gt;旧代码在改变时必须要用单元测试，因为改了代码，有测试保证这也是应该的。&lt;/li&gt;
+&lt;li&gt;在改动的组件中，每次要对旧代码增加一些测试。&lt;/li&gt;
+&lt;/ol&gt;
+
+
+&lt;p&gt;这样一来，每个项目中都会对单元测试有所贡献，长而久之，会积累到比较客观的数量，虽然慢了点，但还是往前进步的。&lt;/p&gt;
+
+&lt;p&gt;时间紧迫型当然不是吃素的，老觉得亏了点，就盯着第三点说：“项目没时间做这个额外的事情”，这个要靠策略了。&lt;/p&gt;
+
+&lt;h1&gt;辅以策略：贯彻实施&lt;/h1&gt;
+
+&lt;p&gt;两个最基本的策略：竭力支持者，说服管理层。&lt;/p&gt;
+
+&lt;p&gt;&lt;strong&gt;竭力支持者&lt;/strong&gt; 是最该采纳的，他们会鼓动周边的人和你一起服务，要善于团结他们，这要就扭成了一股绳。&lt;/p&gt;
+
+&lt;p&gt;对大多数有经验的开发者，大家都明白单元测试是保证质量的最好办法，技术上说服以后，他们很快就变成了&lt;strong&gt;竭力支持者&lt;/strong&gt;，觉得不加单元测试就是一种罪过，项目中有谁忘了，&lt;strong&gt;竭力支持者&lt;/strong&gt;也会及时提醒他们，不需要你们一直跟踪，减轻了很多压力。&lt;/p&gt;
+
+&lt;p&gt;&lt;strong&gt;说服管理层&lt;/strong&gt; 是一个最棒的方式，当然前提是你要能说服他们。&lt;/p&gt;
+
+&lt;p&gt;实际上管理层也知道没有单元测试这一弊端，只是苦于没有行之有效的方案而已。所以当你告诉他们技术上没有问题了，代价也不是很大，并且你又提供了切实可行的计划。管理层立马会通知大家把这个落实到各个项目中去（包括上面的第三条）。&lt;/p&gt;
+
+&lt;p&gt;拿到了这个尚方宝剑，没有谁会阻碍了，我们就可以把主要精力花在技术支持上，当然千万不能搞砸了。&lt;/p&gt;
+
+&lt;h1&gt;收获果实&lt;/h1&gt;
+
+&lt;p&gt;果然，经过了几年，到2010年单元测试已经达到了60%左右（对C++来说不错了），现在开发人员也习以为常了。&lt;/p&gt;
+
+&lt;h1&gt;结束语&lt;/h1&gt;
+
+&lt;p&gt;&lt;a href=&quot;http://www.ituring.com.cn/book/736&quot;&gt;布道之道&lt;/a&gt; 真是一本好书（翻译要记一功），它的好多种模式一看就明白。如果你是个有经验的人，你会发现你的很多技巧都在书上提到了，它会帮你进一步的提炼升华，使你下次做的更好。&lt;/p&gt;
+
+&lt;p&gt;布道会使你有一种成就感，让我们一起来把这个软件行业变得越来越好吧。&lt;/p&gt;
+
+&lt;h1&gt;其他&lt;/h1&gt;
+
+&lt;p&gt;本文也是我用git记录在&lt;a href=&quot;https://github.com/larrycai/larrycai.github.com&quot;&gt;github&lt;/a&gt;上的，你可以看到每次的变化。&lt;/p&gt;
+
+&lt;p&gt;如果对此文有兴趣，帮忙顶一下，别忘了 &lt;a href=&quot;http://weibo.com/larrycaiyu&quot;&gt;@larrycaiyu&lt;/a&gt; ，希望有机会有人能帮我推荐到QConf 2012中去分享，到时我们可以探讨得更多。&lt;/p&gt;
+
+&lt;p&gt;这儿再留一个关子，如何建立一个好的C++代码质量检测框架，并且最终和其他java代码质量清晰得显示在一起又是另外一个布道故事了，而且有一些就是因为没有看这本书而得到的一个反面教材。&lt;/p&gt;
+</content>
+ </entry>
+ 
+ <entry>
+   <title>企业版本控制的改革：从ClearCase到Git--我的布道之旅</title>
+   <link href="http://larrycai.github.com/2011/12/10/clearcase-2-git.html"/>
+   <updated>2011-12-10T00:00:00+08:00</updated>
+   <id>http://larrycai.github.com/2011/12/10/clearcase-2-git</id>
+   <content type="html">&lt;h1&gt;企业版本控制的改革：从ClearCase到Git--我的布道之旅&lt;/h1&gt;
+
+&lt;h1&gt;前沿&lt;/h1&gt;
+
+&lt;p&gt;特别声明：本文专为图灵社区活动“唤醒你心中的布道师”而写，欢迎大家积极参与！&lt;/p&gt;
+
+&lt;p&gt;特别感想：本文的风格照搬高翌翔的“布道体” &lt;a href=&quot;http://www.ituring.com.cn/article/712&quot;&gt;从自定义ORM框架到NHibernate——我的识道、行道、布道之旅&lt;/a&gt;&lt;/p&gt;
+
+&lt;p&gt;&lt;a href=&quot;http://www.programmer.com.cn/9072/&quot;&gt;程序员杂志第十二期&lt;/a&gt;中讲到了企业开发的困境，其中有一点就是企业的流程和工具很难适应新的敏捷开发模式。我认为其中之一就是版本控制系统，本文就是探讨一下我是如何来推动这个改变的，也就是我的布道之旅。&lt;/p&gt;
+
+&lt;p&gt;【免责声明】这里不是探讨两种技术的好坏，而是如何推动变革，每个技术都有适应的场所，请勿生搬硬套。关于版本控制的选择，可以看看Martin Fowler写的&lt;a href=&quot;http://martinfowler.com/bliki/VersionControlTools.html&quot;&gt;版本控制工具(english)&lt;/a&gt;&lt;/p&gt;
+
+&lt;h1&gt;介绍&lt;/h1&gt;
+
+&lt;p&gt;在传统企业中，版本控制系统大都采用ClearCase，因为在早期它应该提供了强大的企业应用的功能，我们企业也很早使用了。而且长久以来，在它周围建立了无数的应用和流程，同事们都觉得它是必须的了。&lt;/p&gt;
+
+&lt;p&gt;然而随着敏捷和开放的推动下，在有些产品用Clearcase开发碰到了很多局限，比如在家上班，远程团队开发。有人开始想到引入其他工具（svn，git）来解决，不过在大型企业中要改变这种基础的工具是很难的。&lt;/p&gt;
+
+&lt;p&gt;我做为一个软件开发的探索者，努力的想改变点什么，但不知从何而起。&lt;/p&gt;
+
+&lt;h1&gt;了解分布式版本控制（DVCS）——初识道&lt;/h1&gt;
+
+&lt;p&gt;开始考虑这个的时候是在2009年初，svn是第一个考虑的对象，因为它在开源中用的最多，&lt;a href=&quot;http://sourceforge.net&quot;&gt;sourceforge&lt;/a&gt;和eclipse的很多项目多用它，但我总觉得缺了点什么。&lt;/p&gt;
+
+&lt;p&gt;恰好我有个&lt;a href=&quot;http://weibo.com/ch3n2k&quot;&gt;Geek朋友：陈忠克&lt;/a&gt;极力推荐一个分布式版本控制工具：mercurial，说实话听了介绍不是很懂，没有眼前一亮的感觉。聊了一下，感觉和svn的分支没有多大区别，还两层提交呢。&lt;/p&gt;
+
+&lt;p&gt;同时他也告诉我还有其他的分布式版本控制工具git，bazaar可供选择。&lt;/p&gt;
+
+&lt;p&gt;不管怎么样，我了解了这块领域有了最新的技术，或许能解决我们的问题。&lt;/p&gt;
+
+&lt;h1&gt;尝试在日常中使用分布式版本控制——初行道&lt;/h1&gt;
+
+&lt;p&gt;为了尽快了解DVCS，我决定要在日常的开发中用用它，实践它，尽快的掌握它的关键。&lt;/p&gt;
+
+&lt;p&gt;由于Geek对mercurial很熟，我就踏踏实实的用mercurial用了两个星期，不懂就问他，顺便查查资料去比较一番。&lt;/p&gt;
+
+&lt;p&gt;wooh,wooh，DVCS真是很神奇，很好用，特别对我（作为码农）的胃口，感觉DVCS天生是为软件开发用的。&lt;/p&gt;
+
+&lt;p&gt;在同一时刻，我又比较深入的看了看其他的系统如git，发现git的生态圈更好一点。在软件开发中，生态圈会决定将来这个工具的发展趋势。&lt;/p&gt;
+
+&lt;ul&gt;
+&lt;li&gt;如eclipse插件开发邮件中开始讨论并决定用git替代svn。&lt;/li&gt;
+&lt;li&gt;git有很多的书可供选择（如 &lt;a href=&quot;http://progit.org/&quot;&gt;ProGit&lt;/a&gt;），&lt;a href=&quot;http://git-scm.com/&quot;&gt;git在线网站&lt;/a&gt;的内容也极其丰富。&lt;/li&gt;
+&lt;li&gt;&lt;a href=&quot;https://github.com/&quot;&gt;github&lt;/a&gt;也漂亮得提供git的支持。补充一下，那时候&lt;a href=&quot;http://bitbucket.org/&quot;&gt;bitbucket&lt;/a&gt;和github还在同一个水平线上。&lt;a href=&quot;http://code.google.com/&quot;&gt;google code&lt;/a&gt;也还不支持git，只有mercurial和svn。&lt;/li&gt;
+&lt;/ul&gt;
+
+
+&lt;p&gt;通过这些实践和了解，发现DVCS：git很适合我们所在的企业产品软件开发。&lt;/p&gt;
+
+&lt;h1&gt;宣扬和推广分布式版本控制——初布道&lt;/h1&gt;
+
+&lt;p&gt;要在企业中换一个版本控制工具难度非常大，所以必须要造势，也就是此处的布道，我采用了下面的方法：&lt;/p&gt;
+
+&lt;ol&gt;
+&lt;li&gt;每月我们都有固定学习新东西的时间，我就推荐了mercurial、git两个课程，让大家共同来学习，了解它。顺便我要看看开发者对它的接受程度，有趣的是，水平越牛的人越是喜欢它，纷纷过来问什么时候能在产品开发中用上git。&lt;/li&gt;
+&lt;li&gt;除了开发者，管理者和其他的使用者（配置管理的同事）的想法也很重要。我经常抓住机会和这些人聊DVCS ，聊git，给他们介绍，看看他们有什么想法。当然他们会不同意我的观点（有强势的，有委婉的），我就试图去说服他们，挖掘出推动这个变化的关键因素。&lt;/li&gt;
+&lt;/ol&gt;
+
+
+&lt;p&gt;慢慢的我就开始得到了很多如何推动这个变化的材料，以及说服他们的模板（哈哈对症下药）。&lt;/p&gt;
+
+&lt;h1&gt;详细研究版本迁移——再识道&lt;/h1&gt;
+
+&lt;p&gt;开发者想使用分布式版本控制的呼声越来越高，管理者也开始认真考虑了。&lt;/p&gt;
+
+&lt;p&gt;在企业中，改变所需要的研究评测报告（word，ppt)是必不可少的了，这也给了我一次重新认识集中式和分布式版本控制的过程，我花了更多的时间去想这个改变对企业带来的好处。实际上开发者有时候不会考虑到整个软件开发的所有方面，如安全，持续集成等等。报告的大致框架是：&lt;/p&gt;
+
+&lt;ul&gt;
+&lt;li&gt;现在问题是什么？&lt;/li&gt;
+&lt;li&gt;什么是DVCS，git是什么？&lt;/li&gt;
+&lt;li&gt;能改变什么？带来的好处？&lt;/li&gt;
+&lt;li&gt;如果变化，计划是什么？&lt;/li&gt;
+&lt;/ul&gt;
+
+
+&lt;p&gt;研究报告就不细讲了，太技术了，而且有点商业机密，哈哈。&lt;/p&gt;
+
+&lt;p&gt;这一期间，使我更详细的了解了git和对企业可能的影响（有好的，有坏的），并制定了相应的对策。&lt;/p&gt;
+
+&lt;h1&gt;开始在小范围实施——再行道&lt;/h1&gt;
+
+&lt;p&gt;布道需要耐心和机遇，机缘巧合，迁移到git的建议比较顺利的被管理层接受了。（我的报告难得那么顺利通过的）。&lt;/p&gt;
+
+&lt;p&gt;然后就是要去认认真真的实施了，这不是一个小问题，既然是软件开发，来不得半点的马虎，细节决定一切。而且实施的好坏还涉及到自己的面子问题，讲笑了。&lt;/p&gt;
+
+&lt;p&gt;企业中一般从小范围开始实施，成功了才推广，下面是我们的一些实践。&lt;/p&gt;
+
+&lt;ul&gt;
+&lt;li&gt;我们用&lt;a href=&quot;https://github.com/sitaramc/gitolite&quot;&gt;gitolite&lt;/a&gt;作为git服务器，架好试验平台，在一个小项目中开始尝试。&lt;/li&gt;
+&lt;li&gt;人手一本git的书，安排git入门培训，提高驾驭git的能力。&lt;/li&gt;
+&lt;li&gt;不断收集资料，提高对git的认识。&lt;/li&gt;
+&lt;/ul&gt;
+
+
+&lt;p&gt;还好基本上没有出大的差错，虽然有蛮多技术难点的，不过最后都解决了。通过小范围的使用推广，我们的技术储备也加强了（特别是配置管理的人），对下一步的全面实施更有信心。&lt;/p&gt;
+
+&lt;h1&gt;推广，并引入gerrit做代码审查——再布道&lt;/h1&gt;
+
+&lt;p&gt;早期我们用的是gitolite来架git服务器，它很不错。不过后来发现&lt;a href=&quot;http://code.google.com/p/gerrit/&quot;&gt;gerrit&lt;/a&gt;更好用，后来就切换过去使用了。这一点很重要，要不断探索这些新技术，争取在大规模推广前，用一个最适合的工具，否者一用上，在企业中就很难改变了。&lt;/p&gt;
+
+&lt;p&gt;git开始在更多团队和更多产品中使用后，我们不断加强知识的培训，而且把相关的系统（如持续集成）都迁移到git上去。一切都还不错，只是git比想象中还复杂一点。&lt;/p&gt;
+
+&lt;p&gt;因为gerrit有很强大的代码审查（code review）功能，不久以后这个功能也用上去了，代码提交的质量一下子上了一个档次，这是开始推动git变革时没有想到的。&lt;/p&gt;
+
+&lt;h1&gt;结束语&lt;/h1&gt;
+
+&lt;p&gt;（此处引用高翌翔写的“布道体”结束语）&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;子曰：己所不欲，勿施于人。因此，布道者在布道前，须识道、行道，而布道时应谨记“己之所欲，慎施于人”，身教重于言教，务必身体力行、以身示道！
+
+我的识道、行道、布道之旅没有终点，希望能结识更多的同路人 ;-)
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;h1&gt;其他&lt;/h1&gt;
+
+&lt;p&gt;本文也是我用git记录在&lt;a href=&quot;https://github.com/larrycai/larrycai.github.com&quot;&gt;github&lt;/a&gt;上的，你可以看到每次的变化。&lt;/p&gt;
+
+&lt;p&gt;如果对此文有兴趣，帮忙顶一下，别忘了 &lt;a href=&quot;http://weibo.com/larrycaiyu&quot;&gt;@larrycaiyu&lt;/a&gt; ，希望有机会有人能帮我推荐到QConf 2012中去分享，到时我们可以探讨的更多。&lt;/p&gt;
+
+&lt;p&gt;顺便推荐&lt;a href=&quot;http://weibo.com/gotgit&quot;&gt;蒋鑫&lt;/a&gt;的&lt;a href=&quot;http://book.douban.com/subject/6526452/&quot;&gt;《Git权威指南》&lt;/a&gt;，国内少有的好书。&lt;/p&gt;
+</content>
+ </entry>
+ 
+ <entry>
+   <title>用veewee创建vagrant的虚拟机</title>
+   <link href="http://larrycai.github.com/2011/11/04/veewee-create-vm.html"/>
+   <updated>2011-11-04T00:00:00+08:00</updated>
+   <id>http://larrycai.github.com/2011/11/04/veewee-create-vm</id>
+   <content type="html">&lt;h1&gt;用veewee创建vagrant的虚拟机&lt;/h1&gt;
+
+&lt;h1&gt;简介&lt;/h1&gt;
+
+&lt;p&gt;虚拟机有很多好处，不仅仅节省硬件资源，而且还可以快速切换系统环境，显然会在软件开发中起到极大作用。&lt;/p&gt;
+
+&lt;p&gt;在&lt;a href=&quot;http://www.continuousdelivery.info/index.php/2011/10/27/vagrant_jenkins_vm/&quot;&gt;上一篇vagrant和jenkins的文章&lt;/a&gt;中我提到了vagrant这个工具，有点麻烦的是你必须有先要有一个盒子（vagrant box)，盒子是vagrant对virtualbox的虚拟机的进一步封装，自己的虚拟机转变成vagrant的盒子有点麻烦，可以参见&lt;a href=&quot;http://vagrantup.com/&quot;&gt;vagrant的说明&lt;/a&gt;，因此一般都是找一个现成的来用。&lt;/p&gt;
+
+&lt;p&gt;但又没有更好的办法呢，现在网络的开放精神真是强大，你想到的一般就存在了，它就是我要介绍的&lt;a href=&quot;http://github.com/jedi4ever/veewee&quot;&gt;veewee&lt;/a&gt;，它的功能就是从你的ISO光盘从无到有装出需要的vagrant虚拟机（盒子）。&lt;/p&gt;
+
+&lt;h1&gt;veewee使用入门&lt;/h1&gt;
+
+&lt;p&gt;这一块有篇英文文章&lt;a href=&quot;http://www.ducea.com/2011/08/15/building-vagrant-boxes-with-veewee/&quot;&gt;Building Vagrant boxes with veewee&lt;/a&gt;讲的不错，github上的官方网站&lt;a href=&quot;http://github.com/jedi4ever/veewee&quot;&gt;veewee&lt;/a&gt;也是蛮详尽的，我在这儿快速的重复一下，再加上一些自己的小技巧。&lt;/p&gt;
+
+&lt;h2&gt;安装&lt;/h2&gt;
+
+&lt;p&gt;首先你当然要安装好vagrant，virtualbox，veewee实际上是vagrant的一个插件，因此也肯定是ruby写的，安装也很方便（象我这种ruby菜鸟也能完成）。&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;rdccaiy@ubuntu:~ $ sudo gem install veewee
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;h2&gt;使用&lt;/h2&gt;
+
+&lt;p&gt;如果安装顺利，那么你就可以打个命令试试到底有何奥妙了。&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;rdccaiy@ubuntu:~ $ vagrant basebox templates
+The following templates are available:
+vagrant basebox define '&amp;lt;boxname&amp;gt;' 'Fedora-14-amd64-netboot'
+vagrant basebox define '&amp;lt;boxname&amp;gt;' 'ubuntu-10.04.2-server-i386-netboot'
+vagrant basebox define '&amp;lt;boxname&amp;gt;' 'CentOS-6.0-x86_64-netboot'
+vagrant basebox define '&amp;lt;boxname&amp;gt;' 'CentOS-4.8-i386'
+vagrant basebox define '&amp;lt;boxname&amp;gt;' 'Debian-5.0.8-amd64-netboot'
+vagrant basebox define '&amp;lt;boxname&amp;gt;' 'CentOS-5.6-i386'
+vagrant basebox define '&amp;lt;boxname&amp;gt;' 'CentOS-5.6-i386-netboot'
+vagrant basebox define '&amp;lt;boxname&amp;gt;' 'freebsd-8.2-experimental'
+vagrant basebox define '&amp;lt;boxname&amp;gt;' 'Fedora-15-i386-netboot'
+vagrant basebox define '&amp;lt;boxname&amp;gt;' 'ubuntu-11.04-server-i386'
+vagrant basebox define '&amp;lt;boxname&amp;gt;' 'ubuntu-8.04.4-server-amd64'
+vagrant basebox define '&amp;lt;boxname&amp;gt;' 'archlinux-x86_64'
+..
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;p&gt;basebox就是veewee插件装好后变成的vagrant中的一个任务，从结果中可以看到已经有好多模板了，怎么用呢，先见一个目录如veewee，然后来创一个自己的机器。&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;rdccaiy@ubuntu:~$ mkdir veewee ; cd veewee
+rdccaiy@ubuntu:~/veewee$ vagrant basebox define 'ubuntu1104' 'ubuntu-11.04-server-i386'
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;p&gt;现在来看看新创了点什么东东。&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;rdccaiy@ubuntu:~/veewee$ find .
+./definitions/ubuntu1104
+./definitions/ubuntu1104/postinstall.sh
+./definitions/ubuntu1104/preseed.cfg
+./definitions/ubuntu1104/definition.rb
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;p&gt;&lt;code&gt;definition.rb&lt;/code&gt;中指定了iso文件&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;Veewee::Session.declare({
+  :cpu_count =&amp;gt; '1', :memory_size=&amp;gt; '384',
+  :disk_size =&amp;gt; '10140', :disk_format =&amp;gt; 'VDI', :hostiocache =&amp;gt; 'off',
+  :os_type_id =&amp;gt; 'Ubuntu',
+  :iso_file =&amp;gt; &quot;ubuntu-11.04-server-i386.iso&quot;,
+  :iso_src =&amp;gt; &quot;http://releases.ubuntu.com/11.04/ubuntu-11.04-server-i386.iso&quot;,
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;p&gt;iso文件就是操作系统的安装光盘，建议先从网上下载，veewee要求本地的话就必须放在和&lt;code&gt;definitions&lt;/code&gt;平级（也就是上面veewee的下面一级）的&lt;code&gt;iso&lt;/code&gt;目录下。&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;rdccaiy@ubuntu:~/veewee$ ls iso
+ubuntu-11.04-server-i386.iso
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;p&gt;闲话少说，让veewee工作起来吧&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;rdccaiy@ubuntu:~/veewee$ vagrant basebox build ubuntu1104
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;p&gt;理论上它应该能无图形化执行，不过我的还是需要打开X-Windows，你应该看到virtualbox虚拟机起来，然后自动按键运行，中间还会重启，我蛮顺利的做出了虚拟机，真是很棒，如下图。（不知怎么的，每次看到电脑帮我自动打字，我进很开心）&lt;/p&gt;
+
+&lt;p&gt;&lt;img src=&quot;/blog/images/veewee.png&quot; alt=&quot;veewee自动安装&quot; /&gt;&lt;/p&gt;
+
+&lt;p&gt;可以看到在终端上的漂亮log&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;rdccaiy@ubuntu:~/veewee$ vagrant basebox build ubuntu1104
+
+Verifying the isofile ubuntu-11.04-server-i386.iso is ok.
+We found no good state so we are destroying the previous machine+disks
+VBoxManage unregistervm  'ubuntu1104' --delete
+Deleting vm ubuntu1104
+Deleting disk /home/rdccaiy/VirtualBox VMs/ubuntu1104/ubuntu1104.vdi
+VBoxManage closemedium disk '/home/rdccaiy/VirtualBox VMs/ubuntu1104/ubuntu1104.vdi' --delete
+Creating vm ubuntu1104 : 384M - 1 CPU - Ubuntu
+Creating new harddrive of size 10140
+VBoxManage createhd --filename '/home/rdccaiy/VirtualBox VMs/ubuntu1104/ubuntu1104.vdi' --size '10140' --format vdi &amp;gt; /dev/null
+Attaching disk: /home/rdccaiy/VirtualBox VMs/ubuntu1104/ubuntu1104.vdi
+Mounting cdrom: /home/rdccaiy/veewee/iso/ubuntu-11.04-server-i386.iso
+Waiting for the machine to boot
+....
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;p&gt;时间应该蛮长的，一切的OK的话，你就可以产生出vagrant的虚拟机了。&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;rdccaiy@ubuntu:~/veewee$ vagrant basebox export 'ubuntu1104'
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;p&gt;然后就用vagrant的方法去尝试了，如&lt;code&gt;vagrant box add ‘ubuntu1104’ ubuntu1104.box&lt;/code&gt;。&lt;/p&gt;
+
+&lt;p&gt;如果你要的操作系统模板没找到，可以到&lt;a href=&quot;https://github.com/jedi4ever/veewee/tree/master/templates&quot;&gt;veewee的最新代码中的模板库看看&lt;/a&gt;&lt;/p&gt;
+
+&lt;h1&gt;veewee的原理&lt;/h1&gt;
+
+&lt;p&gt;如果你对操作系统安装（如linux）熟悉的话，应该能很快琢磨出道道来，veewee调用了&lt;a href=&quot;https://www.virtualbox.org/manual/ch08.html&quot;&gt;virtualbox的API-VBoxManage&lt;/a&gt;来控制虚拟机,如构建裸盘（&lt;code&gt;VBoxManage createhd&lt;/code&gt;）和加载光盘。&lt;/p&gt;
+
+&lt;p&gt;现在再来看看那三个文件是干嘛的。&lt;/p&gt;
+
+&lt;ul&gt;
+&lt;li&gt;&lt;code&gt;definition.rb&lt;/code&gt; 中是你的一些基本硬件配置，每个模板都差不多，中间一段定义了机器启动时如何加载，注意不同的操作系统会用不同的方法，redhat是kickstart，ubuntu是preseed&lt;/li&gt;
+&lt;li&gt;&lt;code&gt;preseed.cfg&lt;/code&gt;中就是ubuntu自动安装的配置参数，如果是SuSE，那就是&lt;code&gt;autoinst.xml&lt;/code&gt;了，它来完成你的初始光盘安装。&lt;/li&gt;
+&lt;li&gt;&lt;code&gt;postinstall.sh&lt;/code&gt; 顾名思义就是装完操作系统后的后续工作，这和你想要的配置有关，为了vagrant，要加上相应的包，当然别做复杂了，记住你只是做一个操作系统的初始虚拟机，具体里面的东西可以让vagrant用puppet或chef来完成。&lt;/li&gt;
+&lt;/ul&gt;
+
+
+&lt;h1&gt;总结&lt;/h1&gt;
+
+&lt;p&gt;这篇文章主要简单讲了一下用&lt;a href=&quot;http://github.com/jedi4ever/veewee&quot;&gt;veewee&lt;/a&gt;这个软件来如何快速创建vagrant虚拟机，有没有体会到持续交付中反复提到的配置管理了，所有的东西都写成配置文件，然后有软件自动生成你要的东西，慢慢试试在体会吧。&lt;/p&gt;
+
+&lt;p&gt;下次我该来谈谈&lt;a href=&quot;http://puppetlabs.com/&quot;&gt;puppet&lt;/a&gt;了，而且是无主机模式的，给些建议鼓励鼓励吧 &lt;a href=&quot;http://weibo.com/larrycai&quot;&gt;@larrycai&lt;/a&gt;，让我持续交付。&lt;/p&gt;
+
+&lt;h1&gt;参考&lt;/h1&gt;
+
+&lt;ol&gt;
+&lt;li&gt;larry的英文博客：http://codeslife.com/2011/10/25/create-virtualbox-on-fly-using-veewee/&lt;/li&gt;
+&lt;li&gt;veewee的官网：http://github.com/jedi4ever/veewee&lt;/li&gt;
+&lt;li&gt;老外介绍的如何用veewee建立vagrant盒子：&lt;a href=&quot;http://www.ducea.com/2011/08/15/building-vagrant-boxes-with-veewee/&quot;&gt;Building Vagrant boxes with veewee&lt;/a&gt;&lt;/li&gt;
+&lt;li&gt;VirtualBox API - VBoxManage: https://www.virtualbox.org/manual/ch08.html&lt;/li&gt;
+&lt;li&gt;持续交付：http://www.continuousdelivery.info/&lt;/li&gt;
+&lt;/ol&gt;
+
+</content>
+ </entry>
+ 
+ <entry>
+   <title>使用vagrant+jenkins来管理虚拟机的技巧</title>
+   <link href="http://larrycai.github.com/2011/10/25/vagrant-jenkins-ci.html"/>
+   <updated>2011-10-25T00:00:00+08:00</updated>
+   <id>http://larrycai.github.com/2011/10/25/vagrant-jenkins-ci</id>
+   <content type="html">&lt;h1&gt;使用vagrant+jenkins来管理虚拟机的技巧&lt;/h1&gt;
+
+&lt;h1&gt;简介&lt;/h1&gt;
+
+&lt;p&gt;虚拟机有很多好处，不仅仅节省硬件资源，而且还可以快速切换系统环境，显然会在软件开发中起到极大作用。&lt;/p&gt;
+
+&lt;p&gt;在《持续交付》第十一章（11.7.1）中就提到了虚拟机环境的管理。如下图
+&lt;img src=&quot;/blog/images/vmm.png&quot; alt=&quot;通过虚拟机创建虚拟环境&quot; /&gt;&lt;/p&gt;
+
+&lt;p&gt;它描述的是在你的持续集成的Jenkins CI服务器（以下简称jenkins）中，需要各种服务器来测试一个应用。我们可以快速的从虚拟机的VMM模板库中，启动需要的各种类型虚拟机，而不是每个都重新安装（省时），完成测试，产生报告后，也快速消失（省钱）。&lt;/p&gt;
+
+&lt;p&gt;让我们一起来看看一种漂亮的实现方案vagrant+jenkins实现技巧。&lt;/p&gt;
+
+&lt;h1&gt;基本知识&lt;/h1&gt;
+
+&lt;h2&gt;vagrant&lt;/h2&gt;
+
+&lt;p&gt;不同的虚拟机技术（virtualbox，vmware，xen/kvm等等)可能用不同的方法管理，&lt;a href=&quot;http://vagrantup.com/&quot;&gt;vagrant&lt;/a&gt;是virtualbox的前端，它简化了virtualbox虚拟机的操作，而且增加了对自动化（provisioning)的puppet/chef的支持，这里就不详细介绍。&lt;a href=&quot;http://vagrantup.com/&quot;&gt;vagrant&lt;/a&gt;的入门介绍已经很详细了，有一篇&lt;a href=&quot;http://blog.crowdint.com/2011/06/21/vagrant.html&quot;&gt;博客&lt;/a&gt;也可以借鉴一下。&lt;/p&gt;
+
+&lt;p&gt;你要知道的就是下面的几个命令&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;$ cd ubuntu1104-vm # 进入已有的 ubuntu 11.04 虚拟机目录
+$ vagrant up # 启动 ubuntu 虚拟机
+$ vagrant ssh -c &quot;pwd&quot;
+/home/vagrant
+$ vagrant halt # 停止虚拟机
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;h2&gt;jenkins CI&lt;/h2&gt;
+
+&lt;p&gt;jenkins 是一个最常用的持续集成服务器，可单独运行或者放在Web服务器中运行。&lt;/p&gt;
+
+&lt;p&gt;直接启动一个任务（jenkins job)去调用vagrant操作虚拟机不是一个很好的方式，因为启动jenkins的用户（如tomcat）的权限都比较小，以防止任务误操作。&lt;/p&gt;
+
+&lt;p&gt;幸好jenkins有个超级棒的主从模式（master/slave)来解决。&lt;/p&gt;
+
+&lt;h1&gt;方案搭建&lt;/h1&gt;
+
+&lt;h2&gt;建立vagrant用户&lt;/h2&gt;
+
+&lt;p&gt;最好先在一个机器上（可以和jenkins主机不在一起）创建一个vagrant用户，建立一套vagrant的用户环境。&lt;/p&gt;
+
+&lt;p&gt;因为无密码访问，所以要配好ssh环境，我们可以重用vagrant虚拟机的公私密钥，如下面的 IdentityFile就是私钥。&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;vagrant@host:~/vm/ubuntu1104$ vagrant ssh_config
+Host default
+  HostName 127.0.0.1
+  User vagrant
+  Port 2222
+  UserKnownHostsFile /dev/null
+  StrictHostKeyChecking no
+  PasswordAuthentication no
+  IdentityFile /var/lib/gems/1.8/gems/vagrant-0.8.7/keys/vagrant
+  IdentitiesOnly yes
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;p&gt;把公私密钥拷到vagrant用户的.ssh目录下。&lt;/p&gt;
+
+&lt;pre&gt;&lt;code&gt;vagrant@host:~$ mkdir .ssh 
+vagrant@host:~$ cp /var/lib/gems/1.8/gems/vagrant-0.8.7/keys/vagrant .ssh/id_rsa
+vagrant@host:~$ chmod 600 .ssh/id_rsa
+vagrant@host:~$ cat /var/lib/gems/1.8/gems/vagrant-0.8.7/keys/vagrant.pub &amp;gt;&amp;gt; .ssh/authorized_keys
+&lt;/code&gt;&lt;/pre&gt;
+
+&lt;h2&gt;jenkins slave设置&lt;/h2&gt;
+
+&lt;p&gt;然后到jenkins主机的 系统管理-&gt;管理节点-&gt;新建节点 来增加vagrant虚拟机节点，如下图。&lt;/p&gt;
+
+&lt;p&gt;&lt;img src=&quot;/blog/images/jenkins-node.png&quot; alt=&quot;配置jenkins虚拟机节点&quot; /&gt;&lt;/p&gt;
+
+&lt;p&gt;例子中，vagrant节点和jenkins主机在一台机器上，所以是localhost，配好了私有密钥，并且设置标签为vagrant-vm&lt;/p&gt;
+
+&lt;h2&gt;jenkins 任务设置&lt;/h2&gt;
+
+&lt;p&gt;现在可以设置新的任务了，选定自由风格（freestyle)，如下图&lt;/p&gt;
+
+&lt;p&gt;&lt;img src=&quot;/blog/images/jenkins-job1.png&quot; alt=&quot;配置jenkins任务&quot; /&gt;&lt;/p&gt;
+
+&lt;p&gt;限定它去vagrant-vm去执行，到时它就会触发jenkins从机(slave)的启动。&lt;/p&gt;
+
+&lt;p&gt;&lt;img src=&quot;/blog/images/jenkins-job2.png&quot; alt=&quot;配置jenkins任务&quot; /&gt;&lt;/p&gt;
+
+&lt;p&gt;然后设置一个构建内容，就是启动虚拟机，执行命令（真实情况会用puppet安装，并进行测试）。&lt;/p&gt;
+
+&lt;p&gt;最后就可以让它跑起来。&lt;/p&gt;
+
+&lt;h1&gt;总结&lt;/h1&gt;
+
+&lt;p&gt;这篇文章主要简单讲了一下在jenkins中管理虚拟机的一种方案，自动化的安装&lt;a href=&quot;http://puppetlabs.com/&quot;&gt;puppet&lt;/a&gt;并没提到，可自己尝试。另外vagrant创立虚拟机也没有谈到，一般可以用&lt;a href=&quot;http://github.com/jedi4ever/veewee&quot;&gt;veewee&lt;/a&gt;这个软件来完成，有空下次讲。&lt;/p&gt;
+
+&lt;p&gt;给些建议鼓励鼓励吧 &lt;a href=&quot;http://weibo.com/larrycai&quot;&gt;@larrycai&lt;/a&gt;&lt;/p&gt;
+
+&lt;h1&gt;参考&lt;/h1&gt;
+
+&lt;ol&gt;
+&lt;li&gt;larry的英文博客：http://codeslife.com/2011/10/21/make-ci-easier-with-jenkins-ci-and-vagrant/&lt;/li&gt;
+&lt;li&gt;stackoverflow的问题讨论：&lt;a href=&quot;http://stackoverflow.com/questions/6941547&quot;&gt;How to combine Vagrant with Jenkins for the perfect Continuous Integration Environment?&lt;/a&gt;&lt;/li&gt;
+&lt;/ol&gt;
+
+</content>
+ </entry>
+ 
+ <entry>
+   <title>敏捷和工具</title>
+   <link href="http://larrycai.github.com/2011/08/18/agile-tools.html"/>
+   <updated>2011-08-18T00:00:00+08:00</updated>
+   <id>http://larrycai.github.com/2011/08/18/agile-tools</id>
+   <content type="html">&lt;h1&gt;敏捷和工具&lt;/h1&gt;
+
+&lt;p&gt;【特别声明】本篇文章刊登在&lt;a href=&quot;http://www.programmer.com.cn/8020/&quot;&gt;程序员2011年第八期&lt;/a&gt;，如需引用，请注明出处。&lt;/p&gt;
+
+&lt;h1&gt;简介&lt;/h1&gt;
+
+&lt;p&gt;敏捷软件开发绝不再是一个新名词了，但理解还是时时有偏差。敏捷宣言中的第一条“个体和互动 高于 流程和工具”【1】，有人就误读为“有了沟通，一切都迎刃而解” ，因此花费大量精力整顿团队合作，却轻视了工具（技术）。其实宣言中的意思只是想强调个人和沟通更重要而已。&lt;/p&gt;
+
+&lt;p&gt;实际上，既然是软件开发，在所难免得面临工具的选择，而且很多优秀软件实践离开强有力的工具支持都玩不转，孙悟空还要个金箍棒呢，对吧？&lt;/p&gt;
+
+&lt;p&gt;另外在如今的软件开发世界中，工具（这里谈的是软件工具）层出不穷，数不甚数，那么到底该怎么去选择适合的工具呢？&lt;/p&gt;
+
+&lt;p&gt;本文作者根据十几年的企业级软件开发经验给出一点建议，在此和大家一起来探讨敏捷和工具（特别是在企业实施中的工具）这个话题。&lt;/p&gt;
+
+&lt;p&gt;为了避免不必要的麻烦，文中尽量用开源软件作为介绍，但这并不是说笔者排斥商业软件，恰恰相反，在很多时候，只有商业软件才提供了你需要的功能（当然大部分情况下开源软件会很快迎头赶上，哈哈）。&lt;/p&gt;
+
+&lt;h1&gt;背景知识：应用程序生命周期管理&lt;/h1&gt;
+
+&lt;p&gt;聊到软件开发中的工具，一般都会提到这个术语--“应用程序生命周期管理（Application Lifecycle Management ：简称 ALM）” ，说句老实话，有点烂，谁都想把自己往上靠，谁都有自己的一套说法，下图为笔者心中贯穿企业开发项目全程的ALM全局观。&lt;/p&gt;
+
+&lt;p&gt;&lt;img src=&quot;http://larrycai.github.com//images/alm-overview.jpg&quot; alt=&quot;图一：开发项目中应用程序生命周期管理及其工具&quot; /&gt;&lt;/p&gt;
+
+&lt;p&gt;图一：开发项目中应用程序生命周期管理及其工具&lt;/p&gt;
+
+&lt;p&gt;图一中列出了ALM中的各个子系统，以及笔者略有研究的相对应工具的名称，让我们一起先来简单地过一遍整个过程。&lt;/p&gt;
+
+&lt;ul&gt;
+&lt;li&gt;产品开发始于一定的需求，需求有好几个层次，从产品需求到项目需求，进而产生出用户故事（User Story）， 然后团队会分解出任务（Task）。&lt;/li&gt;
+&lt;li&gt;团队开发者利用IDE（如Eclipse）去完成相应的代码，单元测试完成后，再推送到代码库（git），这一块和软件配置管理(Software Configuration Management: 简称SCM) 相关。&lt;/li&gt;
+&lt;li&gt;构建系统会从代码库中获取最新的代码，进行编译，打包，功能测试，系统测试，可以设置在质量系统中显示一些相关信息， 如果一切顺利，甚至能直接上传到在线系统更新上线，此外不管是开发中还是运行中一般还都会有一个缺陷管理系统。&lt;/li&gt;
+&lt;/ul&gt;
+
+
+&lt;p&gt;BugZilla大家应该很熟悉了，用Redmine【2】的人少一些，但它实际上是一个非常灵活的项目管理系统，国内也有越来越多的公司在使用了，Nexus是一个java软件包的管理工具，需要和Maven结合使用，Sonar是一个java项目的质量控制工具，它集成了如单元测试、覆盖率、静态质量检查等内容。为什么任务管理下的Redmine有红叉呢？我们稍后会解释。&lt;/p&gt;
+
+&lt;p&gt;限于篇幅，本文只会谈到其中的一部分工具。作为参考，可以阅读Manning出版社的新书《Agile ALM》【3】，它对SCM，单元测试，功能测试等话题进行了更深入的探讨，当然笔者也希望将来有机会再和大家分享其他工具的心得体会。&lt;/p&gt;
+
+&lt;h1&gt;敏捷中有些工具是必须的&lt;/h1&gt;
+
+&lt;p&gt;如果你说敏捷实施大半年了，但持续集成 (Continuous Integration：简称CI）服务器却还没有架起来，那笔者实在是不晓得你都在敏捷些啥东西了。无论你是否“信仰”或“信仰”哪种敏捷，产品开发各个方面的自动化（Automation）和持续集成都必不可少。要了解持续集成，可以看看Martin Fowler的文章，可谓白皮书级别的经典，有中文翻译版【4】。&lt;/p&gt;
+
+&lt;p&gt;&lt;img src=&quot;http://larrycai.github.com//images/jenkins-logo.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;
+
+&lt;p&gt;使用CI就一定会用到CI服务器，可选的有很多，其中Jenkins【5】是现在一个最流行的，而且架设起来也很方便。实际上它是从Hudson继承而来【6】（自从2011年五月Oracle决定把Hudson捐献给Eclipse组织，两者的关系和将来的发展方向也可能带来更多变数【7】）。&lt;/p&gt;
+
+&lt;p&gt;在Jenkins构建服务器中，可以定义任务（在Jenkins中叫job），以完成一些构建步骤（如签出代码，编译，各种类型的测试，打包，等等），它有极丰富插件（plugin）资源作为支撑，可以来集成产品软件开发的各个要素，它把你所需要的一切都自动化起来。&lt;/p&gt;
+
+&lt;p&gt;&lt;img src=&quot;http://larrycai.github.com//images/jenkins-jobs.jpg&quot; alt=&quot;图 二：Jenkins项目自己的Jenkins构建服务器&quot; /&gt;&lt;/p&gt;
+
+&lt;p&gt;图 二：Jenkins项目自己的Jenkins构建服务器&lt;/p&gt;
+
+&lt;p&gt;在Jenkins构建服务器的首页，每个任务还都有一个天气图标表示其状态，非常直观，例如“太阳”就代表着一切正常（至少从构建结果来看）。它是产品项目开发的晴雨表，项目状态是否正常一目了然。不管是是对Jenkins不了解还是想提高，笔者强烈推荐阅读John Ferguson Smart的Jenkins开源书： 《Jenkins: The Definitive Guide》【8】&lt;/p&gt;
+
+&lt;p&gt;所以，对敏捷来说，并没有“CI服务器要还是不要”一说，它就是必须的，一定要好好地实施。基于持续集成再往前走，就是持续交付（Continuous Delivery）了，这也是敏捷的一个新热点，其中加入了很多新元素（如自动化验收测试，持续部署等）。再此先做个友情广告，图灵公司负责翻译出版的《持续交付》中文版即将出版发行，它会给你更多的最新理念来促进敏捷。&lt;/p&gt;
+
+&lt;h1&gt;别让工具牵着鼻子走&lt;/h1&gt;
+
+&lt;p&gt;工具很重要，但会不会有些误区呢？当然有，我们一起来看个笔者经常碰到的一个例子。
+讲到敏捷实施一直都会提到白板（Whiteboard）的使用，得先提醒大家，它也是一个“工具” ，白板的其中一种用法叫任务白板，主要是提供给团队使用的。&lt;/p&gt;
+
+&lt;p&gt;&lt;img src=&quot;http://larrycai.github.com//images/whiteboard.jpg&quot; alt=&quot;图三：每日例会中的任务白板（图来自《硝烟中的Scrum和XP》一书）【9】&quot; /&gt;&lt;/p&gt;
+
+&lt;p&gt;图三：每日例会中的任务白板（图来自《硝烟中的Scrum和XP》一书）【9】&lt;/p&gt;
+
+&lt;p&gt;图三就是常见的任务白板，团队的需求，一般是用户故事（User Story），被放在最左边一栏“NOT CHECKED OUT”，作为团队一个迭代的输入，然后分解成任务（Task）用报事贴（俗称黄贴）贴在白板上“CHECKED OUT”那一栏，并签上自己的名字，就算是领任务啦，当做完了一个任务就把它（黄贴）挪到下一栏“DONE！:o)”，代表做完了，最右边一般还会留出部分空间，用来记录进度条和注意事项来提醒团队一些重要的事情。&lt;/p&gt;
+
+&lt;p&gt;如果说Jenkins构建服务器是产品开发的晴雨表，那么任务白板就是团队开发的晴雨表。&lt;/p&gt;
+
+&lt;p&gt;一般一大早在每日的站立会议 (Daily Standup Meeting)上，整个团队所有人都会围在白板前，分享所负责任务的进度，顺便挪动一下任务到相应的状态栏，用这种方式能够减少很多不必要的汇报型会议，而且团队成员也能很快地就了解到开发的整体状况。相信如果某个黄贴在白板上连着三天都没动，团队里一定会有人站出来帮忙的。（没有？！那还是先组织他们参加团队合作的培训吧）&lt;/p&gt;
+
+&lt;p&gt;有时候团队坐得比较分散，或者有人喜欢流行的在家办公方式，这时可能会开始使用一些图形化的电子白板来管理团队任务，大家对着屏幕介绍进度，效果似乎还不错，其他人（包括经理们）也非常高兴，因为他们可以随时从网上了解到团队的进度了。慢慢地，面对面的时间看起来也可以节省下来，只要窝在座位上点点鼠标，挪挪电子黄贴（如果支持漂亮的拖拉就更好了）就已经足够了。&lt;/p&gt;
+
+&lt;p&gt;这样真的好吗？这是敏捷的好实践吗？&lt;/p&gt;
+
+&lt;p&gt;是否嗅到了一点怪味道？它就是笔者想谈的工具带来的误区，电子白板会削减团队之间的沟通，降低团队的透明度，而这违背了敏捷重视人和团队的原则。如果你的团队成员不经常去更新电子白板上的任务时间，那慢慢你看到的都是不太准确信息了。有人可能说我们还是面对着电子白板开每日站立会议呀，那笔者希望你有个很大的屏幕吧（否者这样子效果会更差）。&lt;/p&gt;
+
+&lt;p&gt;那为什么笔者没说它不对呢，因为在一些场合下，它还是有作用的。关键是团队要能充分认识到它的局限性，因此笔者极力反对在团队组建初期用电子白板，可以等团队充分领会到敏捷中人与人沟通的重要性后再引入。&lt;/p&gt;
+
+&lt;p&gt;这也是笔者在图一中特意用红叉提醒不要用Redmine来管理任务（这个白板功能的插件也很差，因为没人用）&lt;/p&gt;
+
+&lt;p&gt;所以要了解你的需求，不要让一些工具牵着鼻子走，要了解敏捷实施的目的，否者出了问题还以为工具不到位，拼命要更强的功能，结果陷入大误区。&lt;/p&gt;
+
+&lt;h1&gt;有些工具会带来意想不到的好处&lt;/h1&gt;
+
+&lt;p&gt;传统的敏捷著述中通常会提到CI的部分，然而工具的运用并不限于此，例如笔者在实际项目中用到的Gerrit【10】，它非常契合敏捷的宗旨，也给我们带来了意想不到的好处。&lt;/p&gt;
+
+&lt;p&gt;代码审阅是一个不错的敏捷开发实践，让人非常头疼的是实施。大企业中通常是制定出一大堆相关的规范和流程来指导代码审阅。笔者听说好多公司都会把代码打印出来，进行走读，这可真是累啊（幸好我们公司不搞这一套，哈哈）。这种方式会给人不信任的感觉，而且应该是挺浪费时间的。&lt;/p&gt;
+
+&lt;p&gt;结对编程（Pair Programming）也是非常好的一种代码审阅的方式，值得好好地学一学，只是笔者对它并不太感冒，体会是在大企业实行结对编程的难度很大，当然如果能找到合适的推动者，那还是可以尝试尝试的。&lt;/p&gt;
+
+&lt;p&gt;那看看开源社区是怎么解决这个问题的呢，使用的又是什么工具呢？谷歌的 Android 系统是现在非常热门的开源项目，它的代码审阅（包括贡献者的代码）使用的是Gerrit，非常棒的东西，在自己的企业中架设起来也非常方便，我一用就“爱”上它了。&lt;/p&gt;
+
+&lt;p&gt;&lt;img src=&quot;http://larrycai.github.com//images/gerrit-demo.jpg&quot; alt=&quot;图四：Android的Gerrit代码评审系统截图【11】&quot; /&gt;&lt;/p&gt;
+
+&lt;p&gt;图四：Android的Gerrit代码评审系统截图【11】&lt;/p&gt;
+
+&lt;p&gt;Gerrit是一个基于 Web 的代码评审和项目管理的工具，面向基于 Git 版本控制系统的项目（git是一个分布式版本控制系统），所以如果你没用git（干嘛不用呢），就没法用gerrit了，接下来来看看在gerrit中怎么实施代码评审的。&lt;/p&gt;
+
+&lt;ol&gt;
+&lt;li&gt;首先开发者（贡献者）的代码变更通过 git 命令被推送（push）到 gerrit 管理下的 Git 版本库，推送的提交转化为一个一个的代码审核任务（见图四）&lt;/li&gt;
+&lt;li&gt;代码审核者可以通过 Web 界面查看审核任务、代码变更，通过 Web 界面做出通过代码审核（Review）或者拒绝（Reject）等决定。&lt;/li&gt;
+&lt;li&gt;测试者（一般可以设定为CI服务器执行）可以通过访问来获取（fetch）代码变更进行相应测试， 如果测试通过， 就可以把这个评审任务设置为校验通过（Verified）。&lt;/li&gt;
+&lt;li&gt;最后经过了审核（Review）和校验(Verified) 的代码变更可以通过 gerrit 界面中提交动作合并到版本库的对应分支。&lt;/li&gt;
+&lt;/ol&gt;
+
+
+&lt;p&gt;相比代码走读，它的好处在于，审阅动作发生在向主干提交代码前，可以只看变更的部分显得很贴心，网上随时随地审阅起来也很方便，这也是有别于结对编程的一个好处。&lt;/p&gt;
+
+&lt;p&gt;任何人都可以审阅提交的代码，整个团队的代码都一目了然，审阅起来更方便，非常符合开放、透明的敏捷精神。使用之后能够显著提高代码质量，甚至于等到习惯了以后，代码不被审阅一下，都觉得实在是不好意思提交代码到主干上去。&lt;/p&gt;
+
+&lt;p&gt;Gerrit中，通过特定分支，任何审核任务的代码变更都能访问，所以如果需要细看或是合并到本地都异常的方便。&lt;/p&gt;
+
+&lt;p&gt;Gerrit刚开始实施可能会有点不习惯，毕竟整个工作流有所变化，因此实施时需要通盘考虑，国内的蒋鑫写了本《Git权威指南》【12】，值得去看，可以了解git，以及gerrit如何搭建。&lt;/p&gt;
+
+&lt;p&gt;如上只是近期笔者特别喜欢的一个工具，其实类似的工具还有许许多多，这不过是沧海一栗而已。我们需要不断地学习，去尝试和掌握它们，它们会带来意想不到的好处，可以会解决一些一直困扰着你的问题。&lt;/p&gt;
+
+&lt;h1&gt;总结&lt;/h1&gt;
+
+&lt;p&gt;水能载舟，也能覆舟，工具和敏捷的关系亦如此，这正体现了中国文化中的平衡，下面笔者给出几点建议：&lt;/p&gt;
+
+&lt;ul&gt;
+&lt;li&gt;积极尝试新工具，如今的软件开发世界中，工具层出不穷，要不断的与时俱进， 了解最新动向和如何用有效的工具去辅助敏捷的实施，在自己的软件开发环境中去尝试和了解这些工具，尝试这一点很重要， 不要只看说明或戴有色眼睛去看待这些工具， 应该通过实践摸索找到最适合你的选择。&lt;/li&gt;
+&lt;li&gt;人总是第一位的，要了解你的团队，了解他们的需求，有些时候甚至可以为了团队，冒险一下采用新技术、新工具， 这样可以提高团队的凝聚力（敏捷要素之一）。笔者待过的一些部门推动git时，就是这么来的， 很多时候过多的讨论其优缺点反而是浪费时间，不如多花点时间多试试。&lt;/li&gt;
+&lt;li&gt;实施敏捷也离不开组织的支持，特别大型企业涉及到的人很多（可能水平不一）， 这时候推动者就必须用专业的手段建立一个持续渐进的工具引入过程，这样会使得实施更容易些。&lt;/li&gt;
+&lt;/ul&gt;
+
+
+&lt;p&gt;唠叨这么多，实际上也只是讲到一些皮毛，还有很多东西需要我们继续研究下去，所以很希望能和大家一起持续地探讨（联系方式请参看个人简介），也希望本文能带给你一些启示。&lt;/p&gt;
+
+&lt;p&gt;本文得到了《Maven实战》作者许晓斌【13】，敏捷宣言简体中文版翻译的协调者徐毅【1】，敏捷之旅中国组织者滕振宇【14】和同事代鹏的帮助，他们提供了很多宝贵的意见，谢谢！&lt;/p&gt;
+
+&lt;h1&gt;参考&lt;/h1&gt;
+
+&lt;ol&gt;
+&lt;li&gt;中文敏捷宣言：&lt;a href=&quot;http://agilemanifesto.org/iso/zhchs/&quot;&gt;http://agilemanifesto.org/iso/zhchs/&lt;/a&gt;&lt;/li&gt;
+&lt;li&gt;Redmine: &lt;a href=&quot;http://redmine.org/&quot;&gt;http://redmine.org/&lt;/a&gt;
+3.《Agile ALM》：&lt;a href=&quot;http://www.manning.com/huettermann/&quot;&gt;http://www.manning.com/huettermann/&lt;/a&gt;&lt;/li&gt;
+&lt;li&gt;持续集成理论和实践的新进展：&lt;a href=&quot;http://www.infoq.com/cn/articles/ci-theory-practice&quot;&gt;http://www.infoq.com/cn/articles/ci-theory-practice&lt;/a&gt;&lt;/li&gt;
+&lt;li&gt;Jenkins：&lt;a href=&quot;http://jenkins-ci.org/&quot;&gt;http://jenkins-ci.org/&lt;/a&gt;&lt;/li&gt;
+&lt;li&gt;Hudson正式更名为Jenkins：&lt;a href=&quot;http://www.infoq.com/cn/news/2011/02/jenkins&quot;&gt;http://www.infoq.com/cn/news/2011/02/jenkins&lt;/a&gt;&lt;/li&gt;
+&lt;li&gt;Oracle proposes to move Hudson to Eclipse：&lt;a href=&quot;http://kohsuke.org/2011/05/04/oracle-proposes-to-move-hudson-to-eclipse/&quot;&gt;http://kohsuke.org/2011/05/04/oracle-proposes-to-move-hudson-to-eclipse/&lt;/a&gt;&lt;/li&gt;
+&lt;li&gt;Jenkins: The Definitive Guide》：&lt;a href=&quot;http://www.wakaleo.com/books/jenkins-the-definitive-guide&quot;&gt;http://www.wakaleo.com/books/jenkins-the-definitive-guide&lt;/a&gt;&lt;/li&gt;
+&lt;li&gt;李剑翻译的《硝烟中的Scrum和XP》： &lt;a href=&quot;http://www.infoq.com/cn/minibooks/scrum-xp-from-the-trenches&quot;&gt;http://www.infoq.com/cn/minibooks/scrum-xp-from-the-trenches&lt;/a&gt;&lt;/li&gt;
+&lt;li&gt;Gerrit：&lt;a href=&quot;http://code.google.com/p/gerrit/&quot;&gt;http://code.google.com/p/gerrit/&lt;/a&gt;&lt;/li&gt;
+&lt;li&gt;Android的代码审阅：&lt;a href=&quot;https://review.source.android.com/&quot;&gt;https://review.source.android.com/&lt;/a&gt;
+12.《Git权威指南》：&lt;a href=&quot;http://www.ossxp.com/doc/gotgit/&quot;&gt;http://www.ossxp.com/doc/gotgit/&lt;/a&gt;
+13.《Maven实战》和许晓斌：&lt;a href=&quot;http://www.juvenxu.com/mvn-in-action/&quot;&gt;http://www.juvenxu.com/mvn-in-action/&lt;/a&gt;&lt;/li&gt;
+&lt;li&gt;敏捷之旅中国：&lt;a href=&quot;http://agiletour.cn/&quot;&gt;http://agiletour.cn/&lt;/a&gt;&lt;/li&gt;
+&lt;/ol&gt;
+
+
+&lt;h1&gt;作者简介&lt;/h1&gt;
+
+&lt;p&gt;&lt;a href=&quot;http://weibo.com/larrycai&quot;&gt;@larrycai&lt;/a&gt;作为软件实践的先行者，公司的主要工作就是探索软件开发的最好最适合的方法和工具，使得该研发中心成为IT领域顶尖人才向往的地方之一。同时他是一个开源，协作和敏捷的布道者。&lt;/p&gt;
+
+&lt;p&gt;本文提到的内容在 ScrumGathering上海2011上做过专题演讲，参见&lt;a href=&quot;http://t.cn/aCKFrd&quot;&gt;演讲稿件&lt;/a&gt;。&lt;/p&gt;
+</content>
+ </entry>
+ 
+ 
+</feed>