4321定律
- 家庭资产合理分配的比例是家庭收入的40%用于供房及其他方面的投资，30%用于 家庭生活开支，20%用于银行存款以备应急之需，10%用于保险。
月度归档： 2014 年 1 月
2014年1月1日 星期三
2013年就这个过去了，没有经历多少事情，还是我太健忘了，逼迫自己忘却什么。
2014年的第一天，睡到下午1点，中午又浑浑噩噩的度过。本命年的结束，感觉头好烫，好痛。晚饭随便泡点东西，一天就这么过去了。
2013年的总结呢？2014年的规划呢？我在追求着什么？我又失去了什么？
趣文：如果老婆和女朋友她们是程序
去年，我的一位朋友和他的 GirlFriend 6.0 升级到 Wife 1.0 （也就是他们步入婚姻殿堂了）。婚后他发现，结婚就是只留给其他应用少量系统资源，自己却狂占内存的进程。老婆还要生成子进程（Child Processes），子进程会在将来消耗更多的资源。虽然产品说明书或手册里没有提及这种现象，但大家都知道这些都源于自然规律。
不只如此， Wife 1.0 在安装时设置了开机启动，监测所有系统活动。朋友发现许多应用，比如，扑克之夜、啤酒狂欢、午夜酒吧 已经无法在系统上运行了，每次运行，系统就会崩溃。
Wife 1.0 安装时并未给出提示，婚后却多了岳父岳母两个插件，系统性能看起来一天不如一天。
朋友希望 Wife 2.0 版拥有如下新特性：
- “不再提醒我”按钮；
- “最小化”按钮；
- 安装时增加新选项， Wife 2.0 可以在任意时间卸载，并且不会造成缓存和系统资源损失；
- 允许网络驱动使用混乱模式，以便系统硬件探测更多有用的功能。
我本人决定继续使用 GirlFriend 7.0 ，避免 Wife 1.0 带来的麻烦，即使如此，我依然麻烦重重。很显然， GirlFriend 7.0 不能安装在 GirlFriend 6.0 上面，必须先卸载 GirlFriend 6.0。这是一个众所周知的bug，已经存在很长时间。很显然，上一版本的女朋友在 I/O 端口共享的问题上有冲突。我还以为她们已经修复好了这个愚蠢的bug。更糟糕的是，GirlFriend 6.0 卸载时在系统中留下很多不良记录。还有，所有版本的女朋友都会不断弹出烦人的提示，提醒我升级成 Wife 1.0 的好处。
Wife 1.0 有一个没有记录在案的 bug。在 Wife 1.0 卸载之前，如果你试图安装 Mistress 1.1（情人 1.1） ， Wife 1.0 会在卸载之前删除所有财富文件，然后 Lover 1.1 就会因没有足够的系统资源而安装失败。
为了避免此种 bug，就要把 Mistress 1.1 安装在另外一个系统里，并且不要使用例如 Laplink 6.0 这样的通讯软件。同时要小心那些已知携带病毒感会感染 Wife 1.0 的相似共享软件。另外一个解决办法是匿名，通过 UseNet 提供的网络运行 Mistress 1.1，再次提醒，小心那些能从 UseNet 下载东西的病毒。
技术支持的建议：
男同胞抱怨的很多常见问题，大多是源于误解。很多人把 GirlFriend 6.0 升级为 Wife 1.0 ，是因为 Wife 1.0 是最主要的实用工具和娱乐程序。实际上， Wife 1.0 操作系统被原作者设计为可以做任何事情。
从 Wife 1.0 退回 GirlFriend 6.0 是不太可能的，系统内的隐藏文件会使 GirlFriend 6.0 模仿 Wife 1.0，所以一切都是徒劳。一旦安装，就不可能从系统内卸载、删除、粉碎程序。从最初的设计上就屏蔽掉此功能。
一些人安装了 GirlFriend 7.0 或者 Wife 2.0 ，但问题比最初系统还糟糕。看看手册里的 “生活费/子女赡养费“ 警告，我建议你在 Wife 1.0下处理问题。我建议你安装后台应用程序“c:\遵命亲爱的“ 以减缓软件增大。
本人在安装完 Wife 1.0 后，建议你认真阅读“常见关系故障”章节（General Partnership Faults – GPF）。你必须为所有可能发生的过失和问题承担责任，不管其原因。最有用的是在命令行里输入 c:\我道歉。
要避免滥用“c:\遵命亲爱的“，因为有可能在系统恢复正常之前，你还得用 “c:\我道歉“ 命令。只有把所有责任都揽在自己身上，系统才能平稳运转。
Wife 1.0 是一个很棒的程序， 但是维护成本很高。为提高 Wife 1.0的性能，再买些辅助软件吧。我推荐 “鲜花 3.1”和“钻石2K“。千万不要安装”短裙秘书 3.3“，它不支持 Wife 1.0，而且会造成操作系统不可挽回的损失。
祝君好运！
技术支持部
原文链接： funny2 翻译： 伯乐在线 – 马超
译文链接： http://blog.jobbole.com/53403/
你是一个努力工作的程序员吗？还是一个懒惰的程序员？
你是一个努力工作的程序员吗？还是一个懒惰的程序员？
当一个人在完成一件体力工作时，你很容易评估他是否在努力的工作。你可以观察他的物理动作，看他流了多少汗水。你还可以看到他工作的成功：砖墙在砌高，地面上挖的坑在变大。对努力工作的认可和褒奖是人性中非常基本的本能反应。这也正是为什么人们对体力耐力体育活动如此着迷的原因之一。这种对体力上的辛苦工作的本能的赏识，在遇到管理一群技术创造型的员工时，却成了一个麻烦问题。高效的脑力工作者通常会被看作并没有在努力的工作。
早在2004年，我还是一个初级程序员，工作在一家有线电视公司，在一个大型团队中开发财务和供销系统。跟所有的大型系统一样，这个系统由很多的相对独立的模块组成，分别由一些个人或小团队负责。其中模拟电视和数字电视的财务和供销系统几乎完全独立，分别由两个团队开发。
模拟电视开发组决定在早期的微软Biztalk平台上开发他们的系统。由这个公司的4个小伙和微软的一个团队共同开发，并负责产品环境的运行。他们看起来真的工作的十分辛苦和努力。你经常能看到他们加班到深夜或周末加班。每个人都会随时放下手中的活儿来解决正式环境中突现的问题，经常会在一张桌子前一群人围绕着一个小伙，各自说出自己的见解，讨论什么地方错了，应该如何修正。工作气氛永远是热火朝天，每个人都能看到这些——即使只是经过瞟一眼，不仅仅从整个团队讲，而是他们每个人都真的真的工作的很努力。
数字电视供销系统开发团队却是完全的不同。代码几乎是由一个家伙写的，我们就叫他大卫吧。我是一个初级程序员，在团队里做维护工作。起初我在理解他的代码时遇到了很大的麻烦。他的代码里没有很长的过程，通常我的代码会把很多操作放到一起，相反，他的代码里有大量的很小的类文件和只有几行代码的小方法。好几个同事都抱怨大卫把代码搞的过度复杂了。但大卫耐心教导我，建议我去读几本面向对象编程的书籍。他给我讲设计模式，SOLID编程原则，单元测试等知识。很快，我对他的代码开始有了理解，我越研究他的代码，越欣赏这些程序中优雅的设计。这些代码放到产品环境中非常好用，运行稳定的干着它们的工作。这些代码修改起来也相当简单，因此，一些新功能的增加变得轻松容易。单元测试保证了大部分的bug都阻挡到了正式环境之外。
这些做法产生的结果就是，我们看起来完全不是在十分努力的工作。我们5点半准时下班，周末从来没有加过班，我们从来没有发生过一大群人围绕着一个人数小时的讨论正式环境中的错误是怎么发生的场景。在外人看来，我们肯定是被分配了一件相对容易的任务。但事实上，需求都是十分相似的，我们只是更好的设计和实现了这个系统，有更好的支持系统基础架构，特别是单元测试。
管理部门宣称他们要根据员工的工作表现涨薪。当轮到老板跟我谈话时，老板说只给那些工作真的努力的员工涨工资才显的公平。而我们的团队看起来对公司发展的好坏并不太在意——跟那些放弃了自己的晚上和周末的英雄们相比。
这家公司是一个稀有的实验室，你可以将好的软件设计和坏的软件设计、好的团队特征和不好的团队特征的影响效果做一个直接的对比观察。大多数的公司里不可能提供这种比较的机会。你很难说这些挥汗如雨、工作到深夜和周末、坚持冲在灭火第一线的小伙们是为了开发一个真的非常非常复杂的系统而展示了伟大的付出，还是就是一次失败。除非你有能力提供两个团队来竞争，让他们解决同样的问题，可是哪个公司愿意做这样的事情呢。相反，如何看待那些坐在角落里，朝九晚五，看着像是整天上网读什么东西的程序员呢？是他们善于写出强健稳定的代码吗？还是分配的活儿比其他人容易？在常人的眼里，前一个团队的小伙们是在努力的工作，而第二个不是。努力工作值得赞扬，懒惰可耻，不是吗？
我敢断言，表面上看起来工作很努力通常会是一种失败的信号。在高压下，在一个不断被打搅的环境中，软件开发通常是不能干好的。长时间的工作往往不是一个好的方式。有时解决一个难题的最好的方法是停止思考，出去散散步，或更好的，去睡一个好觉，让潜意识帮你解决。我最喜欢的一本书就是20世纪英国数学界领军人物G. H. Hardy先生写的《A Mathematician’s Apology》。在这本书里，Hardy先生描述他的日常规律：上午4小时的工作，下午看板球比赛。他说一天超过四小时的高强度脑力劳动都是无意义的，也是无效率的。
对于那些管理者们，我想说的是，判断一个人要看结果，要看开发出的软件的好用与否，而不是看他们表现的是如何在努力的工作。很反直觉吧，你其实最好不要坐在这些程序员中间，这样能保证你不受传统的、本能上的评判指标的影响，这样你才能对他们的产出有更好的认识。远程工作是特别有效的一种做法，你只能通常他们的产出来评判他们，而不是省事的观察他们是否8小时都坐在办公桌前对着IDE噼里啪啦的敲着键盘或“热心的”围聚在另外一个人的桌前提供着“有效的”建议。