Jacques-YQ 发布的文章

最高昂的成本是什么？做沟通和做决策。眼红的决定是追高、跟风或恐惧时候做的决定。

看雅虎收购Flickr后，Flickr85%的时间再和雅虎做沟通，一项决定层层审批；而只有15%的时间在做产品，创业明星Flickr就此消失；另外雅虎当年看不起、后来买不起谷歌，匆忙收了技术并不咋样的Overtune，却没有做成。

做创业需要降低高昂的成本，就要减少决策，要有能力的人往前冲；就要当面沟通，办公租金成本和交通成本可能是低于远程沟通的时间成本。如果试错速度足够快，那么多试错好过多决策。

然后不能去跟风去追，除非你能有更便宜更好的东西。

创造需要激情和感性，需要独断专行，理性得有别太多，沟通决策太理性，不需要做就别做，必须要做就快做。

1. 搜索并替换
sed /要操作的行包含的内容/s/搜索内容/替换内容/g
s代表搜索并替换，/g代表搜索并替换所有
搜索内容和替换内容可以使用正则表达式
s/xx/xxx/g可以用“”括起来， 但用引号括起来有时候会产生问题；

如：

echo "!  asdf" | sed s/a/b/g

输出：!  bsdf
2. 删除包含指定内容的行
sed /要操作的行包含的内容/d
3. 删除不包含指定内容的行
sed /要操作的行包含的内容/!d
！表示否
注意， 感叹号有时候会被错误识别，这时候用\!代替

mac上不像windows上有tortoiseSVN的图形界面, 还蛮好用. 我们的UI设计师用MAC要上传UI切图, 在MAC上苦于找不到好用的上传工具. 我就给她写了个svn脚本, 双击上传, 好用得不要不要的.

如下, 实现增加所有文件, 删除所有不存在的文件, 并上传文件. 如果需要更新的话, 把后面两句注释掉的去掉就可以了.

脚本第三行, 进入目录, 需要替换为自己实际的目录.

#! /bin/sh
echo '进入工作目录'
cd /users/apple/Desktop/UISVN/trunk
echo '增加所有新的文件'
svn add * --force
echo '删除所有不存在的文件'
svn rm $( svn status | sed -e '/^!/!d' -e 's/^!//' -e 's/$/@/g')
echo 'commit上传文件'
svn commit -m "add by me"
: echo 'update 更新'
: svn update

上述代码保存为.sh文件, 如"svn_upload.sh", 在mac上使用终端打开运行即可. 以后鼠标双击就行了.

linux上, chmod 777 这个文件, 改为可运行, linux控们都懂得. 如:

chmod 777 svn_upload.sh

--------------------------

有的亲不知道svn怎么从头开始取文件? 创建一个存储SVN文件的目录, 用下面的命令就可以了.

svn checkout URL地址

 

时而缥缈不定，时而遮天蔽日，时而有，时而无。

时而重重叠叠，时而淡淡轻轻，时而黑，时而白。

云之变，变之易，揣测实难。

概莫如心境，阴阴郁郁，几时放晴？概莫如生计，忙忙碌碌，几时得闲？概莫如人欲，纷纷扰扰，几时方休？概莫如世界，来来去去，几时消停？

人之变，变之易，揣测实难。

标题党: 产品做不好的原因竟然是这个！

好的产品，精确，智慧，而又人性，说白了就是智商高情商也高。

做好的和不好的产品都需要两样东西:人和机器(计算机)。

然而人与机器相比，健忘，爱出错，运算慢，思考慢，交流充满误解，一句话，笨。

机器与人相比，精确，理智，然而一根筋，情商为零。一句话，轴。

做好产品，就是把这么两种又笨又轴的玩意儿弄一块，做出来又聪明又体贴的产品。所以才这么难。

更难的是，产品经理也是这个笨物种中的一员。

最近发现自己愈发有些焦虑, 焦虑起来的时候就做个低头族, 埋头在手机里面看一些可有可无的东西.以前可能不怎么长期焦虑, 现在一焦虑, 倒是焦虑出来一些心得.

作为神经症的一大病症, 全球终身患病率是13.6%, 大约相当于每七个人里面就有一个人终身焦虑(数据来源于百度焦虑症吧).不说终身的话, 可能每个人都有过或重或轻的焦虑. 现代城市人焦虑症又会更重一层.

不记得是谁曾经说过, 有一点焦虑有助于生存, 就跟痛觉一样.另外我认为焦虑症可能像其他的身体类疾病一样, 可以作为癔症的一种表现形式. 就像极度渴望休息就会生病, 极度渴望怀孕就会假孕一样.

拿咱们的社会现实来说, 周围的生活工作环境中的人群,会给自己一些直接间接的压力和期待, 这些压力和期待又往往长远而脱离实际，超出能力。于是自己就焦虑了，一直焦虑到周围的人感觉不能再给他压力为止。这个时候，虽然焦虑是一种痛苦的状态，并且自我的能力无法通过解决现实问题的方式消除焦虑，于是就不再想要消除焦虑，而是把自己压抑在焦虑的病态中，以解除四周的压力，长期形成像慢性病一样的习惯性焦虑。

焦虑的人无法停止思考和幻想，认为停止下来就是不够努力，会有愧于期待，会使压力卷土重来。于是，手机是一种很好的解脱。手机产生无休止的信息，让大脑一直处在忙碌状态，让自己认为至少在做事情，去抵御愧疚感。

如此说来，极大的压力和期待导致了无力感，无力感导致必须时刻要做些什么的忙碌感，停下来就会导致愧疚感。这就是焦虑的过程之一种。

编程、工作与生活一样，真正有价值的道理简单而朴素，我们在一开始就已经知道，但从来不去好好遵守它。

这些天一直在看和实践敏捷开发，2005年以后，还没有再看过源代码了，现在又在看，并帮助工程师们提高。这个过程中就发现，工程师们对一些编程基本原则的反应是“太理想化”，“确实应该是那样的，但实际因为种种问题是不可能完全做到的”，这些原则“可能并没有那么重要”……

什么原则呢？比如代码应该有高可读性，比如变量命名应该遵循统一原则（驼峰或下划线），比如应该写充足的注释，比如应该做到逻辑代码与界面的 分离（MVC/MVVM）……为了说服大家，我不得不买上几本经典书，把《代码大全》里面的一段章节翻出来给他们看。

然而，这可能并不能起到立竿见影的效果。人们总是知道道理，却却在实践中大打折扣。

在《程序员修炼之道》的中文序言《程序员心里的小声音》中，指出了这种现象，以编程DRY（Don't repeat youself）原则举例，指出“能不能用正确的原则知道正确的行动本身，其实就是区分是否是高手的一个显著标志”。

我觉得这种现象可以称之为编程界的“人格分裂”，知道什么是正确的但不去做或不好好做。

我们每个人或多或少都有些这方面的分裂。全世界人类或多或少都有这方面的分裂。什么原因？对人来说，知道并不等于懂得，特别是实践欠缺，还没有踩到足够的坑来说明不遵循会产生多少问题。

对我国人来说，国民教育环境也促使了这种分裂。思想品德课本上的道理讲着诚实守信，哲学课本讲着全面和联系的观点，历史课本上却讲着和谐过的抗日战争。国家人格分裂，我们每一个人自然而然也跟着一起分裂了。

有什么好的方法治疗？世界上没有银弹，那么路只有三个：一个是按正确的道理办事；一个等自己踩了足够多的坑后再去领悟，“不到黄河心不死，不见棺材不掉泪”嘛；最后一个是，到了黄河也不死心——彻底没救了。

前两天看新闻，真的有这个地方，真在中国，真的焚尸炉。就这个月开业，开业日期是清明节。这就是上海的4d死亡体验馆。

写遗嘱，进棺材，遗体告个别，然后丢进焚尸炉。哦，叫火化炉好了，焚尸的感觉好像对我们自己的尸体不够尊重一样。

据说还不少人，想“死”还得排个队。不过中国现实更有趣，那个放盒子的地儿太贵，可能还死不起。

开设的体验馆的人有心理学背景，焚尸哦不对火化完之后还安排了投胎转世的重生环节，把体验者的心理重新拉回人世。

这家体验馆正式名称是4d死亡体验馆，不少媒体报道时变成了生死体验馆或者生命体验馆，这或许就是人对死亡有意无意的回避态度。

不知怎么，一讲到生死，我想到了两个哲学命题，一个是加缪的西西弗斯，一个是叔本华的钟摆。前一个每天推石头上山，石头石头推到顶又滚下来，因为太无聊也毫无意义，西西弗斯变着花样推，每天都给自己找点儿乐子。后一个说，人生满足了就无聊，无聊了就没事找事，找到事了就痛苦，一辈子这两种状态，像钟摆一样摆来摆去，不是在去无聊的路上，就是在去痛苦的路上。一个是瞎乐观的无聊，一个是穷悲观的无聊。这就是没事找事的人生。

这里一篇文章http://developer.51cto.com/art/200906/129424.htm

不过蛮啰嗦的，写了那么长……

rest就是要无状态，sessionid就是要保存状态，当然就不restful了。需要在每次请求都发送认证信息，才可以restful。

为什么要无状态？这样每次请求可以独立测试啊。

别的好处自然是，服务器很容易做分流了，服务器之间也解耦了。

今天去听了一个干货满满的讲座, 解答了我的一些敏捷的疑问, 也更加确定了我以前的一些想法和做法.

这次由leangoo和scrum中文网组织的讲座, 主讲人是廖靖斌, <<Scrum敏捷软件开发>>的第一译者, 也为很多公司做过内训, 经验丰富.

按讲演的顺序谈谈体会:

一. 敏捷思维

这个包括三部分:

* 价值驱动. 这一点就是要交付, 并且尽快交付有价值的东西. 这次的更深体会是, 一切有价值的需求都是驱动力, 不只是产品, 还包括技术需求, 测试, 重构, 改BUG, 甚至撰写文档.提到一个Zappos的典型案例.

* 适应变化. 这个主要是快速迭代了. 大家并不陌生.  内涵包括频繁交付, 频繁确认, 频繁交付正确成果. 后面两点, 是需要自动化测试, 持续集成保证的了.

* 自组织团队. 这个以前并不够关注, 也没有足够的方法. 这里面提到, 将用户与团队直接对接的重要性, 举了小米的例子, 要求开发团队每天要泡45分钟论坛. 目的是对用户的使用情况有直观的感受.

讲到从契约模式到共享责任这一点, 我们猫宁团队目前还在很努力的去探索. "一荣俱荣, 一损俱损"的方式.

二. SCRUM框架和流程

包括三个角色: PO, SM, 开发团队, 大家一条船, 又是讲前面的 "一荣俱荣, 一损俱损".

三个工作: 产品Backlog, sprint backlog, 燃尽图.

里面比较有感受的是四个会议+1, 分别说一下:

* +1 的会议, 是需求准备的会议, 在开Sprint计划会议之前几天, 提前将准备好的需求,UI,UX等, 与开发沟通清楚. 不清楚的需求补充好, 或者不在此次开发.

* Sprint计划会议. 对应我们猫宁团队, 就是每次迭代前的需求讲解, 用户故事划分为任务,  然而又有几个重要不同: a. 计划会议大约2~4小时, 需要在会上确定前后台接口, 将用户故事划分为任务, 按优先级依次排列用户故事. 但不去确定谁来开发.

* 每日站会. 15分钟内. 这个会议上才去确定谁去做哪个任务. 非常重要的一点是.A. 大家要按优先级去做用户故事. B. 大家要做同一个用户故事, 交付后才能一起做下一个故事 C. 大家自己领取任务, 做完了再继续领取别的任务. 哦, 可是我做IOS不会Java后台啊... 这里提出了要去学习其他的能力, 帮助其他人做事情, 从简单的文档, 测试等开始做起.

* Sprint评审会议. 这个目前我们没有做. 举了个例子, 某个北京的公司 , 周五下午, 老板什么也不做, 就是看各个scrum团队讲这次迭代开发的内容. 全公司其他人有兴趣的都可以参加, 包括市场, 销售等.团队要解答参加者提出的问题. 评审前, 要将产品发布到预发布环境中, 也就是上线前的测试环境.

* Sprint回顾会议. 团队内进行的查漏补缺. 在下一次Sprint时候改进. 这一个我们目前也做的不够.

三. 用户故事地图

我们之前用的是需求池, 感觉结构上类似. 用户故事地图更好的地方在于, 横向上再次用用户角色进行划分(不同泳道), 并且将用户的业务流程从上到下依次排列. 业务下面再划分用户故事. 其他纵向的按Sprint划分, 与我们现在按版本划分差不多.

四. 其他

* 可视化协作. 看板放在一个人人都能随时看到的地方非常重要, 对所有人都有很好的督促作用. 所以他建议买一个大电视一直用来放看板. 而且也确实有公司这么去实践了.

* 自动化. 自动化是解决技术债务的唯一方式了. 把那些无聊的重复的工作都自动化了吧! 不用再有疑问了.

* 文档. 目前出现的接口文档和实际接口不一致的问题. 那么把文档也作为验收标准, 作为需求的一部分吧!

Powermockito对java代码可以进行静态方法的Mock. 用于junit单元测试, 但由于依赖问题, 在运行Junit时候, 会遇到Initialization error
一般见于Powermockito <1.6.1的版本和Junit<4.12的版本.
解决方法: maven中修改依赖为:

<dependency>
  <groupId>org.powermock</groupId>
  <artifactId>powermock-api-mockito</artifactId>
  <version>1.6.1</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.powermock</groupId>
  <artifactId>powermock-module-junit4</artifactId>
  <version>1.6.1</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.12</version>
  <scope>test</scope>
</dependency>

即可

参考:

http://stackoverflow.com/questions/26192929/unable-to-run-junit-test-with-powermockrunner

  1. 1
  2. ...
  3. 69
  4. 70
  5. 71
  6. 72
  7. 73
  8. 74