博客园_Xiao Peng

也说说我的5个特质

2010-12-31T13:17:00Z

胡凯和熊节分别发布了自己的5个优势或者特质。我也总结一下我的吧。

坚持。人们对摩羯座最大的恭维，莫过于——万王之王的称号。做事情有头有尾。就拿我现在在翻译的POSA第4/5卷来说，两本书翻上3年多，虽然不是太光荣的事情，但是我毕竟把它做完了，而且中间我从来没有想过放弃。
保守。我非常热衷变化，但是我总能想办法找到更小的变化。所以，我做咨询的时候，客户说还是你为我们着想，因为我在三个人里面总是扮演把“激进的”方案往回拉的那个人。
表现欲。我的价值观第一条就是影响力。要达到影响力，首先就要表现。而反过来我的保守让我只有在有九成把握的时候才出来表现，确让我浪费了很多机会。
设身处地。本能的从别人的角度思考问题。
冷静。

还有一个奇怪的，不放到里面了，我不知道这个该怎么总结。但是我发现当我面临N个选择的时候，如果我认为第i个选择是最合适的，我首先做的事情，往往是先把另外的N-1个排除掉。

Simple Sequence Tutourial

2010-11-30T08:58:00Z

This is a tutorial for the online sequence diagram drawer: Simple Sequence .Sample Code is as below. Paste the code in the editor and the sequence diagram show:

Browsers supported:
Safari, Firefox, Chrome, IE 8 or later.
What is it used for?

To show how the classes cooperate with each other;
To help clear your head with something visualized;

Example:
Let's say
// Client call methodA on A
A.methodA{
  // In the implementation of methodA, we call an internal methodA1
  methodA1();
  // Then we call methodB on B
  B.methodB(){
    // In the implementation of methodB, we call methodC on C
    C.methodC();
  }
}
The result sequence diagram is as:

How is it used?
Just input some pseudo code into the text-box, and nothing more. The simplest way is click the "Insert Sample Code" button and see what's happening.
The grammar:
I believe the grammar is very easy and clear for a programmer reading from the example. There is still some principle when I designed it.

1. All messages must be originated from a pre-defined "CLIENT" entity. But there could be more than one root message invoked from CLIENT.
2. Other messages are invoked inside a root message or its children messages (embedded in "{}" following the parent method).
Tips:

All script saved as you are typing. Fell free to close and reopen you browser at anytime.
If you want an Entity (e.g C) shown before others defined it on the top with :EntityName (e.g :C ).
Limitations:

Keyword new still to be supported, you may use EntityName.new now.
Loop/iteration/if-else still to be supported find a way for your representation.
It is designed to support IE 8 or later, but it doesn't work as well as safari/firefox or chrome.
No, you can't move the lines (that's a feature).

本文链接

Post parameters to server with Java

2010-11-07T08:50:00Z

Sumary:

Use:

data = URLEncoder.encode("para1", "UTF-8") + "=" + URLEncoder.encode("value1", "UTF-8");

Don’t use:

data = URLEncoder.encode("para1=value1", "UTF-8");

Posting data to a server should be very easy. But for some newbies, it could make troubles. I’m a newbie.

Normally after googling, you should find something like this:

From:http://www.javadb.com/sending-a-post-request-with-parameters-from-a-java-class

        //Build parameter string
        String data = "width=50&height=100";
        try {
            
            // Send the request
            URL url = new URL("http://www.somesite.com");
            URLConnection conn = url.openConnection();
            conn.setDoOutput(true);
            OutputStreamWriter writer = new OutputStreamWriter(conn.getOutputStream());
            
            //write parameters
            writer.write(data);
            writer.flush();
            
            // Get the response
            StringBuffer answer = new StringBuffer();
            BufferedReader reader = new BufferedReader(new InputStreamReader(conn.getInputStream()));
            String line;
            while ((line = reader.readLine()) != null) {
                answer.append(line);
            }
            writer.close();
            reader.close();
            
            //Output the response
            System.out.println(answer.toString());
            
        } catch (MalformedURLException ex) {
            ex.printStackTrace();
        } catch (IOException ex) {
            ex.printStackTrace();
        }

If your parameters and values are as simple as this, everything is OK. But if not, you may need a URLEncoder! And that’s what makes me in trouble.

If you write your code as

data = URLEncoder.encode(data, "UTF-8"); 
            //write parameters
            writer.write(data);
            writer.flush();

You are in trouble now. All “width=50&height=100” will be expained as ONE parameter name.

And think a little. Why we need an Encoder? We use an encoder to convert a special charactor into something like %xx, if your code is like above, “=”will be converted. And that now we supposed. So it should be like this:

data = URLEncoder.encode("para1", "UTF-8") + "=" + URLEncoder.encode("value1", "UTF-8");
data += "&" + URLEncoder.encode("para2", "UTF-8") + "=" + URLEncoder.encode("value2", "UTF-8");

That’s it!

本文链接

Parallel Desktop 6: Failed to insall shared folders driver

2010-10-31T05:59:00Z

Please try to remove the file C:\WINDOWS\inf\infcache.1
To do so, please click start -> cmd.exe and type in the appeared window "del C:\WINDOWS\inf\infcache.1" (without quotes)
Warning! This is Windows XP only solution. This should never be done on any other system (like Vista)

如果以上方式不管用可以尝试暂停杀毒软件，包括360之类的。

本文链接

我也说说敏捷中国2010大会

2010-10-16T08:33:00Z

作为主持人和大型敏捷团队的持续交付之路演讲者，我来说说我的敏捷中国2010.

所谓轶事

传说这是国内规模最大的收费的技术会议，我孤陋寡闻，不敢确信，倘若是，心里也不甚自在，因为即使如此，据说还是赔钱赚吆喝。你不知道吧，酒店里面一壶咖啡能卖到600RMB。

当然，这些我都可以装作不知道，自有其他人郁闷。对我来说，累是累了点，但是从项目中脱身出来几天还是挺好玩的一件事情。

13号Mary的精益讲座我只听了上午的场，收获甚微。我想Mary还要照顾很多没有听过精益的朋友，所以花了两个小时的时间讲各种浪费。下午据我的同事说讲的内容收获更多一些，可惜这个时候我回去准备我的演讲去了。

我这个主持人是13号晚上临时被抓的壮丁。原来安排的轻眉（传说是“轻看须眉”的意思，求考证），因为担心英语的问题，临时换成了我。当时连件像样的衣服也没准备，所以大家就看到了14号早上一身便装的主持人。很多事情的复杂性不是外人想象的。就这么简单的串场，13号晚上准备到了将近12点。准备台词，调整时间等等。

我想很多人对于时间的调整会有一些意见，但是主办者确实花了很多的心思。由于上午有3个Keynote，所以中间的休息时间不能太长，而如果是太短，又没法把人拉回来，所以干脆取消了中间的休息时间。事后证明这种安排确实不太妥当，我只是想说主办者真的是花了心思在上面的。

有人可能认为主持人站在前面什么都听得清，其实不然，基本上心思都没法放到演讲上面去。什么时候开始，什么时候结束，下一个人怎么上场，我一直都得准备着。就这样，James Greening提前了5分钟结束还是打了我一个措手不及，没来得及脱掉外套就上去了。

所谓收获

对我来说听讲座的收获可能还不如线下的收获更多一些，我想这可以作为下届大会的一个考虑因素——这就是所谓的平台。最大的收获是认识了两个人——周耀辉和滕振宇。分别是组织转型Track和业务敏捷Track的主席。如果我说从他们身上看到了光辉的人格魅力可能有些俗气，但是这样两个人无所求的付出，实在是让我钦佩不已。

耀辉

我今年讲的话题叫做——大型敏捷团队的持续交付之路。最初，这个话题叫做——如何从持续集成中真正获益，那是一个偏向技术的话题，所以放在技术实践Track。但是后来由于要保证各个Track的数量一致，结构合理，组委会决定把我的话题放到组织转型这个Track上。本来那个话题从技术实践的角度讲述我已经驾轻就熟了，但是如何从组织转型的角度讲确实一个新的挑战。这个PPT，前前后后总共改了不下20个版本。

第一个大版本主要是为技术实践Track讲的，李剑、乔梁、李彦辉跟我帮了不少忙。这个时候，我要考虑的事情就是如何从一个3个小时的话题缩减到40分钟。

通知我转到组织转型的时候已经是9月底了，我还要在公司内做排练，所以匆匆改了一个版本。仗着我对这个话题已经做了不下十次培训和演讲了，我以为只是删减一下就好了，所以没有自己做试讲。结果9月29号的公司内部试讲，差得一塌糊涂。乔梁、彦辉、王锐等给我了很多建议（感谢王锐还帮我做了记录），但是坦白的讲，我在讲的过程中就知道接下来这个PPT肯定要彻底大改了。

第三个大的版本初稿是10月7号做完的，整个十一期间我都在思考，到底怎么讲。一方面以前从这个角度思考的比较少，另一方面也受到我以前演讲的思路约束，迟迟写不出来。到7号的时候，我知道必须得写了。最终的这个样子，是我在6号晚上想出来的。上班的第二天9号，我在公司内又做了一次排练，松哥给了很多建议。主要是如何契合组织转型的主题。其他的同事的意见也大概是这个方面的。周末我又做了一些修改，如果我拿这个版本去讲，我想我能给自己60多分吧。

13号下午场刚刚开始，松哥把我叫出来，说耀辉要跟我过一遍我的PPT。我无论如何没有想到，耀辉所谓过一遍，是指每一页，每一句话都要过一遍，甚至不止一遍。从每一页的表达内容和方式，到前后顺序，我们两个人搞了三四个小时，出来的版本已经真的有组织转型的味道了。我得说，耀辉的细致程度和负责人程度比我的同事们要高得多。我不是不感谢我的同事们，相反，我是觉得作为ThoughtWorker，作为ThoughtWorks family，我们有很多需要从耀辉身上学到的东西。

13号和14号晚上，我没有回家。14号的讲座和下午的采访给了我很多的灵感，特别跟小熊的聊天让我认识到，所谓切入点的问题。我的潜意识里面可能一直认为从持续集成入手才是真正可行和靠谱的。14号晚上我把所有的胶片又详细过了一遍，每一页设定了时间，重新设计了开场。至此，我有了80分的信心。

15号下午的表现，我给自己打84分。我发挥得比我自己、耀辉和李剑想象的都要好。如果没有两个小插曲，我应该可以做得更好。一个是休息时间。第一场和第二场的休息时间改成了5分钟，这个时间连上一趟厕所都不够，男厕所都排起了长龙。我跑到另一个厕所回来的时候时间已经到了。我居然心跳突然加速。开头的笑话说得非常生硬，自我介绍也了然无趣，并且比我预计的时间快了将近一倍。更重要的是，我忘了给自己的电脑插上电源。这就导致了第二个事故。我演讲到了5分钟左右的时候，突然跳出一个对话框——没电了。等我插上电源，重新启动的时候，我的屏幕上的计时从零开始了。所以，我要一边讲，一边计算我还有多少时间。这直接导致后面几页讲的速度明显偏快了。

这次演讲，我模仿大熊在QCon上演讲挖了一个坑，自己感觉还不错。

我：我们这个Track怎么会来这么多人呢？我以为这个Track人少，压力会小一些，才选择这个Track的。我们这个Track讲的是组织转型，我有个小调查：有多人认为组织转型主要是解决跨团队的问题？

（有几个人举手）

我：好，这几个朋友现在可以出去休息一下，半个小时以后再回来。因为我前半个小时都是讲团队内部的事情。最后10分钟将跨团队的问题。

滕振宇

滕振宇居然是我大学（山东大学）的师兄，也是山东的老乡。我以前对Scrum Master认证这件事有一些偏见，进而对从事其中的人也有不好的印象。这次由于突然被抓了壮丁，晚上要彩排回不了家，所以跟他睡到同一个房间里面。晚上我们聊了很多东西，聊到国内技术圈子的沉闷，聊到AgileTour的进展，聊到未来的发展。山大人的直率和务实在他的身上体现的更明显，而我却显得空谈阔论、眼高手低。

在OpenSpace上，他主持了两个游戏。第一个游戏结束后，他问我你知道这个游戏吗。我说不知道。他说我待会儿讲给你听，这是一个可以讲得很深的游戏。想想我刚才走过来的时候，还在考虑要不要给他们捧场，实在是要挤出我心中的“小”来。

其他收获

作为咨询师，如果我听到太多新东西，应该是一件奇怪的事情，譬如精益、持续交付等等。但是还是有一些东西触动了我的思考。

1. Shape your path。Mary讲到的这个概念，让我联想到，我的主题里面讲了切入点之后，更多的从团队需求驱动的角度推动新的实践，缺少牵引和路线的清晰性。

2. 熊子川的从外部消除浪费的成功案例，让我对大型团队敏捷推进这件事有了全新的认识，特别是对我的敏捷V型图的解释，有些观点证明是错误的。

3. Jean的演讲从演讲技巧的角度来说我认为是最棒的一个。她用听众自身的交流，解决了通常大型演讲不能互动的问题，当然她的PPT也做得精彩的不得了。

4. James Greening的演讲则更有原教旨主义的味道。我们一次次自以为是的妥协了，一次次给自己找各种理由。James给我们讲别TMD找理由了，做吧！

5. OpenSpace上第二个游戏实在是笑死我了。

所谓遗憾

刚才说到对从事CSM人的偏见，除了滕振宇还有吕毅、鲍央舟等等。这次大会却没有抽出时间去认识一下他们。主要是上午主持大会，下午接受采访和自己的演讲。

本文链接

A Story of Software Configuration Management Migration in Large Scale Team

2010-09-07T13:17:00Z

So I'd like to tell another story -- a bigger team with 300+ developers and 100+ testers. Stories are different, something are common.

When we arrived, they were using ClearCase. As you know, we hate CC (not CruiseControl). But we decided not changing it at first. The team had some problems. They knew that were their problems. But if you changed the SCM tools, and in case the problems got any worse, they would be the consultants' problem. Instead we used it, cautiously.

We chose a small team, found a good code base line (that compile, pass some tests. Don't be surprised, it's not so easy to find a version that compiles. ), and created a branch for that team, so that other teams would not infect them.

Then we added test script to that branch. Don't get me wrong. The test script were already there, just in another system. They had some mechanisms to keep the mapping between code revisions and test script suites. We decided to replace it with simply putting them together.

We helped the team build a continuous integration environment. (Normally, scm migration is part of the CI process improvement.) It was not so easy, but since the code compiles, we made it.

We trained the team of how to work in a CI process. Many teams don't know what's the right way to work under CI process (though Martin published it several years ago). They modify the code and submit and pray that the code would pass the commit build. We tought them, update, modify code, personal build, update, second person build, commit, commit build.

Till now, two or three week passed. We had showcase each two weeks, in which we will told the client what we had do in the last two weeks and what we would do in the next two weeks. Most team leaders attended the showcase. As the showcase was on-site. They could see how that team work.

And we started the MIGRATION. In the real case, it's a BANG! We told the client, we would help them switch to SVN. And the next morning, they told us all teams (400+ people) had switched to SVN (they OT much more than TWers). We all were astonished!

But everything seemed OK. They had one general CMO, and some developers and testers, who had got trained before our coming. And the had a guide document, telling them how to update, and commit (they use tortoise svn as their client). We admitted that it was not our plan to switch in one night. We even had a plan, in which we designed a sandbox period. But everything just went well. The migration is sort of simple. They found a good code base from OUR TEAM, 'cause we have told them code and test code (script) must be on the same branch. Then they created a repository and commit the code in, send out a mail told everyone to install tortoise svn and check out the code to their computer. The branching strategy is what we showed in a former showcase. The simplified branches is as below (since there were more than 20 teams, the branches strategy is 3-layer, not 2-layer as below. The publish branch are tags, not real branch. We call the strategy as stable main line with active braches ):

__ __ __ __ __ __ __ __ __ __ __ __ __（publish branch)

========================================(integration branch)
| \
| \____________________________________(branch of team A)

\______________________________________(branch of team B)

Since they started using SVN, we were forced to start the training at once. What we told most was about merging. They used to use beyond compare to merge changes between branches. We told them as long as you do as we told, you could let SVN to merge them with good confidence.

About CI, there are still much to say, but for SCM migration, I didn't see magic trick or disasters.

Q&As:

Specifically, how did you get the devs trained up?

They trained some people, at least one in each team. And then publish a guide document. When we trained them, we used the same strategy. Since SVN is not so complex as ClearCase, it's not a big deal. What is more important is the process, described as before. In another consulting project, we had some internal coaches. We had them coach each developer (tester) when they wanted to commit in code in the beginning period.

How are they finding the transition?

TW has high reputation. Since all TWers keep talking the benefit of atomic committing, optimistic locking, easy branching, some will try it and more will see it works.

What are the teething troubles of running SVN for that many people?

1. Log. Some (even some of ourselves) will challenge of the missed logs. I believe it will be a nightmare, if you try to import the history of each file to svn. So convince them, they are not that important, or just leave an approach for accessing the old logs.

2. Merging. People keep doing some wrong with SVN, especially merging two branches in hard way.

3. SVN is not perfect. Sometime people broke their branches. Let's say, it's just a folder in svn. Creating a new branch is often the easiest way to fix it. I had spend one day to fix a strange problem, and then some other SVN expert another day. At last, creating a new branch, spent only several minutes. Of course, since client pay us by time, it depends.

4. Cleaning. Jeff said enough about it.

5. Some kind of files need pessimistic, such as word document. Don't mess them up, or you will be sued.

6. Big binary file could not be put into svn if they get changed a lot. As an exception, putting the whole CI environment into SVN is a very good idea. As someone told, perforce is good at handling big binary files.

7. Authentications. I don't have much experience on it. In my projects, they use the simple access control model based on folder control.

8. Some may delete .svn file. Stop them.

9. Teach them to write comments in right format. Add a hook to svn, so that code can't be commited without comments.

How have you split the repos amongst teams etc?

In fact, we don't do much on this. But we see that, their SVN supporting team set up several Linux servers and run a instance on each sever. More than one project's code are hosted in one SVN instance. They create a folder for one project. And truck/branches/tag folders for one project are created as sub folders. In fact, I know some team set up their own svn server, which I think is the most scalable way:), only if they can make sure the data are safe.

Why not Hg or Git?

For me, I think the learning curve is steep. And for some reason, having a local repository on developers' computer is dangerous in some managers' mind. The third reason is that I still don't know how to host more than one projects in one Hg/Git instance.

A question, does anyone know how GitHub manage projects?

本文链接

Jez大作《持续交付》出版，中文版翻译中

2010-09-07T12:24:00Z

Jez （ThoughtWorker）的大作《Continuous Delivery》出版了。Martin Fowler（另一个ThoughtWorker）亲自作序，并纳入Martin签名系列。这本书的中文版正在由乔梁等人（包括我）翻译，中文出版估计要到明年了。

不过10月份的敏捷中国大会我会就这个话题做一个演讲。我讲的话题是：敏捷组织的持续交付之路。

见过很多公司搞持续集成搞不起来，不能说他没下决心，服务器架了，CC装了，轰轰烈烈地运行了一周。以后就放到那里供起来，专供领导参观使用。为啥？一不小心持续集成就失败了，还不好定位。

实际上，老马对这个问题早就有论述，放到那里没人看。大家都在做自己心里的那个持续集成。

在持续集成领域，我们经常会用到的一个术语就是“构建（Build）”。很多人认为“构建=编译+链接（Build=Compile+Link）”，Martin在第一版中指出一次成功构建包括：

所有最新代码从配置管理工具中取出（check out或者update）。
所有的代码从干净的状态开始编译。
将编译结果链接并部署，以备执行。
执行部署的应用并运行测试套。
如果上述所有操作没有任何错误，没有人工干预，并通过了所有测试，我们认为这才是一次成功的构建。

实际上，目前很多团队对成功持续集成构建的定义基本上是符合上述定义的。这个定义的特点在于它是相对独立的，它是一个从干净状态的源代码最终获得可运行的通过验证的软件的过程。
Martin在第二版中则在成功构建的基础上给出了成功集成的定义。成功集成关注的不是一次“编译+链接+部署+验证”的过程，而是从开发流程的角度介绍一次完整的在持续集成约束下的代码提交过程笔者对其格式略作处理，与原文稍有出入。：

将已集成的源代码复制一份到本地计算机。
修改产品代码和添加修改自动化测试。
在自己的计算机上启动一个自动化构建。
构建成功后，把别人的修改更新到我的工作拷贝中。
再重新做构建。
把修改提交到源码仓库。
在集成计算机上并基于主线的代码再做一次构建。
只有这次构建成功了，才说明改动被成功的集成了。

下图展示了Martin对成功集成的定义：

当然在第一版的“代码提交”这一节，Martin也提到了本地构建的概念，只是不如第二版这么明确。

我在大会上更详细地介绍一个案例。除了上面说的流程之外还包括：配置管理、环境管理、测试重组、组织结构调整等。讲义开完了会放到博客上来。

欢迎参加敏捷中国大会的同学来听我的主题。

本文链接

《面向模式的软件架构》第四卷“分布式计算模式语言”已经出版，收集反馈。

2010-05-04T15:00:00Z

《面向模式的软件架构》第四卷“分布式计算模式语言”已经出版，收集反馈。

http://www.china-pub.com/196747

本文链接

珍惜你的共鸣

2010-04-03T04:12:00Z

我们每天置身于信息的海洋，然而要将知识转换为自己的知识却并非易事。

[Posted with iBlogger from my iPhone]

本文链接

程序员的安全感

2010-03-12T14:39:00Z

做为咨询师，我们经常说要给程序员足够的安全感，让他们安心于写代码。但是，这种安全感不应该大到让他们忘记了自己的责任：写好的代码。有些责任必须让他们清楚，提交未通过本地构建的代码是严重的错误；配置管理和持续集成是团队中每个人的责任，而不是某个人的事情。
对于自己份内的事，不应当存在任何一种规则使其可以完全免责。参与者只有具备这种敬畏感才能保持思考的习惯。

[Posted with iBlogger from my iPhone]

本文链接