“提交”
只有提交会导致服务器上发生变化

“更新”

更新操作只是把服务器上最新版本下载到客户端，规则如下：
1、如果你本地的某个文件没有修改过，而服务器上的这个文件别人已经提交过新版本，那么会用服务器上最新的文件覆盖你本地的文件；
2、如果你本地的某个文件你修改过了还没有提交，服务器端的这个文件还没被别人改过，那么对你本地的这个文件没有任何影响；
3、如果你本地的某个文件你修改过了还没有提交，服务器端的这个文件已经被别人改过，那么会提示你发生冲突，会将服务器上最新版文件、你新修改的文件、发生分歧前的那个版本的文件都存放到你的本地

“update to version”
更新到指定版本

SVN的经常性使用步骤：

Ctrl + H
.NET下面我最喜欢使用的操作了。特点是有些慢，但使用起来方便。查找代码中的名称会经常使用

Ctrl + F
用于文件内查找，类似当前文件的查找功能

public class FirstCode{
public static void main(String[] args) {
System.out.print(“Hello word”);
}

}

从代码层面上回归到业务上。现在的趋势已经基本趋向远离业务。谁都知道和业务扯上关系，任务就是完不成，还没完没了，而且多半有吃力不讨好的嫌疑。当初我们提出的业务架构和系统架构现在也演变成了一个养老院的概念。公司能有几人有这样的能力担当呢！养的比用的多，吃空ing。也许大家都知道，当有机会规划公司时也多了几分经验。

手工制作的兔子灯看上去没有店主的精致，但MM亲自制作就有了不少感情。在爸妈家大概花了4小时总于完成，给兔子贴毛是最耗时间的，我比较懒MM辛苦的贴好了。正月十五拿出去遛的是否发现，前面有个封口没处理好，风一大蜡烛就被吹灭了，点蜡烛就成了常事。

说远了，其实这些都跟我没关系。偶是个码农，就负责没日没夜的写代码。公司说要向硅谷学习，实行弹性工作制，可这是中国特色的弹性工作制，只可延长，不可缩短。九点下班那算早的，十点下班才算正常。事实上就没有下班的时候，经常会凌晨的时候一个电话打过来，然后回公司去处理线上事故。为什么老在凌晨的时候出事故呢？这跟线上服务有关系，晚上上网的人少，所以很多复杂的操作都留在晚上做，比如更新数据。这些操作往往会导致事故。凌晨不睡觉起来处理事故，有啥好处呢？加班费肯定是没有的。就没有加班的概念，因为是弹性工作制。第二天首先要追究事故责任。如果是我们自己的代码导致线上事故，然后扣钱，通报批评，自我检讨。如果是别人的代码导致线上事故呢？然后老大们会说你们响应太慢了，从事故发生到解决，居然花了一个小时，导致公司损失了多少多少钱，好好检讨一下应急机制，然后还是扣奖金。

没日没夜的加班，周末、加节也加班，加上出了点小事故就没完没了，导致的是，面黄肌瘦，早生华发，同时伴有强迫症，写代码的时候小心翼翼，反复测试，线上操作的时候，反复校对操作单、配置项。

每次做项目的时候就说，大家好好干，辛苦几天，做完这个项目就休息。事实上一个项目没做完，另一个项目已经在排期了。为什么会这么忙呢？主要是因为码农的需求来源有几个，一是PM，主要是提一些产品层面的需求，一是策略，主要是提些按什么规则贴牛皮癣的需求，一是公司上层，涉及到商业模式的变更，比如按什么规则收费。用IT的行话说，码农就是这些人的共享资源，都在争夺的，根本就不会有闲下来的时候。哪天运气好，真的闲下来了，直接经理也会没事找事，让码农干点事情，以体现他的管理水平，比如整 理下文档，整理一下统计报表。

在这种情况下写代码，会造成代码能力下降。记得小时候，字写得本来不丑，后来语文老师老逼着抄课文，结果字写得很丑。有时候看前人写的代码，有些写得很恶心，就不像学过编程，基本就是这种情况下写出来的。当然了，经理会忽悠码农，做啥事情都是能提高能力的，扫天下者先要扫厕所。

顺便说一下分工吧，主要有几个工种，PM,RD,QA,OP。这几种工种都会强调自己很重要，说自己是产品开发的中心。具体来说，PM主要是面向用户，偏好是人工干预，自以为了解用户，主要问题是逻辑能力一般，头疼医头，脚疼医脚，都按他们说的做，会把系统弄得一团糟。PM的职责就是催促RD去完成他的产品设计，所以天然跟RD关系是不好的。RD也就是研发了。QA是测试，不过QA喜欢说自己是安全保证，测试只是他们一小部分工作。QA的喜好是把些根本没有意义的BUG，而对产品质量的提升意义不大。什么会这样呢？这样是有段时间QA的考核是按BUG数。而那些重要的功能，RD往往会自测，所以BUG不多。那些根本没意义的功能，RD考虑不到，容易出问题，比如各种根本不可能的配置。其实QA也不容易，刚开始工作那会，QA都是美女，过了一年，都变成男生了。这就是传说中的，女生当男生用，男生当牲口用。OP又叫运维，在RD看来就是负责操作线上机器的，但是OP说他们是运维的，线上操作只是他们工作的一小部分。OP也是命苦的人，各个项目组的RD的操作都要他们作，出点差错，会被批评，所以容易得强迫症。

一般来说，如果一个新产品的收入不符合预期，谁也不知道哪里出了问题。但是PM会说，是RD的代码写的有BUG,RD会说是OP操作错了。

这么辛苦，回报是啥呢？等到评职称，涨工资的时候，老大们说，你的工作有技术含量吗，是个人就可以做。然后那些拿着鞭子催码农加班的人则一路往上升。所以组内的同事，大都会变成祥林嫂，逢人就说：我真傻，真的，光知道埋头干活；不知道是在为人做嫁衣。

然后同事都要走。然后经理开始挽留。挽留会分四个阶段，

第一阶段是许诺有多少多少好处，但是大都不会兑现，上过一次当不会再上第二次，可以参考一下http://hi.baidu.com/rodimus/blog/item/3a91a500505b631d738b6531.html

然后进入第二阶段，这阶段的主要是打击信心，先说要跳槽去的地方怎么怎么不好，再说个人怎么怎么不好，去哪都混不好，一直以来都是他在照顾我们。这阶段就会把人弄得很烦，干脆写个签名档”天要下雨，娘要嫁人”。然后经理也写了个签名档“那么多要嫁人的，是庙太小，还是心太高”。

然后是第三阶段，这阶段主要是人身攻击，比如说，你性格有缺欠，怎么说你都不明白，太偏执了。如果是内部换岗位的话，这些话的影响范围不确定。比如某部门的经理，跟我谈得本来挺好的，结果跟当时的经理谈完之后，态度就变了，他们谈的内容不得而知。

脱了一层皮之后，终于进入第四阶段，这阶段主要是拖。各种流程拖着不让走，能拖一天算一天。

看见挽留无望之后，经理会跟其他同事说，这个人做得很烂，我压根就不留他。这些话可能会在公开场合说，甚至当事人也在场。

据同事说，出去面试的时候，常会问的一个问题是，为什么要跳槽，然后同事苦大仇深的样子，对方说，这个部门我知道，前面有人说了。

具体到我来说，之所以要走，直接原因是职称问题。经理原先的说法是，你某些方面能力存在缺陷，不足以升职称，我说如果是因为我个人能力不够，而职称低，那我认为这个部门不适合我的发展，我选择更适合我发展的地方。过几天经理又改口说，其他大家对你能力都很认可，你在这边成长很快，我说如果个人能力已经到了，职称却偏低，我认为这个部门不公正，我选择更公正的地方。反正就是没完没了的扯皮。

几终折腾，终于跳出火坑。进入一个为日本淫民服务的部门。相关的工作之前主要在上海的分部做，现在要迁回北京总部。所以换部门后第一件事就是去上海交接工作。适逢世博会，住宿吃饭都很麻烦。很多人专程跑到上海看世博的，我既然到上海了，也应该顺便去看看的，只是人实在太多了，所以没去。

交接工作，主要流程是看代码、文档，然后跟别人讲，然后台下有人提问，如果都答上了，就认为接手得不错，可以接手下一个模块。接手比较不爽，一方面是以前都是模块负责人跟我说他的模块是怎么怎么做的，然后我问一下细节，就可以开工了，另一方面是提问的人老问些类似用长连接还是短连接，某常量是多少的问题，弄得很烦。

回到北京后开始具体工作，一开始是负责策略，然后负责抓取、存储、建库之类。

日本的工作，相当不好开展。这里不负责任地猜测一下，市场份额最大的是以人工推荐出名的YAHOO。很多人认为搜索引擎能成功，是因为信息爆炸及需求多样性（也就是也尾理论），但是在日本，这两者都不太符合。日本拍的电影虽然多，但也不至于海量，用户的需求虽然有区别，但是也不会太多，人的基本需求差别不大。

这里顺便说一下工程跟策略的区别吧。虽然都叫研发，但是工作内容差别很大。在系统里有些问题是不能用数学解决的，就算能用数学解决的，也不一定能用计算机解决，能用计算机解决的，也不一定能用现在的机型解决，所以就需要一部分做策略的同学，尝试各种方法，碰运气看哪种方法能更好的解决问题。其实跟中医一样，只是靠积累经验，药方有用，但是背后的理论都是伪科学。既然是碰运气，所以变数大，所以他们自以为这样很有水平，其实就跟买彩票一样，认为变数大，所以回报应该高。

之前贴牛癣的策略同事，大都擅于表扬与自我表扬。刚开始的时候，是A发邮件说B很牛，B说C很牛，C说A很牛。后来觉得这样还不过瘾，A直接就发邮件说自己很牛，B也回邮件说，我也很牛，C说我更牛，这时候A不干了，说活都是我干的……这时候做工程的同事就郁闷了，这代码都是我写的，怎么就没我啥事。遍身绮罗者，不是养蚕人。

不久又到了职称评定的时候。因为上一个经理给我的上半年考核很低分，所以没机会参加职称评定。虽然换部门之前，就知道换部门可能会导致无法参加职称评定的，但是真的到了这时候，还是很不爽的。有点像PIE版上剩女，年轻的时候遇人不淑，上了年纪，也不管自身啥条件，都要房要车。然后考虑别的机会。到外面公司转了一圈，不太顺。

一方面原因是，社招的时候，更看重的是在原来公司的职称。这方法也合理，想通过一两个小时的面试，确定一个人的技术水平也不容易。唐骏之流就是利用了这个漏洞。

另一方面是，工作这两年，确实没学到什么东西。时间都花在处理各种琐碎的小事，比如为什么某个连接出错了，某个客户钱被扣多了，某台机器为什么慢一点。仅剩的一点时间 ，想做点像样子的事情，经理觉得风险大，不让做，或者资源上不支持，大公司里做开发，不是一个人就行的，还需要OP,QA的协助。最后只能做些小打小闹，闭门造车的事。

还有一个原因是，跳的人太多了，把行情拖低了，可以参考一下http://hi.baidu.com/rodimus/blog/item/0ab1b7cee6ff860f92457e38.html

这感觉像在监狱里待久了，虽然越狱了，但是想找个好地方待也不容易

主要还是之前职业规划得不好。记得之前的经理，居然把我写的代码说成他自己写的，然后去参加部门的CODE评比，然后还好意思在我面前自夸技术牛。跟了这种不厚道的经理，早该走的。之前还是过于安土重迁了。

那个经理是把别人的功劳据为己有的老手了，比如09年的时候，他已经是项目经理了，一行代码没写，每天就拿着鞭子催大家干活，居然还评上了年度最佳工程师，这得抢多少人的功劳。

顺便说一下，他怎么催大家干活吧。每天不停地在办公区走来走去，看大家都在干嘛，看到谁不在干活，就直接批评，“你怎么在看论文，活干完了再看”，“你居然在看BBS，还是PIE版”……

怎么催大家加班呢？在项目开始的时候，先假惺惺地跟大家讨论项目排期，然后说，“这个项目正常是要7天，但是作为一名试用期的新人，要好好表现自己，努力一下，3天吧”或者“这个项目很重要，周末努力一下，下周一前提测吧”。然后开始没日没夜地编码，但是万一还是延期了，他又开始说了，“这个排期是你自己定的，现在QA,OP都按这个排期去准备了，对大家的工作造成很大影响，不能延期”，然后只能熬夜写代码了。项目完成了，又假惺惺地说，项目安排要合理，要先紧后松，老这样熬夜写代码，伤身体，代码质量又不好

简单来说，就是对外软弱，把脏活累活接回来，然后对内独裁，整天逼RD干活。为什么会这么BT呢。这跟公司的制度有关，PM经理，QA经理，其他部门的经理的意见都可能会影响经理的晋升，但是RD的意见是影响不了经理的晋升的。所以RD只能用脚投票了。当然大部分经理还是不错的

前面是杂文，后面的部分就当随笔看吧

公司里做事的一个信条是“简单可依赖”，即简单，又可依赖，这当然是好的，但是很难同时满足这两点，有些事情的复杂度就是很高。而且关键的问题的是，“简单”的标准没定下来，有的人觉得四则运算已经很复杂了，只会加减，有的人觉得微积分也很容易。这个原则当然也有它合理的地方，在老员工离职率居高不下，新员工没有体系的培训的情况下，事情必须做得足够简单，简单的标准就是，毕业生可以直接接手。

但是这些人也不是完全地排斥复杂的技术。对复杂的推崇是人的本性，人都喜欢忽悠说自己的东西很复杂，各种祖传秘方。这些人也喜欢说某某部门的技术很牛，很复杂。但是，就是不让自己身边的同事做复杂的事。长得高不是你的错，跟了武大郎就是你不对了。所以这个做事原则，充分保证了将熊熊一窝。

公司里会议特别多，所以有白天开会，晚上写代码的说法。这里分析一下原因吧

首先是因为，有人热衷于开会。开会的作用很大，首先一点，解决问题固然重要，但让老大们觉得事情正开展得轰轰烈烈更重要。开会+群发邮件就是很好的方式。有点像中共的官员，每天的工作就是开会，公司里很多同事，每天的工作也是开会。悄无声息地把问题给解决了，还不如不解决。另外，开会也是抢功劳的重要方式，多点露脸，把事情都说成自己做的，那些没去开会的RD,人们根本就不知道他在干活

没有合适的仲裁方式，一群人没完没了地扯皮。解决问题大都不是选择技术上最好的方案，而是依靠行政力量，把好处留给自己，脏活累活推给别人，所以讨论容易变成办公室政治。但是行政力量也不能完全解决问题，由于历史原因，牛皮癣部门分成两块，有两个老大，他们是平级的，谁也管不了谁。这里不负责地猜测一下原因，这个部门老早就成立了，那时只有一个老大，后来公司裁了一个部门，也裁了些人，引发了些风波，不过那个部门的老大没裁，而是调到牛皮癣部门，又不能让他降级，于是就有了两个老大，一直到现在。

顺便说一下工作很难推动的原因。一方面是每个人都很忙，而又不是所有的负出都有回报的，所以人们只会做两种事情，一是被行政力量逼迫的，必须得做，一是自己发起的，自己有收益的事情。所以想推动别人协助自己的工作很难的，必须得自己的职称比较高，但是自己职称低的话，推动不了别人干活，肯定也是升不上去的。这是个恶性循环。

这个公司有个据说特别帅的CEO，这位CEO偶尔也会以座谈会的方式回答员工的提问。这时候形势就会两边倒，一边是花痴小女生，不停地表达爱慕之情，一边是饱受剥削的男民工在抱怨工资低，CPI涨得快。然后某位高层冲出来表忠心，说那些整天抱怨的民工都是LOSER。CEO觉得光是小女生崇拜他是不够的，于是开始了轰轰烈烈的造神运动。比如像CCAV一样的内网，每天播领导活动；还有一本语录，人手一份，还要考试

项目起名是很重要的，一定要让人听了不知道这个项目是做什么的，出自中国的古典神话，或希腊、罗马神话都可以，越玄越好，正好能唬住没文化的民工。曾经做过一个项目，这个项目大意是要把一个本来只是流式处理数据，没有状态数据的模块，改成记录所有数据，所以内部叫法是“****状态化”，后来某人起名叫“运河计划”，化腐朽为神奇。取意是说，这个模块连接了公司很重要的两部分服务，所以称为运河。后来想了想，这种说法不对，这两部分服务本来就是连接，只是流式的，也就是类似消息队列的功能，现在要做的是把消息队列的内容存下来，叫水库比运河更合适，叫“三峡工程”多好，不过貌似现在中共也不拿这个当政绩了，不吉利。

http://www.hetaoblog.com/?p=34

#jmeter的linux资源监控器改进

http://www.51testing.com/?uid-170805-action-viewspace-itemid-96360

#性能测试方法

http://www.qqread.com/soft-engineering/a448881.html

#ab-Test的总要文章

http://blog.miniasp.com/?tag=/ab

#JMeter的最佳使用方法

http://gaokaozl.blog.hexun.com/16351908_d.html

#python web性能测试工具

http://code.google.com/p/multi-mechanize/

#Finalbuilder

http://www.cnblogs.com/arming/archive/2004/09/01/38267.html

http://article.yeeyan.org/view/ShiningRay/19940?from_com

#Memcache LUR

http://www.javaeye.com/topic/225692

#Memcache总结在Memcache的实际使用中，遇到的最严重的问题，就是在增减服务器的时候，会导致大范围的缓存丢失，从而可能会引导数据库的性能瓶颈，

http://www.okpython.com/bbs/thread-3752-1-1.html

#memcached win32的安装问题

http://blog.csdn.net/ufojoan/archive/2008/04/10/2272223.aspx

#memcached 分布式

http://www.okpython.com/bbs/thread-3752-1-1.html

#Discuz!NT 中集成Memcached分布式缓存

http://daizhj.blog.51cto.com/285189/141419

#memcache监控方案

http://www.diybl.com/course/6_system/linux/Linuxjs/20090317/162059.html

http://www.javaeye.com/topic/438722

#memcache深度分析

http://blog.developers.api.sina.com.cn/?p=124

#PAE\3GB\AWE的区别

http://support.microsoft.com/kb/283037/