分类 未分类 下的文章

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

熟悉了多年的瀑布流程，一开始做敏捷，是被敏捷对需求的快速响应所吸引。互联网公司宣扬的快速迭代，已经深入人心。而敏捷所说的：需求在一开始并不明确也无法明确，在构思和开发多款新产品的过程中，也深感切肤之痛。
瀑布模型周期长，在一次需求确定之后，开发人员非常讨厌变更。而变更总是不可避免。所以，在正常开发流程之外，总是要附加另一个需求变更流程。在网上搜“华为需求变更管理流程”，你会找到一张长长的流程图，诸多的审批环节，这本身就说明需求变更是个多么讨厌的麻烦的事情，以至于要这么多环节去限制它。
而在流程不那么规范的公司——我相信这种公司应该是大多数的，毕竟象华为这样的公司还是少数——老板、总监、甚至销售人员，都能在开发过程中随意给提出几个需求要求开发人员去实现。即便是产品经理去建立一个需求变更流程也无济于事，毕竟一次开发需要半年到一年的时间，毕竟老板发现有新的很重要的需求总不能憋着不提。
那么需求为什么不能一开始就定清楚？这就是敏捷的核心之一，很多需求就是一开始定不清楚的。
那么敏捷怎么解决这个问题？快速迭代！
一次开发过程中的需求变更不是限制，在敏捷中是被禁止了。对需求的任何变更，都预先记录下来，然后放在下一次迭代前的需求评审中。每次迭代很快，一周到两周不等。
不过，在公司的实践中，要求每次迭代需求一点儿都不变，总没有那么绝对的事情，不过要好处理的多：对于一些文字的小修改，开发人员也并不在意，对于稍微大一些的修改，由于一次迭代速度快，放在下一个迭代中，对于公司老板和其他人员，一旦逐渐理解了敏捷，也是会接受的。并且迭代周期短，意味着提出的需求变更也不会太多了。
并且，在这个过程中，我会观察到一些有意思的事情。一开始的时候，一个迭代中忽然插入的需求——提出者往往是刚刚拜访客户回来的销售或者老板——会说这个需求如何的紧急、重要，势必加入开发不可。然后我把它放入下一期需要评审的重要需求中。等过了几天需要评审的时候，把这个需求拿出来和别的一对比，往往又觉得，其实没有那么紧急，也没有那么重要了。这种需求有时候一放就是好几个迭代都没有开发，甚至一直躺在需求池里面。敏捷的这种流程，还能让产品经理去重新审视需求的必要性，也能让提出需求的人“冷静一下”，更客观地和产品经理去评估需求。产品经理这时候也更容易去说服他们，把哪些不必要的需求推迟，即使那个人是老板——我知道，在很多公司，有很多产品经理都不知道怎么对付老板提出的古怪需求的，这或许就是其中的方式。

frisby.js是基于node.js和jasmine的自动化测试工具,可以很方便的测试服务器http get/post请求及其返回的json数据. 可以对json数据的类型和数值做判断.

首先需要安装node.js, 并且安装node.js的包管理器npm.

然后使用npm安装frisby和jasmine-node

npm install frisby -g npm install jasmine-node -g
进入frisby的安装目录. 我是win10, 是装在 C:\users\USERNAME\node_modules\frisby 下面的.
在这个目录里新建一个测试用例的目录, 例如建立一个 ceshi 目录. 目录结构是: C:\users\USERNAME\node_modules\frisby\ceshi
[注意] 特别坑爹的是, 这些目录结构不能任意改变. 既不能把frisby目录复制到别的地方使用, 也不能在别的地方创建测试用例的目录. 否则, 测试用例依赖的各种文件找不到, 运行的时候就会报错MODULE找不到.
在ceshi目录中建立一个js文件, 以 spec.js 结尾, 如建立一个test_spec.js 文件
输入如下内容
var frisby = require('../lib/frisby'); //全局设置 frisby.globalSetup({ request: { headers:{'content-type': 'application/json'} } }); frisby.create('登录get') .get('http://apis.baidu.com/apistore/mobilenumber/mobilenumber?phone=15210011578') .expectStatus(200) .expectJSONTypes({ status: Number }) .expectJSON({ status: 1 }) .toss();

在命令行, 进入 C:\users\USERNAME\node_modules\frisby 目录, 输入 jasmine-node ceshi 回车, 运行. 出现类似下面的结果. 说明测试没有通过.
C:\users\USERNAME\node_modules\frisby>jasmine-node ceshi undefined F Failures: 1) Frisby Test: baidu [ GET http://apis.baidu.com/apistore/mobilenumber/mobilenumber?phone=15210011578 ] Message: Error: Expected number '300202' to match number '0' on key 'errNum' Stacktrace: Error: Expected number '300202' to match number '0' on key 'errNum' at _jsonContains (C:\r\test\node_modules\.frisby.DELETE\lib\frisby.js:1271:17) at jasmine.Matchers.toContainJson (C:\r\test\node_modules\.frisby.DELETE\lib\frisby.js:1186:12) at null. (C:\r\test\node_modules\.frisby.DELETE\lib\frisby.js:717:24) at null. (C:\r\test\node_modules\.frisby.DELETE\lib\frisby.js:1074:43) at Timer.listOnTimeout (timers.js:93:15) Finished in 0.256 seconds 1 test, 3 assertions, 1 failure, 0 skipped

冬季，几十年不遇的北极涡旋寒流将至。早上熙熙攘攘的公交车站，人们裹得厚厚地挤在一起等车。一只老鼠，堂而皇之旁若无人地趴在站台旁东看西看，等车上班的人们和路人——包括我——除了给它让出直径五米的隔离区外，完全不知道该怎么办。若在老家，早就有人抄起板砖过街老鼠人人喊打了。而在繁华都市，你抄板砖追老鼠的狼狈无法保持城市人的优雅姿态，你百米冲刺十秒的速度无法穿越人流车流马路天桥，就算追到，你板砖落下光天化日血腥四溅血肉横飞路人和你都无法直视，况且砸不到老鼠砸到花花草草，砸不到花花草草砸到个奔驰宝马，砸不到奔驰宝马砸到路人甲是完全有可能的。那么，在人来人往的城市大街上看到一只不紧不慢的过街老鼠，有谁知道可以告诉我该怎么办呢？

  1. 1
  2. ...
  3. 67
  4. 68
  5. 69
  6. 70
  7. 71