按正常的作息时间，现在已经睡着了，但今天加了点班，回到家又吃吃饭喝点啤酒，就不太困了。 既然无事，就写些闲话杂谈吧，反正也好久没更新过了。
刚才看博客园一篇文章《记一次面试经历》，里面谈到zookeeper分布式协调，很高深的样子，就百度科普了一下，原来是和大名鼎鼎的Hadoop有联系的。
此处也附带几个链接，为以后查看做个标记。
分布式服务框架 Zookeeper -- 管理分布式环境中的数据
就在上一年，这些分布式之类的概念都离我很远，只存在我的念想中。因为之前是做企业或学校内部管理系统的，对分布式的需求几乎没有，或者那时候我还没有意识到什么是分布式。但自从进了互联网公司之后，会越来越多的接触这些概念。公司在成长，数据在变大，个人也要跟着成长，要不然跟不上时代的脚步就被遗弃了。现在一些数据量大，耗时的动作，为防止网页超时，需要发送指令给后台处理，还要涉及不同系统之间的信息共享，又要防止因各种错误中断，不影响任务的继续执行。这些都是现在或以后需要考虑的事。
以前觉得自己的技术还行，除了设计无感，前后端都可以，接触了更多的同事之后，发现自己的js水平还很初级。去年刚来公司时，连chrome的js调试工具也不会用，以前完全即使alert或者IE的debugger调试的。chrome的这个F12 console调试更加方便。之前我也封装过各种弹窗，表格插件，提醒等，但和新同事的比起来，规范性和维护性都有些差距，认识到不足，才能提升。
以前做查询的时候，还是一个一个的拼接字符串，是多么的浪费时光。后来发现asp.net MVC自身的Model绑定，然后利用一些ORM或泛型或反射来处理好查询条件，节约了不少精力。这是对去年的自我检讨，今年已经再渐渐改正了，逐渐采用3.0，4.5以后的操作方式，lamuda表达式，List的查询，C#的表达式树等，来提高工作效率。新版本的特性也要更多的了解。
以前听说高内聚，低耦合，只知道模糊的概念，并不知道有什么好处，也没有具体的案例来分析。现在总算有一个大体的认识了（或许也很基础）。如果新建了一个项目，要引用老项目里面的一个小接口，却需要把老项目很多地方都引用进来，一层套一层，这就是比较坑的地方。老项目有些地方耦合太深，解耦任务经过不断的尝试和修改，已经有了很大的提升。说起这里，我想起过去一个项目的二次开发，那里面一个方法里面一层套一层，最后能套几十层，再加上里面一层层的接口实现，横跨大半个仙姑，最后都不能确定某个方法是谁调的了，维护性非常差。经历了这些坑，就能理解高内聚，低耦合的重要性了。高内聚就是要模块内的各个元素尽量紧密结合，低耦合就是要各个模块之间尽量减少依赖。
工作（生活）就是不断填坑（需求）的过程，有的人懂的多，已经预先填好了，走的路就顺畅些，有的人走一步填一步，没有规划，走过的路就坑坑洼洼的，一下雨就完全瘫痪。弥补这种情况的好方式，就是多学习，多思考，多看牛人的解决办法。
计算机界有个出名的摩尔定律：当价格不变时，集成电路上可容纳的元器件的数目，约每隔18-24个月便会增加一倍，性能也将提升一倍。摩尔定律虽然不是万能的，但生活也应该像摩尔定律一样，在相同的工作时间，产出的效率和工资，约每隔18-24个月便会增加一倍。如果还没有做到，一定是还不够努力，努力学习新知识吧，在合适的情况下，多投投简历，试试自己的水平。比如金三银十阶段，即使不打算换工作，也可以试试水，毕竟如果一年半换一次工作的话，贸然提高一倍工资会心虚，但如果换成三个阶段，每半年广撒网一次，探探水，看看外界都是需要什么水平的，实时调整自己的方向，每次试投提价30%，一年半后就真的翻倍了。摩尔定律作为一种指导思想还是不错的。随着年龄的增大，步入中年期，就有瓶颈了，毕竟IT是个吃青春饭的活。
最近盛传36岁IT男加班猝死，园子里也多有文章辩论，所以大晚上的还是好好休息吧！。