闲亭信步（KISS）

how to use systemd or systemctl on linux

自从2009年6月，Cruise team 开始尝试在项目中使用Kanban。作为项目经理，非常高兴这个改变，在回顾会议上，Team反映也很好。它让整个团队更加聚焦于频繁部署产品，因些也非常容易识别项目运行过程中的瓶颈，以及对事情排定优先级。不再有项目估算会议，取而代之的只是平均每张卡片的生命周期。所以，对于整个团队来说，唯一重要的事就变成了“如何让每张卡片快速走完它的生命周期”。Releas

几个月前参与翻译的《the Thoughtworks Anthology》终于面市啦，中文名为《软件开发沉思录》。共有13篇文章，是ThoughtWorks的思想沉淀，内容包括软件开发过程中的各个方面，如项目管理、迭代管理、发布管理、敏捷开发与测试。 以前发布的《一键发布》就是其中一篇。还包括《练习OO的原则》。这是豆瓣上的链接。

在Cruise项目使用了Story&Process/Themes Mapping的方法来检查Story list是否有遗漏。操作起来也非常简单。其步骤是： 一、将所有业务流程画在一个大白板上；（画不下的话，找更大、或更多的白板。自己想办法吧）二、将所有的Themes分栏放在桌面上。三、将所有的Story打印在小卡片上（两份）。四、根据业务流程的相关性，将小卡片贴在相应的

 昨天中午的BA交流讨论会上，小裴讲了一下在某项目收集需求，捕捉用户故事（Story）的过程，很是值得深思。其关键在于INVEST原则中的V（Valuable）。该项目是一个有很多分析图表的改造项目，需要保持当前的数据，并修改或增加一些图表。例如：  那么，对于这类分析图表如何写用户故事（Story）呢？ 最初，是根据图表的区域来划分用户故事（Story）。即左边的折线

 在上个星期，与一个项目的开发人员讨论了有关项目中的非功能需求（我们手中有一些关于非功能需求比较High Level的描述），目的是让这些东西落地。 这种形式的讨论一下子让我想起了CMMI中的评审过程，非常的类似，但却有本质的不同。＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋CMMI中的评审过程是当项目某些Artifacts产生出

 在去年的AgileChina大会中，Jez Humble(Cruise的产品经理)提到了持续集成的成熟模型， 从低到高为：  1 自动化构建并持续编译(Automated build / continuous compilation)2 让单元测试自动化(Automated unit tests)3

Martin Fowler 最近在用分布式版本控制工具（mercurial/GIT），并写了一篇博文，名为《特性分支》，主要讨论了使用分布式版本控制工具以后，可能的三种工作方式。（非常佩服Martin Fowler的总结能力。） 1. 堆积变更，推迟合并       在我看来，这种方式的确充分利用了DVCS的灵活性，但显然，不爱频繁提交的开发人员很可能一直发扬这个坏

前些日子写了关于小规模产品团队的持续集成实践，之后就一直就忙于项目，今天终于有时间完成这一篇关于大规模项目的持续集成相关问题了。 一、持续集成基础在典型的软件项目中，集成阶段一般都是在最后，因此也是出现问题最多，而且最有可能导致不能按时交付。而持续集成（XP十二实践之一）可以用来解决这个问题。既然大家都认为“频繁地使软件在某一代码基线构建并通过测试”是个不错的做法，那么

自从去年开始，Cruise团队就坚持一周至少更新自己使用的Cruise服务器一次，更新其它团队使用的Cruise服务器一次。四个月前，我们又建了一个Personal build CI server，而这个server的部署频率更高，只要每次提交到团队持续集成服务器上后单元测试通过，Cruise就会将其自动部署到这个Server上。效果非常不错，因为这个持续集成服务器是每个开发人员做pre-comm

This manual deployment process was as follows.1. Logon to the ‘build box’2. Get latest3. Open visual studio and compile the application4. FTP the resulting app to a staging area on our product

持续集成已经是一个古老的话题了。有的公司跃跃欲试，有的公司浅尝则止，有的公司半路放弃，而有的公司去能持之以恒。这是什么原因呢？既然是一个古老的话题，那与它刚出现的时候相比，现在是否有了新的变化呢？受优快云之邀，本人将在软件开发2.0(SD2.0) 软件工程专场（本月23日上午9:00）和对此话题有兴趣的朋友一起探讨这一主题，题目

 原则一、首先要行动起来 改进多是些平常没有做过的事情，不要在做之前就罗列出各种各样做不到的理由。先试试，有不对的地方，马上修正就好。 原则二、工作内容的可视化 要将工作的流程和进度，随时都能被看得见。要将工作中的异常现象凸显出来，并马上采取措施。 原则三、生产效率的可视化 改进的好了还是坏了，不能搞不清楚。专注于能够提高生产效率的改

不能持续学习的团队，会出现下面的一些症状：·     疲劳（持续在紧张的节奏下工作）导致士气低落。·     在一个迭代周期中，反复地出现无法达到 “完成状态”的现象。·     承诺的任务总是无法完成（有些特性或任务甚至还没开始）。·     已经部署的软件不断地有缺陷暴露出来，导致开发计划流产。·     减少或者取消回顾会议（“因为从来没有真地解决过发

ThoughtWorks笔试题汇总 2016

ubuntu16.04 install oracle java8 step by step

Emacs24的自动折行设置

我去过多个公司，加入过多个团队，也带过多个团队。让我感觉软件开发是如此美好的团队只有一个，那就是我在Thoughtworks工作时，加入并带领的产品团队——Cruise。到目前为止，对我来说，那两年的经历（2007~2009）的确是最美好的巡游——正如这个产品的名字。今天在这里列出所有的Cruiser，以及故事中提及的人。 1. 乔梁（就是我），Delivery man

1) Visualize the workflow2) Limit the work-in-progress3) Measure and manage flow4) Make process policies explicit5) Implement feedback loops6) Improve collaboratively (using models & scienti

之前没有用过CPPUnit，可是现在的公司在用。为了准备TDD代码道场，今天下载了一份。可刚编译就遇到了问题，查了一下，是原代码包中的配置项错了，现象如下：运行　./configure 和make以后，出现错误：undefined reference to `dlclose'undefined reference to `dlopen'undefined referen

本文是 王晓明同学在InfoQ发表的文章《关于项目估算的微博讨论》中提到的排序法详解。一、引言软件项目的估算历来是一个难题。由于软件开发活动还无法实现土建工程那种成熟度，所以也无法像做土建工程那样通过预算速查手册来评估。但是，对于一项投资来说，总要说出要投资多少吧，软件开发也要给出投资额，这就需要做估算了。本文主要讨论敏捷软件开发中的用户故事（User Story）

目前，持续集成工具多达30种，每种工具都有自己的特点。在国内，软件企业很少为这类产品付费，所以国个目前最流行的包括Hudson（开源），CruiseControl（开源），TeamCity（商业版，买了IntellJ的License就能免费使用）。而在国外，还有两个比较流行的工具

以前用过几次这个东东，但每次都重新查询一次。本文原始出处是这里。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－Keytool是一个Java数据证书的管理工具,Keytool将密钥（key）和证书（certificates）存在一个称为keystore的文件中在keystore里，包含两种数据：

继续《理解面向对象的练习原则》 所有原则要在大家做练习时使用。但只有练习过，才更容易理解面向对象。 一个整型数字本身没有任何意义。当某个方法用一个整型参数做参数时，这个方法名就要负责解释一切。假如这个方法使用Hour作为参数，那么就更容易知道它是做什么一些了。小对象可能会使代码易维护一些，因为你可能把一年的"1"传到这个方法中。 而且使用原始类型的变量时，编译器无法帮助

什么是个人预提交（Personal build）?Personal build简单来说，就是开发人员在代码提交之前，先要自己在本地运行一次构建和测试代码，保证本地没有测试失败后，再将其提交到中央代码仓库。Personal build的痛处在哪里？“提交代码之前，必须在本地运行并通过单元测试”是敏捷团队的原则之一。而随着新功能的增加，我们的单元测试越来越多，运行时间当然也就越来越

最近，在google group的Agile china讨论组有一个关于Scrum培训的讨论。其中有一个回贴提到"scrum对管理层的要求更高"。那么，再进一步，Agile对管理层的要求更高吗？个人认为，至少在采纳Agile的初始阶段，这种提法似乎不是很正确。（我假设这里的“管理层”是指有决定权的组织级管理者） 首先，无论我们采用什么方法，最终都是为了一个目的，即“创造更多的价值”。如果能够创造

如果你的开发团队正在使用敏捷开发方法，而客户并不在意什么开发方法，他们只想尽快地拿到他们需要的软件。作为项目经理，你该怎么办呢？如果客户不知道敏捷开发方法，那么向他介绍敏捷开发方法是项目经理应该做的一件事，但是要适可而止。因为能用的软件才是他们想要的，在没有深刻体会到它带来的益处时，你是无法用嘴皮子来证明的。但并不能这么就算了，因为还要保持开发团队的士气呢。所以，一方面要在客户能够接受的程度下尽量

持续集成是敏捷最佳实践之一，但并不是只有使用敏捷方法的团队才能够采纳。但如果你能够采纳敏捷方法，那么它会发挥更大的作用。“什么是持续集成”在前面的文章中已谈过了，这里只把其中的一部分：持续集成的六个基本自动化再细说一下。这六个基本自动化是：自动运行测试、自动产生可部署的二进制文件，把它部署到类似生产环境中，自动标识你的代码基线，自动运行回归测试以及自动产生度量。一、运行测试 　　这本来是不必说的事

在今年的2月29日，访问了一个基于JRuby的Web应用。可返回的结果是：29号不是有效日期。看它的异常报告，个人猜测是JRuby的一个Bug，不是很确定。

自从2005年开始，Yahoo! 在美国、欧洲和亚太地区就开始尝试使用Scrum进行软件产品开发。最初仅选择了四个团队进行尝试。到目前为止，已有近200个团队在不同程度上使用Scrum。这里所说的“不同程度”是指不同的受益程度。Yahoo!有一个由三个人组成的类似于教练团的组织，该组织成员与其他项目的成员一起参与项目，一起解决他们遇到的关于过程和方法方面的问题。根据实施效果来看，仅仅三个人是远远不

最近，有一个关于组织内采纳敏捷软件开发实践情况的调查，调查结果产生于2008年2月。所提的问题是“你所在的公司，采纳敏捷方法（包括XP, Scrum,TDD等等）”的情况如何？“ 同样的调查已在2005年进行过一次了。结果如下：   2008 2005

在敏捷团队中，BA（业务分析师）的一项主要工作就是分析User Stories。一般来说，我们用纸卡写记录它们。Mingle发布以后，我们开始使用它来管理我们的故事卡片。Mingle是一个很好用的敏捷项目管理工具，说它好用是因为它的可定制性非常好。你可以用它管理你的项目，即使你用传统的项目管理方法。它暂时还不能完成我（一个BA）想要的功能，即（1）我可以任意拖动我的卡片，（2）在它们之间任意的画线

CMMI 是一种已被很多IT公司广泛采纳的过程框架，而Agile是一种逐渐流行起来的软件开发方法。 从根本上讲，CMMI是一种过程改进框架，针对软件工程的管理，它定义了一整套的过程。而Agile可以被认为是针对软件活动的迭代软件开发框架，二者的目标也不完全相同。与Agile相比，CMMI的范围更广泛，它还包括产品支持与维护等其它方面。CMMI基于两种潜在的假设： 软件开发过程是可以或

精益（Lean）从泰勒的”科学管理理论“，其思想源于消除浪费敏捷（Agile）的初衷是应对变化有观点说：”敏捷是软件行业中的精益“，但二者还是有一些区别的。精益可以说是一种比较完善的管理思想或理论，而敏捷可以说是一种做事原则或方法。精益是否发挥了作用，可以用实实在在的金融指标来衡量。而使用敏捷的效果还不能用金融指标来一概而论。敏捷如何发展呢？走向精益吗？还是......？让我们拭目以待吧。

现在，“敏捷”一词被“炒”得沸沸扬扬，也被“吵”得扬扬沸沸。前不久，还有人提出“后敏捷”时代的来临。我不能枉言这种“chao”是否为当今时代“特征”？但有一点是可以肯定的，那就是：网络使更多的人有更多更大的言语权来影响更多的人。 2001年，从图书馆借了本名为《拥抱变化：解析极限编程》的“小”书。之所以说它“小”，是因为它很薄，每页的文字也不多，页边也很宽，里面有很多图。当时感觉这种风

以前没使用Nant和Nunit建立过C#代码的自动化构建，今天自己写了一个C#程序，想用Nant和Nunit构建C#代码。可写好build文件后运行UnitTest时遇到了麻烦。命令行提示如下：Could not load file or assembly nunit.framework, Version=2.4.3.0, Culture=neutral, PublicKeyToken=

假设阅读本文的同学已经使用过Mingle，Mingle是一个项目管理工具，生来就可能很好地为敏捷服务，而且马上就有新版本发布。——————————————————————————————————————————用Mingle半年多，为Card增加了很多属性，今天想作个图表，看看Story增加到开发范围内的趋势是什么样。却发现只有In Scoped属性，却不知道是什么时候创建的。我们的迭代是固定时间

十三人组成的敏捷团队在两天内能做些什么呢？4月19日和20日，公司在北京office进行了一次“Code Jam”。这次Code Jam是一个迷你型的敏捷项目，其目标是为乡村教育促进会（一个国际非盈利性组织，致力于通过素质教育改善中国农村地区儿童的生活）开发一个内部资源共享平台，以便分布在三个省份（山西、安徽和山东）的教师可以通过网络分享他们的教学计划和教学方法，互相学习交流。 本次项目

else关键字多了以后，当增加新需求时，很容易令人不由自主地去增加新的if...else子句，而不是去重构代码。而且，这种条件判断较多的地方，很容易出现代码重复的现象。例一：应用原则之前：public static void endMe() {    if (status == DONE) {         doSomething();    } else {          

原则一：每个方法只使用一层缩进。如示例代码所示，应用原则(1)之前,代码只有一个方法，要通读代码之后，才知道该方法的用法；应用之后的代码有三个方法，但每个方法都只做一件事，而方法名反应了它做什么事，所以很容易理解。 之前：class Board {　　...  String board() {    StringBuffer buf = new StringBuffer()