试用了一下，有的操作会比较卡，不知道是网络速度的原因还是机器性能的原因还是两者的原因。
而且目前貌似不能支持多语言，我在chat框输入中文，显示出来的竟然是乱码···

这东西咋赚钱？
目前看来，买衣服、家具等系列用品啥的会是一个赚钱的渠道吧？连qq秀那种衣服都能卖钱，这3d的衣服是不是也能卖个好价钱呢？
另外就是广告吧，比如去逛街，看的都是各种各样的广告。哎，现在的互联网，弄来弄去还是广告···

有兴趣的同学可以去试试，目前的功能我认为还是比较简陋的···
http://www.lively.com

今早5点半就醒了，可能是昨晚睡的太早，也可能是早上的风太大给吵的。
没睁开眼睛前，心想这么大的风，怎么也是个大晴天吧，可是睁开眼睛看到窗外，还是灰蒙蒙的一片。

抛开天气不说，其实早睡早起还是蛮舒服的，至少身体特别放松。

这样的时间总会想起高中那会儿的情景，那段日子是充实的。
每天起的很早，吃过早餐后，就蹬着车子往学校奔。
街上的人有从早市归来的，或是像我这样的学生，还有几位完工的环卫工人。
每个人都闲适的忙碌着。
路旁的杨树偶尔被风吹的沙沙作响，因为空气很好，叶子油亮亮的，在太阳的照射下不时的闪动。
在东北的夏天，太阳会升起的很早，6点多的时候，就已经很亮了。
学校在家的东面，所以每天早上都要迎着太阳上学。
那时觉得那时的阳光很刺眼，现在觉得那时的阳光很幸福。

早上上msn，发现原来一个同事在线，我问怎么这么早，他说都走了，就剩他一个人通宵加班了。
天下没有不散的宴席，不过最后一个离开的往往最伤感，因为那时可能已经没有人为他送行。

说点开心的，一位好朋友最近过了CCIE，他女朋友最近也来了北京，于是昨晚在眉州东坡小小庆祝了一下。
席间谈论最多反倒不是他，而变成了谈我的“终身大事”。
说到这，想起了前一阵的两次相亲经历，有兴趣的同学可以线下交流

准备洗脸吃早饭

另外今天还看到了《比尔盖茨在微软的最后一天》，邀请了很多名人参与“演出”。盖茨谢幕，IT依旧继续。在电脑革命的这几十年里，盖茨无疑是最闪耀的传奇人物之一。他和微软改变了这个世界，改变了太多人的生活。我现在就在装有windows的电脑上写着blog～

这个世界会继续充满想象。

从递交辞职申请到正式离职，前后也将近有一个月的时间了。
这一个月的时间里，很多时间都是在交接工作，期间最大的一个工作就是做了一个系统的服务器迁移。
工作上的压力小了，但是生活的节奏基本没有变化，一切仿佛还是像老日子一样继续。

前段时间无暇回忆过去的两年，而且这种将要离开时的回忆总是带有伤感的色彩。

现在可以沉静下来，想想过去的两年在TOM都做了什么，又有怎样的收获。

这两年从开发到测试，从系统管理到部署，从课程培训到面试新人，前后很多方面都有了广泛的涉猎和进步，另外周围有很多个各个技术领域的达人，他们也让我学到了很多。

不过事情常常有两面性。上规模的公司必然需要更多的制度来管理日常的工作和事务，这对于比较喜欢Open方式的我，是个挑战。但是两年下来，我觉得无论外部环境如何，自己的适应是首要的，如果你想改变现状，那么首先要有足够的能量，如果没有能量，那就安安稳稳踏踏实实地把每件事情做好就ok了。

这两年来赶上了公司的很多活动，刚来那会儿，就参加了研发中心的年度聚餐，然后就是公司在北京饭店召开的年会，接着是拓展、北戴河，还有前一阵的三亚之旅等等等等，貌似公司所有的活动，我都赶上了一遍～然后就是同事大大小小的搓饭，刷夜K歌，杀人，保龄球等等。

也正是通过一次又一次的活动，很多人也从陌生走到熟悉···

常常会看到这样一些文章，说不要把同事当朋友，即使是朋友，也只是暂时的。
或许我们这一代人不同，也或许我一直处在相对平静的技术部门，我经历过两家公司，都觉得同事是可以成为朋友的，并且可以成为很好的朋友。
本想写一些对朋友的回忆，但发现在blog上罗列出来，并不是一件很容易的事。
纵然心中有千言万语。
即使是在现实生活中，我也很难用语言对朋友直接的表达赞许或者是关怀什么的。
这有时看上去会很冷血，但是在我心里谁轻谁重，理解我的人自然会知道。

关于辞职这件事，我一直保持得很低调，以至于身边有的人直到最后一天才知道我要走。
这是因为在事情没有被最终确定下来之前，我不想弄的“满城风雨”，
即使我没有想象中的那么受人重视（自恋ing～）。
不过怎么说呢，无论怎样，大家迟早有分开的那一天，分开固然不是一件能让人开心的事，但是每个人都有各自的路，我们只能在内心互相祝福未来更好。

上周一，和QA小组的朋友们第一次也是最后一次聚餐。
上周二，完成那套最复杂日志系统的交接工作。
上周三，最后一次为同事解答BugFree的问题。
上周四，最后一次拷贝日志。
上周五，“完成”了在公司的最后一次迟到。
上周五，和“午饭友们”吃了离开公司前的最后一次午餐。
上周六，跟朋友们一起在钱柜很High的K了一次。
今天上午，花了一个多小时办完了离职手续，留下了印有我头像的员工卡片做纪念。

路过TOM，生活继续～

最主要的原因是上周末两天的时间没有怎么开发。
上周六去汇蕾修电脑，周日又去跑了马拉松，两天都是不到6点就爬起来了，周日下午又跑回公司加班—-最近一个系统的数据总是出问题，因为这些，耽搁了一部分的开发时间。

今天在BugFree的官网上写了延迟发布的公告，有点不情愿，总觉得这样就不完美了。
但是回过头来想想，这也是为用户负责，为了用户能够用上更完美的版本。
希望月底能有一个健壮的RC1供大家使用，期待那天的到来～

不过当在昨晚小组讨论确定BugFree2RC1的发布时间的时候，我当时的感觉是心里有块石头落了地。
这是一种很确切的感觉。

剩下的将近两周的时间，需要修改一些Bug、一些细节、还有一些功能的改进。
在下下周的10月26号，BugFree2RC1就能和大家见面了。

很期待那一天的到来。

假如你有一份聊天记录，格式是大概是说话人+冒号+内容+tab+时间，如下：

我：哈哈 2046-4-1
她：你好 2046-4-1
我：我不好 2046-4-1
她：你好 2046-4-1
我：··· 2046-4-1
她：你好 2046-4-1
我：扁 2046-4-1
她：哦 2046-4-1
我：··· 2046-4-1
—-未完待续—-

后面会是啥，不知道，反正是一大堆有聊无聊的话，也可能不止“我”和“她”。我们现在来统计一下这个聊天记录里的碎碎念达人。
把聊天记录存到一个文件里，比如suisuinian.log，然后运行如下命令：

cat suisuinian.log |awk '{print $1}'|sort|uniq -c|awk '{printf ("%010d %s\n",$1,$2)}'|sort -r +0 -1|head -n 3|perl -n -e '/([0]{0,10})(.*)/ && print "$2\n"'


恩，前3位的碎碎念句子就出来了。

3 她：你好
2 我：···
1 我：扁

“她”说了3次“你好”，“我”说了2次“…”～

说明：
cat suisuinian.log 获取内容
awk ‘{print $1 }’ 打印出聊天内容（去掉时间）
sort 排序
uniq -c 去除重复并计算数目
awk ‘{printf (”%010d %s\n”,$1,$2)}’ 将数目用0补齐10位
sort -r +0 -1 按数目排序
head -n 3 取前3位
perl -n -e ‘/([0]{0,10})(.*)/ && print “$2\n”‘ 将用于补齐的0去掉

很好的linux，很好的工具～

做易趣相关部署工作将近一个月，有一些感想，记一下。

1、大型项目的部署会很复杂。当然也会简单，前提是你真的清楚身在何处，要做什么。
一个像eachent这样大型的网站项目，本身的架构层级很多，涉及到的软硬件资源也很多，乍看上去繁杂无比，令人望而却步。这会造成一种紧张气氛，萦绕在部署团队周围。不过只要能够静下心来，整理清楚资源和流程，便可以做到繁而不乱。

• 整理一份软硬件资源清单列表。依照分类列清，无论是数据库服务器还是缓存服务器，无论是负载均衡还是中间环路，把每个资源个体的相关的信息（如IP、端口、说明等等）都写全，一些敏感数据除外（如DB用户名、密码等），把这份清单放在大家触手可及、抬眼可看（如交流白板）的地方，放到版本库中也是个不错的方法，记得要做到及时更新。不建议通过邮件的形式传来传去。
• 整理每个模块、每个项目的部署流程和部署架构。一个模块或者一个项目的代码，它的周边资源该如何准备，准备好后是如何将可用代码上传到服务器，而且是方便、快速、准确的上传到指定的一台或多台服务器。线上、中转服务器、版本库如何协同，保持步调一致。灾难恢复的流程又是怎样。总之，就是做到部署动作可以按照一定的模式重演，这也会为日后的自动化部署提前打下基础。
• 整理负责人。DBA是谁？前台机器的管理员是谁？构建代码又归谁负责？这很重要，哪个地方出了问题，可以知道找谁，而不是像无头苍蝇一样到处打探。当然，这份清单同样需要人手一份。

做好这一步，并不需要花太多时间，却会为日后的部署省去很多麻烦。

2、记住部署过程中的每一条问题。
即使有最初的看似精细的部署文档，也不一定能够应付多变的实际情况。遇到问题我们就要解决问题，但是有时候常常忘记将这些问题（这里不包括程序代码的问题）产生的原因和解决方法及时的记录下来，等到系统成功上线再回头总结，怕是不能一一想起了。

3、再大的线下Bug也是小Bug，再小的线上Bug也是大Bug。
程序到生产环境后，常常会暴露出一些bug，这个时候就需要修改程序。我觉得应该确立这样一条原则，在部署期间所修改的代码，一定要经过测试，而不应该慌忙的更新到线上，因为再小的bug被放到线上，也会被无限放大。

4、谁的责任？
系统上线，每个人的压力都很大，一旦发现某个部署问题是由于个别人的疏忽所导致的，应该先事后人，毕竟，解决问题最重要。不要急于旗帜鲜明的确立是谁的责任，这些事情可以放到最后～

5、部署VS开发经验。
如果你有开发经验，而且还是部署自己熟悉语言的项目，那简直是一件不能再好的事了。你甚至可以协助PD很快的定位错误所在。相反，如果面对的是一个一无所知的语言领域，则会总有一种被牵着鼻子走的感觉。熟悉开发、熟悉部署项目的开发语言，虽然不是必须的，但会令你事半功倍。

6、结对部署。XP中有结对编程，而结对部署在实际操作中的效果也是不错的。假如有两个模块，分成两个人一人部署一个模块和两个人一起部署两个模块，后者的效率要比前者高。两个人能够互相监督彼此的操作，还能针对一些问题进行讨论，这也大大降低了部署的出错率。此外，这对降低人力风险也有帮助。

7、万恶的权限！哈，这算是一句牢骚吧，也算是一个小建议。如果你在部署中遇到问题，首当其冲的要想到是不是哪的读、写、执行权限没设对～

出于商业机密的原因，我只是提炼了一些普遍层面的东西，权当抛砖引玉吧。
最后，欢迎大家访问新的易趣平台～

1、用版本库没？
有了版本库，你可以让历史重演，没有版本库，等待着你的是绝对多的不定时炸弹。

2、统一开发方言没？
项目开发，交流占了很大比例，信息的精确传递和准确获取，直接影响着项目的质量。既然要交流，就要说词汇。所以不要一会儿说“产品”，一会儿说“物品”，一会儿又说“商品”，一会儿说“人员”，一会儿说“会员”，一会儿又说“用户”。统一一下开发的方言，你会发现交流的效率会大大提升。

3、有测试没？
这里不是说程序员测没测试自己的程序，而是有没有独立的测试人员和测试环境。一个熟练的程序员可以同时担当一个小项目的PM、PD、BA等角色，但我强烈建议不要把QA/TE这个角色在分给他。所以一个再怎么mini的项目，也要至少需要开发和测试两个人。

4、有文档···没？
这是开发人员永远的痛。
在随需应变的今天，去维护一份开发文档、需求文档、用户手册等等文档真是一件痛苦的事:-(
不过总该有项目的开发记录吧？（PM和老大要看）
总该有项目的安装手册吧？（配置人员要看）
总该有开发问题总结吧？（知识库，大家都可以看）
总该有~~

5、不知道了，还没想好。不过能做到、做好上面四条，就能让你的项目轻松一些了。
而且这几条似乎并不是那么难实现，比起引入强大的工具、倡导前卫的开发模型、设计精致的系统架构来说，实在是容易很多。