• 1. 默默。逻辑思维方式。

    2. 梦头。在不见其增,日有所长有关咨询的一点事儿里面已经提到了

    3. Tin。今天晚上跟Tin说起对某人的一些负面印象,他在肯定了我的看法之后,又很认真的给我指出他身上有哪些优点是值得去学习的,之后又建议我去给他一些能够给他提供帮助的反馈。

    这些都很好,自己要想办法养成这样的习惯。

  • rojam是dreamhead同学做的一个用ruby代码操作java字节码的开源项目,项目具体内容因为跟本文主题无关,所以就不多描述了。我最近一段日子因为onbeach,所以就参和了进来。在开始读到rojam的代码之前,我原本以为自己还是会写一点ruby程序的,然后就被深深的打击了。。这里记录下来一些rojam中的metaprogramming技巧,并不是什么系统化的知识,只是自己的一点总结把。

    先看这段代码:

    class << self
           {
            :no_arg       => 1,
            :var          => 2,
            ......
          }.each do |type, size|
            class_eval %Q{
              def #{type}_instructions(*opcode, &block)
                instructions(#{size}, *opcode, &block)
              end
            }
          end
    ......
    end

    eval方法会将字符串作为ruby代码执行,它的变体有如下几种:class_eval, instance_eval, module_eval,分别用于其名字所表示的上下文。上面那段代码的含义就是,把block跟hash的each方法关联起来,当block被调用的时候,%Q{}所包含的部分就会被作为ruby代码执行,于是就有了

    def no_arg_instructions(*opcode, &block)
        instructions(1, *opcode, &block)
    end

    def var_instructions(*opcode, &block)
        instructions(2, *opcode, &block)
    end
    .......

    自然,这些方法是动态生成的。

    接下来再看这两个方法:

    def instructions(consumed_byte_size, *opcode, &block)
       opcode.each do |single_bytecode|
          define_method instruction_method_name(single_bytecode), &block
          consumed_byte_size_table[single_bytecode] = consumed_byte_size
       end
    end

    def instruction_method_name(instruction_code)
        "__#{instruction_code}__"
    end

    这行代码:define_method instruction_method_name(single_bytecode), &block,会把instruction_method_name(single_bytecode)所返回的字符串定义为方法,后面的block作为这个方法体的一部分。最终的结果就是为每一个opcode都定义了与opcode同名的方法。

  • 昨天听默默的讲座,清一色的头脑风暴,完事以后大家都感觉特累。

    在一个头脑风暴里,当时是要每个组都给四天的课程安排agenda,我们组的人讲完以后,dreamhead说:我其实特别关注你的思路,因为你现在不是跟客户讲,而是跟公司内部的人讲课程安排,所以思路就很重要,你是出于什么目的来这样安排课程,这样安排会带来什么样的好处,这些一开始就是需要讲清楚的。

    唔,其实何止是没讲清楚,我很怀疑大家有没有自己想清楚为什么要这样安排课程;当时team的人都是匆匆忙忙的往白板上贴纸条,后来我强调了一下,告诉大家别只顾着零零碎碎的贴,自己心里得有谱,有一条线索把你贴上去的这些东西能够串起来,自己能按照这些纸条把几天的课讲完。

    不过dreamhead的话还是让我感触很深,在服从习惯做这样那样的事情的时候,一定要多问自己几个问题:为什么要做这样的事情?它给自己或是别人带来什么样的好处?有没有更好的方式来做这件事情?比如我现在用blogbus的编辑器写博客,旁边dreamhead就在用文本文件写,写完以后再往上贴。

    以后要时时提醒自己,让自己做事更有效率一些。

  • 今天听@eaglexiao讲去某大型电信厂商那里作咨询,做CI的一些经验心得,然后大家又探讨了很久。

    下面是学到的一丁点东西:

    1. 团队内部的沟通。我们是作为一个整体去为客户提供服务的,所以要有一致的声音,任何一点微不足道的分歧,在单独面对客户的时候都有可能给人产生不靠谱的印象。所以当我们在内部表达观点的时候,应当要努力坚持,直到被说服为止,而不是被简单的否定。不然就没有很主动的心态去说服客户也接收这个观点。

    2. 知识的系统体系。上个月老大在office update的时候也讲到了小强的故事,说他每天晚上都要狂补CI、配置管理的知识,今天听@eaglexiao和dreamhead也是说同样的观点,很多知识也许在我们看来是common sense,但是客户不一定,甚至就是不这么以为。那么要说服客户,抛开沟通技巧、演讲技巧之类的软性因素不谈,自己和团队必须得建立完善的知识体系结构──至少在自己所擅长,所要为客户提供价值的领域内。这样自己心里有谱,客户也会觉得你比较专业。

    3. 不要用自己的知识面去套客户所面对的问题。这还是锤子和钉子的典故了,一旦有了心理暗示,就容易忽略掉其他证据。要多听,多调查。

    4. 多探究问题的本质。客户暴露给我们的问题、要我们去解决的问题可能只是表面现象,我们得追求它的成因,这才是能够更好提供价值的地方。

    5. 不一定客户问什么,我们就得回答什么。那句话实际上是前面那条的引申,这是在@eaglexiao陈列客户问题的时候,dreamhead提出来的。当时列出来的问题有:单元测试应该有多大的覆盖率?测试代码跟产品代码的比例应该是多少?dreamhead就说,你不一定就非得给客户把这些问题回答出来,你可以问他,你问这些问题的目的是什么?这背后可能就隐藏着一堆问题是需要解决的。如果你告诉客户,测试代码跟产品代码的比例在0.8~1.5之间,这种答案对他有意义么?没有。也许你问他以后,他可能会回答你,他要用这个数据去做评估,那么你就继续问,为什么要用这种数据作评估,然后顺藤摸瓜找出流程的问题来。这样一来就可以找到让我们价值最大化的地方了。

  • 首先是装mysql,参见http://2tbsp.com/content/install_and_configure_mysql_5_macports

    1. installation

    sudo port install mysql5 +server

    2. create databases

    sudo /opt/local/lib/mysql5/bin/mysql_install_db --user=mysql

    3. start mysql

    sudo /opt/local/share/mysql5/mysql/mysql.server start

    or

    alias mysqlstart='sudo /opt/local/bin/mysqld_safe5

    4. stop mysql

    /opt/local/bin/mysqladmin5 -u root -p shutdown

    然后就是装mysql的adapter,这里因为是用macports装的mysql,所以会装到/opt/local下面去,跟默认的/usr/local/mysql不同,用gem装就行不通了,参考官网说明:http://www.tmtm.org/en/mysql/ruby/,这里只需要把第一步的参数修改一下:

    ruby extconf.rb --with-mysql-lib=/opt/local/lib/mysql5/mysql/ --with-mysql-include=/opt/local/include/mysql5/mysql/

    然后再一步步走下去就好了。

  •       1、我们要不要孩子?如果要,主要由谁负责?
      2、我们的赚钱能力及目标是什么?消费观及储蓄观会不会发生冲突?
      3、我们的家庭如何维持?由谁来掌握可能出现的风险?
      4、我们有没有详尽地交换过双方的疾病史?包括精神上的。
      5、我们父母的态度有没有达到我们的预期?会不会给足够的祝福?如果没有,我们如何面对?
      6、我们有没有自然、坦诚地说出自己的性需求、性的偏好及恐惧?
      7、卧室能放电视机吗?
      8、我们真的能倾听对方诉说,并公平对待对方的想法和抱怨吗?
      9、我们清晰地了解对方的精神需求及信仰吗?我们讨论过孩子将来的教育模式和信仰问题吗?
      10、我们喜欢并尊重对方的朋友吗?
      11、我们能不能看重并尊敬对方的父母?我们有没考虑到父母可能会干涉我们的关系?
      12、我的家族最让你心烦的事情是什么?
      13、我们永远不会因为婚姻放弃的东西是什么?
      14、如果我们中的一人需要离开其家族所在地陪同另一人到外地工作,做得到吗?
      15、我们是不是充满信心面对任何挑战使婚姻一直往前走?

  • 三年前,收到了jessie的拒信。

    那个时候,我对TW的认识还仅限于gigix博客上的只言片语;那个时候我不知道重构;那个时候我还没有学会独立思考,更不要谈反思总结;我甚至只能看懂TW中国站点上的汉字,英文资料就大部分靠蒙了。

    两个月前,我离职了。

    两个月的时间里,一次次尝试,一次次碰壁,自傲、自卑,对自己的定位不停被推翻重来。压力一点一滴的增加,友情、爱情、亲情、人性,都有了新的感悟。开始彻底放下自己,去找一个能够暂时落脚的地方。

    后来,终于拿到了Offer。

    一个星期前,看到了姚明的一个纪录片。

    在他刚刚赶赴NBA的时候,他说,我要面对的是一个全新的世界,所以不管从前有过什么样的成绩,我都不会再记在心里,我只管自己的目标,然后向着这个目标努力。

    然后,又看到了湖南卫视的一呼百应。在这个节目中,他们把歌手投放到陌生的城市,让他们设定好一个挑战目标,也就是能来听演唱会的人数,宣传时间只有100分钟。歌手上台的时候带着眼罩和耳机,然后主持人让他们摘下耳机对观众问候,自然,观众已经被提前关照过不要鼓掌不要欢呼,在黑暗中听不到反应,恐慌便在心中蔓延。有的人泪流满面,情绪失控;有的人依然保持镇定,面带微笑。

    太在乎就会怕失去,太年轻…太年轻了会有很多问题…

    我不要再犯同样的错。

    从明天起,做一个幸福的人

    喂马,劈柴,周游世界

    从明天起,关心粮食和蔬菜

    我有一所房子,面向大海,春暖花开

    谢谢朋友们一直以来的关心和帮助,谢谢妻子的鞭策支持和爱护,谢谢妈妈照看着这个家庭,谢谢女儿,为我带来了无限的欢乐。

  • 1. svnadmin create /home/jacky/repository/test (Note that this directory should be accessable by accounts other than root)

    2. svnserve -d --listen-port 8099 -r /home/jacky/repository

    3. vim svnserve.conf

    anon-access=none

    auth-access=write

    password-db=passwd

    4. vim passwd

    test=test

    5. vim authz

    [/]

    test=test

    6. cd /$cchome/projects, mkdir test, cd test, svn co svn://localhost:8099/test .

    7. edit /$cchome/config.xml, add "test" project

    8. commit something to svn://localhost:8099/test, and force build on cc

  • 1. make sure that JDK installed and JAVA_HOME configured.

    2. sudo vim cruisecontrol.sh, modify webport

    3. replace config.xml

    4. remove useless project under /logs and /projects

    5. cd /projects, mkdir marsrover

    6. cd /marsrover, run svn checkout http://marsrover.googlecode.com/svn/trunk/ . (don't miss .)

    7. start cruise.

    See the config.xml below:

    <cruisecontrol>

        <project name="marsrover">     <!-- should be the same as the project directory name-->
        <!-- NOTE: if you want to force build even if no code modifications detected, you can add requiremodification="false" to the project attributes -->
        <!--
        there are some different scenerios -
        http://confluence.public.thoughtworks.org/display/CC/CruiseControl+Scheduling+Scenarios
        -->
            <listeners>
            <!-- listening for status change, such as waiting for build, queued, building, etc. Normally we won't change this configuration -->
                <currentbuildstatuslistener file="logs/${project.name}/status.txt"/>
            </listeners>
           
            <!-- NOTE: CC doesn't support check out the code on the first time, so you should check out code to the project directory first.-->
            <!-- NOTE: if you're using https to update code, then the code should checked out firstly with command line, and accept certification permanently-->
            <bootstrappers>
            <!-- this element is used to checkout code, we use svn here, localWorkingCopy is used to check out code to local file system-->
                <svnbootstrapper localWorkingCopy="projects/${project.name}"/>
            </bootstrappers>

            <modificationset quietperiod="30">
            <!--if the code changed, and there are no checkins within quietperiod seconds, the cc will check out code from the repository-->
                 <svn localWorkingCopy="projects/${project.name}"/>
                 <!-- here we do a forced nightly build, it will create a faked modification on 11pm,
                        then it needn't <project requiremodification="false"> -->
                 <timebuild time="2300"/>
            </modificationset>

            <schedule interval="300">
            <!-- do CI during the day, every 5 minutes-->
            <!-- cc will launch a build every interval seconds, here we uses ant with the specified build file-->
            <!-- NOTE: user can also specify time attribute to ant, such as <ant time="2300"> means build on 23:00-->
                <ant anthome="apache-ant-1.7.0" buildfile="projects/${project.name}/build.xml"/>
            </schedule>

            <log>
            <!-- save log file, the file will be saved under logs/${project.name} by default-->
                <merge dir="projects/${project.name}/target/junit-test-report"/> <!-- merge the build result -->
                <!-- if we want to see the just test result in cc, the junit result should be located under the same directory as described above -->
                <merge file="projects/${project.name}/target/checkstyle_report.xml"/>
                <!-- to show the checkstyle result on the cc page, we should edit /webapps/cruisecontrol/main.jsp, and uncomment the lines below:
                <cruisecontrol:tabrow/>
                <cruisecontrol:tab name="checkstyle" label="CheckStyle">
                  <%@ include file="checkstyle.jsp" %>
                </cruisecontrol:tab>
                -->
            </log>

            <publishers>
            <!-- publish the build result to the specified location, there are many plugins in cc to do all kinds of publishing, such as send out
                email, call the specified page using http, play music, etc. -->
                <onsuccess>
                <!-- specify what will be published when build succeeded-->
                    <artifactspublisher dest="artifacts/${project.name}" file="projects/${project.name}/${project.name}.jar"/>
                    <!-- in the element above, we must make sure that the built jar file should be exactly named as ${project.name}.jar-->
                </onsuccess>
    <!-- NOTE: if you want cruisecontrol to report a test failure as a build failure, you need to make Ant report the test failure as a failure. just like this:

    <junit fork="true" haltonfailure="false"  failureproperty="junit_test_failed" printsummary="on">
    </junit>
    <fail if="junit_test_failed" message="One or more JUnit  tests failed"/>

    see: http://confluence.public.thoughtworks.org/display/CC/FailOnTestFailure
    -->
                <htmlemail mailhost="smtp.gmail.com" mailport="465" usessl="true" username="xxx@gmail.com" password="xxx" reportsuccess="always" returnaddress="build@xxx.com" subjectprefix="xxx build logs">
                    <always address="xxx@gmail.com" />
                </htmlemail>           

            </publishers>
        </project>
    </cruisecontrol>

  • sudo mount.vboxsf sharedfoldername tobemountedlocation

  • 大会的累都是自己给自己找的,既没有安下心来听演讲,又不去跟人深入交流。下次递名片可以更主动一些,虽然已经有了进步,但还需提升。

    主持的时候到最后紧张的厉害,演讲稿中间不甚吸引人。

    大会第二天下午的爆满,也许是因为互联网行业的神秘感,也可能是大家更愿意听实践经验。

    但也许也跟理解层次有关系?大家都没有达到理解抽象层侧的level?想InfoQ总站的调查,中文站的读者,更喜欢跟工具、具体实践有关的内容,而不是Thinking。

    不过也有可能跟大师们的演讲方式有关系,也许他们该讲述的是如何从实到虚,从具体到抽象的思考过程。这样听众能更好理解。

    见到了林昊、王速瑜、于晶纯、周爱民、高焕堂、Henrik、Rod、Randy……跟Floyd和MF是第二次见面了。Floyd还赞扬了我的贡献。哈哈,很高兴。

    有人找我签名,有人找我合影,低调、低调。

    潘加宇的讲座很实际,因为他以咨询生存,有明确的目标,所以演讲中边字字谈钱谈利益。架构就是为了钱而架构,设计是为了钱而设计。纯粹的在思考方式上进行洗脑。这是不是偏执狂的生存之道?有人说,现在UML的创始人都不谈UML了,只要说起UML来,就会想起潘加宇……

  • 1. 这次国外嘉宾一共三个光头:MF、Randy、Rod,开场前一天带他们打车,一共两辆车,怕后车跟丢,就跟司机说,跟着前面车后座上那个光头就好了。车上的老外也跟着嚷:Follow the light, Follow the light!

    2. MF那场讲座很惊险,我看时间还有二十分钟才结束,就跑出去吃吃喝喝了,正吃得开心,x5跑过来喊,快点,他快结束了,你得串场了。然后我就跟着跑,直到跑到VIP会议室,手里的西瓜皮和面包袋也没找到扔的地方,x5英勇的伸出手掌说,你就放我手上吧!

    3. Henrik那场也很惊险,本来我是没有看到他的ppt,就想听听讲座再准备采访提纲,听到一大半,忽然想到第三场的讲师阿朱我根本就没见过面!!连忙拔腿飞奔,找到泰稳要了阿朱的电话……

    4. 多背一公斤也在会场,10元钱捐一本书给野三坡的孩子,有人从我这里借钱买书,我忘了他是谁了……

    5. 默默第二天中午的时候也要支持多背一公斤,从裤兜里掏了半天,掏出四张一元的大钞来。

    6. 有人在自助酒会上四处拉人合影,冲过去先问,你好,我能跟你合影么?如果答曰能,他就往旁边一坐,自己拿着相机就pia~的一张,我哭笑不得:大哥,你让别人帮你对一下镜头好不,照半张脸好看么。

    7. 9号散场的时候,我把所有背包里面剩下的planning poker全搜罗起来了,除去被半路劫持的,还剩11副,可以让44个人一起做计划……

    8. 庆功会上,我跟tomgaoang、小熊、jason四个人玩棒子老虎鸡,输三次喝一杯,后来发展到输了三次的去敬霍霍一杯,霍霍拍着胸脯说,你们谁 输了的就来找我喝,我要是被你们灌趴下我就不姓霍!然后我跟jason就用冰绿茶跟他喝(只喝了一杯)。他还嫌我们杯子不满,给添了点酒。不过他还是站着回去的,就是回家以后吐趴下了。

    9. 大会当天我穿的是T恤牛仔裤,转眼见到vision wang西装革履,大为惊骇,问道,你怎么穿这个?不热么?vision答道,霍霍跟我说要穿正装的。我大怒,靠!霍霍咋没通知我?然后,大会开场,霍霍跟Floyd穿着QCon的T恤就上去了……

    10. 有人要跟MF合影,MF不同意,旁边有人说,你是不是要收钱才跟人合影啊?MF大怒!旁听者大汗!瀑布汗!冷岑岑汗!核弹爆炸汗!然后后面的人统统都没有签名和合影了……

  • 亲爱的各位兄弟姐妹,欢迎大家来到QCon全球开发者大会敏捷分会场,我是主持人李剑。

    今天这个分会场的标题让我想起一个笑话,高速公路 上左右各有几条标语,左边“在建设有中国特色社会主义的道路上奋勇前进”,右边“限速60公里”。左边“高举***理论伟大旗帜”,右边“限高2.4米 ”。敏捷也在路上,那么在这条路上有过哪些囧人囧事,这是一条什么样的路?这条路又通向什么地方呢?

    李世民同学曾经说过,“以史为鉴,可 以知兴衰”,从2001年敏捷宣言诞生开始,到今天,已经是第八个年头了。虽然说,这八年间发生的一幕一幕,没法在十几分钟内一一重现,但至少我们可以回 头看上那么一眼,看看从去年这个七年之痒的日子开始,发生过哪些或是精彩、或是喧嚣的事件,是值得我们深思的。

    今年年初,有人做了个Scrum在中国的调查,采访了国内一些实施Scrum的公司,然后发现不少公司就是听说敏捷这个东西很好,Scrum这个东西很 好,然后就开始搞,然后搞烂了,有几个公司是真正的从公司现有的问题出发,寻找解决方案,就做的很不错。写这个调查报告的人恰好是我。

    然后呢,又有人翻译了一本迷你书,叫硝烟中的Scrum和XP,就有那么几个公司,看了书以后觉得我靠,Scrum这玩意真简单啊,照猫画虎着来,然后又死翘翘了,不过也有不少企业,用它当个入门指南,然后不断回顾,结合企业现状进行调整。翻译这本书的人碰巧也是我^_^

    从 去年夏天起,国内外敏捷社区中对Scrum认证的反对的声音就越来越强烈,大家纷纷质疑,花几千块钱,听两天课,拿一个证,到底有什么意义。除了能够说明 你花钱参加了两天的课以外,还有没有别的用途。然后一波未平一波又起,最近又蹦出来一个组织,名字起的很是彪炳千古啊,叫做“世界敏捷资格委员会”,要搞 敏捷开发者认证和敏捷测试人员认证,也遭到强烈抨击。

    有人声称,敏捷正在衰落,因为他看到许多团队、许多人都在做买椟还珠的买卖,选了Scrum中最容易上手的实践用起来,把那些可以产出高质量软件的技术实践置之不理。然后有人说,这跟Scrum和XP没有关系,因为再好的流程,再好的实践,也得看用它的人有没有大脑。

    有人搞了个太极敏捷派,说是文化决定管理,管理决定技术,因此太极敏捷认为只有具有先进文化的团队和企业,才能实现真正的敏捷变革,并从中获益。然后有人引用温瑞安的话回复说:“你的话既不可能错,也没有分明的对,根本无对错可言,只听了让人心里舒服,所以是废话。

    Bob 大叔在博客上提议敏捷宣言上应当增加第五项价值:精益求精胜过按部就班。o6z在图灵俱乐部里面说,个人能力才是关键,不然团队啊协作啊就都只是空谈。再 接下来,软件工匠讨论组推出了软件工艺宣言。宣言声称:作为胸怀大志的软件工匠,我们在亲身实践专业化软件开发,也在帮助他人掌握这一匠艺,我们要设立更 高的目标。

    把上面这些事情整理一下脉络,就会发现他们基本上有着一条很明朗的主线,也就是大家越来越清楚的意识到,哪些做法哪些说法是不靠谱的,如何能够做到靠谱。

    假如,我们能够有一个统一的认识:我们需要为客户交付高质量的软件,能够适应客户不断变化的需求,在成本和收益之间达到最佳的平衡,让客户收获最大的投资回报;那么通向这个目标的路,便是我们迤逦而行的路。敏捷,只是行路的手段。

    所 以,这是一条实事求是的路,按照唯物主义认识论的说法,我们是先要认识世界,然后再去改造世界。换句话说,是先认识到问题所在,然后对症下药量体裁衣去解 决问题;所以,我们要仔细想想,我们做过程改进,做敏捷实施……这些事情的目的是什么?为了达到这样的目的,我们做了哪些工作?在所做的工作中,哪些事情 有助于达成我们的目的,哪些事情事倍功半,哪些事情南辕北辙?为什么会有这样的情况出现?下一步又该怎么走?

    这又是一条理性的 路,Scrum认证,有人热捧,有人唱衰;有的人觉得敏捷实施需要面面俱到,有的人就认为这代表着敏捷学家的衰落;纷纷扰扰,是是非非,有人就有恩怨,有 恩怨就有江湖,我们能不能看清这纷争背后的真相,不被它迷了双眼?桃花扇中唱,“眼看他起高楼,眼看他宴宾客,眼看他楼塌了”,我们且只管做自己该做的事 情,过上几年,再来看这江山,必定又是另一番容颜。

    这更是一条务实的路,我有位朋友曾经说过:“没有实践经验就不要扯那些看上去很美实际 上狗屁不通的淡”,客户也好,公司内部也罢,要的都是真正能干活花了银子见成效的东西,花言巧语、巧舌如簧,也许能蒙蔽一时,但也要小心跟CCTV一样, 躲得过初一,躲不过十五。同样是敏捷咨询,有的舌灿莲花高坐厅堂,有的卷起袖子下厨房,哪一种更能带来实际成效?结果很是显而易见。

    这也 是一条追求卓越的路,因为从提供专业服务的角度来讲,我们理应抓住每一点可以做出改进的机会,可以消除一点一滴明显或者不明显的浪费的机会,可以提升个人 与团队生产效率的机会。所以我们要不断在回顾中做改进,我们要精益求精,我们曾经为了一段程序的优化埋头书海衣带渐宽,我们有过在客户现场没日没夜加班的 辛劳,我们有过每周工作60个小时、80个小时的日子,我们注视着别人的背影成长,然后,不经意间,也成了别人眼中的风景。

    希望在座的每一位朋友,都可以在这条路上走的更远,走的更稳。

    谢谢大家。

  • anchuan Scrum认证测试,主要是考察敏捷项目管理的知识。ScrumMaster真正需要的是敏捷项目实施的能力,而不是知识。敏捷项目管理的知识,找几篇文章,找几本书读一下就可以了。

    vincentxu @anchuan agreed, it's just like sex, even though you've lots of knowledge, you still mess it up without real experience.

    vincentxu @JackyLiJian @anchuan another thing is ppl always over estimate the difficult to gain knowledge, which is really cheap nowadays. And more saddly most of ppl think knowledge == capability