只依稀记得九个月漫无目的的加班，还没结束，不知道明年的何时是个尽头。这里也不想再赘述关于加班的事情，大家都明白的。客观改变不了，是自己陷得太深。

一年时间，居然没有点记忆，真是悲哀。收到很多邮件和留言询问我关于paypal支付的问题，我却发现对此的记忆是多么的模糊，大学时一天的不眠不休，写完了那些代码，现在，却再也找不到当初的感觉和记忆。工作两年多，失去了很多很多，最重要的，是失去了时间。

2011年，更是无法回忆的一年，堆成小山的安排都烂在角落，一切都被毫无意义和鲜有意义的事情充斥着，答应别人或者别人答应的诸多计划都因为那些虚无缥缈的形式主义而被放弃。就这样，浑浑噩噩，走着，或者爬着，到了年底，只有一身的伤病和疲惫见证了我这一年。

最近看到很多人，很多事，静下心来，定期的冥想也还是有道理的，不为别的，只为让自己走得更远。也不用在每年的年尾一番豪言壮语，期望来年能有改变。寻谋改变，即刻上路，只想让时间不再被遗失。

优点：自然就是方便，ipad2比前一代轻薄了不少，随手放在包里一点问题都没有，配上E5805，上网也OK，不用再抱了个笔记本跑来跑去了。基于一直开机的特性，也做到了随时可用，车上，街上，办公室里，餐馆里都可以。一些app的设计也很不错，能够做到随身提醒，基本一些日程安排备忘都没有问题。

不足：打字手感明显没有键盘好，输入效率也不高。基于iOs，许多习惯需要适应，目前看来，至少编程暂时实现不了，能写也还需要一个编译器，不过现在涌现的在线编程也许能弥补这个缺点，如果能实现，则可以在任何访问web的设备上编程，时髦的说法就叫云编程吧。

综合一周下来，感觉单纯的pad办公还有点勉强，目前理想的做法应该是以pc机为核心，主要是工作的细化和一些复杂任务；pad作为终端设备，主要是日程安排和即时信息的反馈，通过网络同步，这样比较完美。

观察了几家银行，我大致把申请方式分为三种。

第一种，传统的线下申请。如华夏银行，杭州银行。普通客户如果需要申请，则必须到网点柜台填写申请书，才能申请信用卡。或者是银行工作人员在写字楼，商场等摆摊现场推销和办理信用卡。

第二种，线上申请，线下办理。如招商银行，交通银行。客户可以通过网站或电话提交信用卡申请，然后由银行派工作人员上门办理信用卡申请。

第三种，线上申请，线下开卡。如工商银行，广发银行。客户通过网站填写信用卡申请信息并提交，银行则直接进入核卡流程，完成后直接发卡。客户收到卡后，需要去附近网点提交各种证明资料进行开卡。

严格来说，第一种和第二种都可以归并成为传统申请，后者不过多了一个网站和电话的通知渠道，并有专人上门。传统信用卡申请效率较低，由客户发出申请意愿，然后安排人员上门填写，之后对于信用卡部不在当地的银行，还需要邮寄申请资料至卡部，再由卡部对于纸质资料进行审核，完成核卡后，还有一个邮寄卡片的过程，这样一个流程下来，往往大半月已经过去了。

同时，对于客户来说，他们的个人资料也存在风险，银行工作人员能够充分了解客户的各种信息，以及各类证件的复印件。对于上门办卡，往往办卡人员会在客户单位推销信用卡，对于客户也会造成非常不好的体验。

因此在传统渠道上，信用卡申请的效率低下，隐私安全也不能完全保障。

第三种线上申请的方式，才能算真正意义上的线上申请，利用了银行网点柜台资源，客户的所有信息都在网上提交，提交后立即进入核卡流程，省去了填写纸质资料和邮寄资料的环节，客户收到卡后，只需要去柜台提交证明资料就可以完成开卡。

从整个流程来看，会发现所需要的资料一样都没少，很聪明的利用了柜台资源来将资料邮寄这个过程从核卡前移到了核卡后，这样就大大加快了申卡速度，提升了申卡体验。同时，在线提交也减少了客户资料泄露的风险。

不过从广发在线申请的体验来看，目前还是有一些问题的，特别是客户收到卡片，去柜台提交证明资料后，还需要4至5个工作日才能激活卡片，个人觉得对于柜台能够验证资料的情况下，这个流程应该短于24小时，这之间也不存在什么技术问题。

说点题外话，前几天经常看同事在做批量处理，现在很多不合理的地方，比如信息有一天的滞后，都是科技工作上没有做好造成的，随着用户体验要求的不断增加，“实时”是未来最普遍的要求。看现在的科技，没有什么完不成的需求，只有想不到的业务，如果一直拘泥于自己的认知，认为有不能实现的需求，那科技还会有进步吗？

现在需要的，是能够真正把科技和业务相结合，并且互相推动发展的人。在线申卡，对于科技来说，只是一个很简单的功能，但却解决了一个头疼的问题。

不成熟的管理制度，没有对项目整体的了解，盲目的投入新的项目，以及急于将各种新鲜事物不加思索的应用到团队中，都是一些值得回味的。所以说，换位思考，说起来容易，只有很少的人能做到，没经历过这个位子，真的很难模拟这个环境。

最近主要在关注nodejs和redis，业务上被分到银行支付结算这一块，也是个机会。

抱怨归抱怨，如果只有抱怨和消极，最终还是害了自己。至少，趁着加班的氛围多研究点东西。

每周一到周五，早九晚九，再加个周六，已经两个星期了，每日昏昏欲睡，筋疲力尽，真不知道何时是个头。

和以往一样，项目继续在无序中进行着，改了又改，变了又变，也早已经没有刚来时的激情。当洗脑时，教导着大家要牺牲时，大家都笑了。真的，只有为自己，没有为别的。

不过周末加班的时候，李总的一些话还是让我有些感触，至少，还有人在关注这些技术并尝试努力。但是，毕竟老大的位置决定了不可能亲历亲为，将想法和技术做到应用层面，只能靠层层传达，到开发者手上时，已经惨不忍睹，不成模样了。

刚毕业时的那份激情，还真的已经被消磨殆尽，只剩下抱怨和消极。桌边的项目表已经有了薄薄的灰尘，和熊哥X哥讨论的那些事也没有了下文，看着X哥培养新人的那份干劲，熊哥那份犹存的激情，我还剩下什么？

一个人始终成不了奥特曼，改变不了环境。懒散了那么久，要给自己定些目标了。有人说过，不能被项目弄死，即使是一个充满悲剧的项目，最终也要结束。

面对现实，忠于理想。拿起那些我该做的，重拾那些我想做的。

Using(Graphics g = this.CreateGraphics())
{
     Int dpi = (int)g.DpiX;
}

其实就是通过在当前环境下创建一个图形，来获取Dpi 。

顺便试下代码高亮

1月。我在不停的加班中。新项目开发刚刚开始，很多很多的工作要做，加班，没日没夜的。很少能坐上403路公交，只能做220夜班车回家。关于项目开发中的问题，现在回过头来看看，只能一笑了之。

2月。博客被关了，因为没有备案，被上海的服务商关了。回头和熊哥一合计，这样下去也不是办法，重新买了一个美国的空间，起码，不受行政命令的制约，起码，我又不做坏事-_-

3月。Ken还在中国。周末一起去了义乌，顺便也去瞄了下植物园的梅花。说起来真浪费，公园年卡一直到今年过期为止，都只刷过那一次植物园。接着，三月份生了一场病，其实就是发热，一时想不开，去医院挂了点滴，看了上个月央视的新闻，真后悔去医院。。。

4月。离项目上线还有不到两个月。不断的加班，加班，再加班。项目前期的准备不足开始体现出来，如同一颗颗深埋的地雷，各种问题叠加。整个月的主题就是加班，加一些很无所谓的班。这也是这家公司的一个特色吧。

5月。富士康依旧很有规律的跳楼，但也同时证明着跳楼解决不了任何问题。我们也依旧很有规律的加班，但也同时证明这加班解决不了根本性的问题。系统最终还是上线了，5月的倒数第二天，夹杂着咒骂，抱怨，最后十分钟，还没有冻结的代码，在那天深夜，终于上了生产线。不管是好是坏，至少能结束加班的日子了。

6月。毕业一周年，在杭州一年。作为一个外来务工人员，压力依然很大。系统上线了，感觉自己浪费了很多时间，花在一些很官僚的事情上。有些事，是应当做；有些事，只是给某些人做。一直觉得，为什么大家不敢承认项目的失败呢？

7月。世界杯，买彩票，很欢乐。

8月。对一期的项目修修补补，总算也有了个稳定版。二期的项目更加的“宏伟”，只是，带着陈旧的思维去做改革的事情真的好吗？

9月。传说中一年比较闲的时候，开始制定自己的计划，看书，学习。工作依旧蚕食着我的时间，有用无用，都在那里。

10月。世博会，凑个热闹。也满足一下出去旅游的欲望。被封闭在一个病态的企业文化里确实害人。

11月。换了个房子。找了一个有书房的房子，需要一个书房，让我安心的，静心的做事。

12月。雪，冰，年末。继续按照自己的计划，看书，学习。顺着组织的意愿继续工作，但别忘记自己在做什么，别忘记对与错。体检报告出来了，身体没想象中的好，食堂的地沟油一直在招手，组织对我们很好，有加班，还有地沟油。

隔了那么久才把总结发出来，期间也不知道在做什么。2011也过去了四分之一，我还没从冬眠中醒来吗？

一直想用一个没空，很忙的理由来搪塞，但其实骗不了自己，一个字，懒。

对于这段时间的规划，自己做得太差，博客本是一个很好的平台，不在于写给别人看，更关键的是留给自己翻阅。没有很好的规划时间，应该是一个很大的问题，留恋与网络巨大的信息量，也是一个要解决的问题。很多时候，仅仅是看看新闻，就花去了大量的时间，在网页间漫无目的的游弋。

本周日，去爬了浙大老和山，7点半起床，也算对时间规划的一次胜利吧，接下来，还有更多的挑战要面对。

继续坚持每天看书，至于查阅网站，看样子要制定几个质量较高的，而不是无目的的点击。

PS：毛8你另一个微博帐号太恶心了。。。。。

当业务拉动IT时，只能说IT用来简化了工作；当IT驱动业务时，才体现了两者结合的创造力。

原文在此，看完之后，终于明白为什么优秀的工程师都去了/想去facebook，因为那里是工程师们的天堂。

译文:

我对facebook的运转着迷。这是一个很独特的环境，不容易被复制（他们的体系并不适合所有的公司，即使他们努力尝试过）。下面是我和facebook的朋友们关于他们如何开发和管理项目的记录。

现在距离我收集的这些信息又过去6个月了，我相信facebook肯定又对他们的项目开发实践进行了改进。所以这些记录可能会有点过时。同时facebook的工程师驱动文化也越来越为大众所知。非常感谢那些帮助我整理这篇文章的facebook的朋友们。

记录：

• 截止到2010年6月，facebook有将近2000名员工，10个月前只有1100名，一年之间差不多翻了一番。
• 两个最大的部门是工程师和运维，每个部门大概都是400-500人。这两个部门人数大约占了公司的一半。
• 产品经理与工程师的比例大约为1-7到1-10。
• 每个工程师入职时，都要接收4-6周的培训，通过修补bugs和听高级开发工程师的课程来熟悉facebook。
• 培训结束后，每个工程师都可以接触线上的数据库(更大的权力意味着更大的责任，也有一份”勿做清单”，不然可能会被开，比如共享用户的隐私数据)。
• 有非常牢靠的安全体系，以免有人不小心/故意做了些不好的事。
• 每个工程师可以修改facebook的任何代码，随时可以迁入。
• 浓厚的工程师驱动文化。”产品经理基本可以被忽略”，这是facebook一名员工的话。工程师可以修改流程的细节，重新安排工作任务，随时植入自己的想法。
• 在每月的跨部门会议上，由工程师来汇报工作进度，市场部和产品经理会出席会议，也可以做些简短的发言，但如果说得太多，很可能就会被打小报告。他们确实想让工程师来主导产品的开发，对自己的产品负责。
• 项目需要的资源都是自愿的
  • 一个产品经理把工程师们召集到一起，让他们对他的想法产生兴趣。
  • 工程师们决定开发那些让他们感兴趣的特性。
  • 工程师跟他们的经理说：”我下周想开发这5个新特性”。
  • 经理会让工程师独立开发，可能有时会让他优先完成一些特性。
  • 工程师独立完成所有的特性——前端/后端/数据库，等等所有相关的部分。如果需要得到设计人员的帮助，需要先让设计人员对你的想法产生兴趣。其他如架构之类的也一样。但总体来说，工程师要独立完成所有的任务。
• 对于某个特性是否值得开发的争论，通常是这么解决的：花一个星期的时间完成他，并在小部分人群中(如1%)进行测试。
• 工程师常常希望解决难题，这能获得声望和尊敬。他们很难对前端项目或UI设计产生太大的兴趣。这跟其他公司可能正好相反。在facebook，后端任务，比如新的feed算法，广告投放算法，memcache优化等等，是工程师真正感兴趣的。
• 所有的代码修改都要进行审核(通过一个或多个工程师)，但News Feed是个例外，因为太重要了，Zuckerberg会亲自review。
• 所有的修改至少要被一个人审核，而且这个系统可以让任何人很方便地审核其他人的代码，即使你没有邀请他
• 工程师负责测试，代码修复，和维护自己的项目。
• 每个办公室或通过VPN连接的员工会使用下一版的facebook，这个版本的facebook会经常更新，通常比公开的早1-12小时。所有的员工被强烈建议提交bugs，而且通常会很快被修复。
• 很奇怪只有很少的QA或自动测试——”大部分工程师都能写出基本没有bug的代码，只是在其他公司他们不需要这么做。如果有QA部门，他们只要把代码写完，扔给他们就行了”
• [针对上一条]我们有自动测试，代码发布前必须要通过测试。我们不相信”所有的工程师都能写出没有bug的代码”，毕竟这是一个商业公司。
• 很奇怪，缺少产品经理的影响和控制——产品经理是很独立的和自由的。产生影响力的关键是与工程师和工程师的领导们们搞好关系。需要大致了解技术，不要提一些愚蠢的想法。
• 所有提交的代码每周二打包一次。
• 只要多一分努力，终于一天会发生改变。
• 星期二的代码发布，需要所有的提交过代码的工程师在场。
• 代码打包前，工程师必须在一个特殊的IRC channel上。
• 运维执行打包过程
  • facebook有大约60000台服务器
  • 有9个代码发布级别
  • 最小的级别只有6台服务器
  • 星期二的代码发布会先发布到6台服务器上，运维组会检测这6台服务器的反应，保证代码正常工作，然后再提交到下一级
  • 如果发布出现了一些问题（如报错等等），那么就停止下一级的部署，提交出错代码的工程师负责修复问题，然后从头继续发布。
  • 所以一次发布可能会经历几次重复：1-2-3-fix. 回到1. 1-2-3-4-5-fix. 回到1. 1-2-3-4-5-6-7-8-9
• 运维组是受过严格训练，倍受尊敬，而且有商业意识的。他们的工作包括分析错误日志，负载和内存状态等等。还包括用户行为。
• 代码发布期间，运维组使用IRC-based页面系统，可以通过facebook/email/irc/im/sms ping每一个工程师，如果需要他们注意的话。对运维组不做回应是一件很羞愧的事。
• 代码一旦发布到第9级，并且稳定运行，就算发布成功了。
• 如果一个特性没有按时完成，也没什么大不了的，下次完成时一并发布即可。
• 如果被svn-blamed,public shamed或工作经常疏忽就很可能被开除。”这是一个高效的文化”。不够高效或者不够聪明的员工会被剔除。管理层会在6个月的时间里观察你表现，如果不合格，只能说再见。每一级都是这个待遇，即使是C级别和VP级别，如果不够高效，也会被开除。
• 被责骂不会导致解雇。我们特别尊重别人，原谅别人。大部分高级工程师都或多或少犯过一些严重的错误，包括我。但没有人因此被解雇。
• 我也没有遇到过因为上面提到过的犯错误而被解雇。有些人犯了错，他们会非常努力地去修复，也让其他人得到了学习。