2011 年 01 月 05 日
2010总结: 2010年最大的变化就是换了工作,换了城市。从电子政务跳到互联网行业,从厦门来到杭州。
迷茫:
年初一直很迷茫,工作上找不到方向,觉得公司的项目管理水平低下,即使自己的技术水平再好,也没有办法改变项目中遇到的种种管理上的问题,而且一直呆着也没有什么发展空间,于是做完自己感觉管理上非常失败的一个项目后开始寻找新的公司。
应聘:
那时候正好支付宝在javaeye论坛上打广告,说实话那时候我根本没用过支付宝,只知道和淘宝有些关系,阿里系的java水平算是国内比较好的,另外冯大辉、蔡学镛等当时支付宝的牛人在twitter上相当活跃也引起了我的兴趣,我就投了一份简历试试看,电话面试完以后,屁颠屁颠跑到杭州面试,几轮面试顺利通过后,就在6月份加入了支付宝。
生活:
奶奶80大寿,趁着入职前的空闲时间,时隔7年之后回到了吉林,也见了N年没见的亲戚们,非常的开心。父母在十一期间也来杭州看我,他们对我的现状也比较满意。购入ipad加入apple阵营,ipad的作用超过预期,优秀的体验也触发了自己几个idea。
感情:
和妹子感情良好,见了双方家长,总的来说还可以,生活有滋味。
学习:
读的书比以前多了不少,主要是觉得新的工作上可以用上这些知识,有必要充实自己,有学习的意义,比以前又开窍了不少。看了大概7,8本技术书籍,明年争取看更多。
技术:
这一年的写代码量比以前要少,思考和review别人代码的时间变多了,但是自己的代码质量提高许多,因为不断的学习使自己对技术看的更加清楚了,支付宝的高要求对自己也是一个督促。另外总结了自己的性能优化方案,并将一个系统的性能提高了10倍,使得系统在每天承受上亿的请求时保持良好的运行状态。以及一些关键问题的解决都让自己小有成就感。
工作: 总体感觉偏累,属于自己的时间比较少,对现状基本满意。加入支付宝的研发团队让我开阔了眼界,尤其是敏捷开发的一些思想运用,比如自动构建,持续集成,迭代开发,代码review等给项目开发带来了大量的好处,也解除了我对开发过程的一些疑惑,遗憾自己没有早一些接触和实践。
总的来说2010是充满变化的一年。
对2011的期望
把负责的项目做好
生活一切顺利
父母身体好
gfw少封一些优秀网站
房地产崩盘
做3个开源项目,实现5个自己的idea
读10本书,包括技术和非技术
每季度做一次分享
2010 年 12 月 20 日
dropbox及其山寨产品的出现让文件可以轻易的在各个平台和各台电脑上实现同步,而TeamViewer则可以让我们轻易的遥控远程电脑做任何事情。
比如有时候在家会需要一些公司电脑上的资料,这时候TeamViewer就可以出场了,只要公司的电脑没有关闭,并且打开了TeamViewer,那么在家里就可以直接远程连接,不需要管任何防火墙或者IP地址之类的影响,每台安装了TeamViewer的电脑都会有一个唯一的数字ID做标识,并且生成一个动态密码,通过ID密码可以直接连接,建议注册一个的帐号,这样可以把自己的所有电脑都加在自己的帐号里,就不用记住那一串数字ID和动态密码,每次从列表里选择就可以了。
(更多…)
2010 年 12 月 17 日
以前听 @bluedavy 讲过几次集合类一定要限制大小避免内存溢出,却没有引起足够的重视,没想到今天真的遇到了。
过程如下:下午在线下的稳定环境突然出现了内存溢出,java.lang.OutOfMemoryError: Java heap space 。先观察日志,主要业务逻辑并没有完全停止运行,即使commons-error日志里一堆的内存溢出,也并没有完全影响到主要的功能逻辑,所以可以大概确定是一些非核心服务导致的,再仔细观察commons-error,有不少ibatis执行时抛出的OOM,根据堆栈信息,又联想到之前做的一个模块:一个线程定时轮询数据库,根据时间标记,取出这段时间内需要处理的数据,使用完毕后删除掉。再去看这个功能模块的日志,果然,每几分钟轮询数据库时就打出一次OOM错误,再联想到bluedavy提到的集合类限制大小的问题,立刻明白原因很可能是定时捞取数据的时候,数据量过大,直接超出了堆内存最大值,所以导致内存溢出。查一下开发环境数据库,果然如此,定时捞取数据的sql执行一下会查出300W+的数据,添加到List,一次性加载到内存里,自然就溢出了。
(更多…)
2010 年 12 月 11 日
这是一篇用ipad写的博客,写之前必须把控制台﹣设置﹣撰写﹣Rpc发布打开,才可以用ipad或者android客户端进行编写,我竖握ipad,用拼音输入法打字,因为我的手指比较长,两个拇指覆盖整个键盘区,所以还算习惯,比手机打字快,比电脑慢不少。横屏输入是浮云,太容易误操作;手写输入也是浮云,速度太慢。
功能上没有富文本编辑器,但是可以上传图片和视频,这样的话直接用safari打开wp进行编写似乎更好。
好了,本次测试就到这里,ipad拿太久了还是会累的。

2010 年 12 月 09 日
目前NEXUS ONE也没有收到android2.3的推送,于是下载了SDK尝鲜一下,至少在UI方面改进很小,没什么好期待的,就这水平还说不让第三方定制UI呢,难道palm的设计师过去就只改了这么几个图标?也许要等到3.0才会有大的变化吧。
(更多…)
2010 年 12 月 09 日
写设计文档时总要在word里贴一份所谓的表结构设计的表格,一个一个整理太麻烦了,用groovy写个小程序生成一下,就当练手了。
下面的代码会生成一个xls文件,excel打开后再拷到word里选一下格式就变成表格,就基本可以使用了,也就是说我没有引入任何操作word文件的包,那样太麻烦了。
只支持mysql,其他数据库的话把里面的两个sql和数据库连接相应的改掉就可以了。
(更多…)
2010 年 12 月 07 日
之前是把博客放在taobao买的合租主机上,结果被别人的黑冒SEO连累,再也没办法把域名绑定在dreamhost主机上了,索性买了个justhost的独立主机,这次完全是自己的地盘随便折腾吧。
2010 年 11 月 28 日
eclipse的设置模块设计的非常糟糕,没有一个专门的配色方案模块,各种配置参数只能整合在一个epf文件里,如果直接把其他人的配色方案导出再导入你的eclipse里经常会出一些问题,甚至导致ec无法启动。
(更多…)
2010 年 11 月 09 日
设置一个合适服务端系统的线程数又是一件事半功倍的事情。
最佳线程数的东西我是最近才从淘宝的一份ppt上看到的,这里总结一下:
在压力测试中,先给服务器的最大线程数设的很大,然后逐渐增加压测工具的并发数,一开始,并发数增加,QPS会上升,等上升到一定的值之后就不再上升了,再继续增加压测并发数,QPS就会开始下降,响应时间也会增加,那么,在QPS刚刚达到最高点时的并发数就是最佳线程数。
最佳线程数的定义就是:刚好消耗完服务器的瓶颈资源的临界线程数。
(更多…)
2010 年 11 月 08 日
前面说了怎样合理的找到系统的瓶颈,解决系统的问题,这时候系统应该比较健康了,如果还想要进一步压榨系统的性能,就必须从一些参数下手,而调整参数实在是一件事半功倍的事情。
JVM参数调优总的来讲主要分两个方面:1.代大小的调优 2.垃圾回收机制的调优。主要的调优方向也是两个:减少full gc次数,减少每次gc所使用的时间。
(更多…)