-
多态与延迟执行
上面的类图是针对最近改造的类图。 原先有多个command，执行各自的逻辑。现在由于command涉及的配置需要放缓存，抽象出config。config和command存在一定的映射关系，通过CommandFactory维持。考虑到config存入缓存时会以接口或者抽象类方式，取出时丢失了直接类型。使用VISITOR模式多态创建command。 现有command中有一个是条件型的，会根据执行时的上下文生成新的command并执行。在配置分离后，理论上变成生成新的config转换成command后执行。因为不想在CommandFactory中带入执行上下文（这样就破坏了简单的config-command关系），所以只能延迟到command执行时委托条件command的配置计算得到实际配置，再通过CommandFactory重新生成command，最后执行实际逻辑。 个人认为，这里理解的难点在于延迟执行。如果存在并不能立即决定的逻辑，则可以考虑返回一个实现某个接口的类，并包含执行的相关数据。比如这里返回ConditionalCommand，包含了ConditionalConfig和CommandFactory，在实际执行时计算。并通过CommandFactory的引用创建实际执行的Command后运行逻辑。
-
设计模式笔记1
设计模式的资料主要来自sourcemaking和《敏捷软件开发 原则、模式与实践》。 按照sourcemaking，设计模式主要分为 构造型模式 结构型模式 行为型模式 个人认为模式理解难度从低到高。 构造型模式 模式名 个人理解 FACTORY 由工厂决定创建哪个子类。多个子类，子类实例构造复杂时建议使用。Java中有基于static方法和新建工厂的方式。 ABSTRACT FACTORY 子类实例构造分组，比如多个“平台”，超类包含通用逻辑。“平台”与子类的实例矩阵。 BUILDER 多步创建。如果单步（方法）的参数比较复杂时推荐使用。 OBJECT POOL 对象池，典型如commons-pool，需要考虑并发问题。 PROTOTYPE 以某个实例为蓝本创建其他实例。Java中需要实现clone方法。
-
简易顺序执行框架attic开发笔记1
最近业余时间在写一个叫做attic的东西。attic的灵感来自《敏捷开发》中的验收测试，比如下面的验收测试脚本： AddEmp 1429 “Robert Martin” 3215.98 Payday Verfiy Paycheck EmpId 1429 Grosspay 3215.88 这是不懂编程的人，具体来说是业务人员也能看懂的验收测试脚本。《敏捷开发》没有对脚本的执行与实现做介绍，但是我觉得我get the point了： 按照行解析执行命令（Command） 类似CSV方式解析行，因为存在空格，不能直接按照空格split 有很多命令，需要命令库或者动态加载命令 转化为程序设计就是 val context = new CommandContext file.getLines.foreach{line => createCommand(line).execute(context) } context是命令之间交互的载体，个人认为命令之间肯定存在依赖关系 createCommand完成解析和创建命令，可能是这样： def createCommand(line: String): Command = { val cmdNameAndArgs = parse(line) val cmd = Class.forName(cmdNameAndArgs.name).newInstance.asInstanceOf[Command] cmd.setArguments(cmdNameAndArgs.arguments) return cmd } 这里cmd直接用load class的方式，便于扩展。parse部分相对难一些，我暂时用空格分割实现，之后肯定要换成类似CSV解析格式。 以上就是attic开发笔记第一部分。
-
scala模拟ketama算法
ketama是memcached客户端使用的一种一致性哈希算法。是为了解决余数实现分布不均匀的问题，在last.fm的一篇博客中首次提到。这里有一些介绍链接，其中第一篇是原博客。 http://www.last.fm/user/RJ/journal/2007/04/10/rz_libketama_-_a_consistent_hashing_algo_for_memcache_clients http://blog.csdnnet/kangojian/article/details/6708460 http://tech.idv2.com/2008/07/24/memcached-004/ 原博客里面提到算法步骤如下： Take your list of servers (eg: 1.2.3.4:11211, 5.6.7.8:11211, 9.8.7.6:11211) Hash each server string to several (100-200) unsigned ints Conceptually, these numbers are placed on a circle called the continuum. (imagine a clock face that goes from 0 to 2^32) Each number links to the server it was hashed from, so…
-
null-safe和scala的monad
长久以来，习惯了写如下的Java代码： User user = userService.get(1); if(user != null) { doStuff(); } 称之为null检查，亦有null != user的尤达式写法。 在学了Scala之后，知道了Option，改用如下写法：
-
千岛湖希尔顿游记
上周六到本周一公司旅游，去千岛湖希尔顿酒店住了两天。期间没啥事情，就是在宾馆内休息放松，看看电视，游泳、健身，玩玩WII之类的。 下面这张是从四楼，也就是吃早饭的地方拍的。下面是酒店的一楼。酒店的娱乐设施基本上都在一楼，主要有三个游泳池（一个室内，两个室外），健身房，亲子乐园和两个WII（美版破解）。
-
《七个会议》观后感
到昨天为止，我把《七个会议》全部看完了。整体来说，题材符合我的口味，结尾发人深思。虽然可能因为集数偏少（4集）的原因，感觉人物描绘不够深入，剧情展开不足。 东山大叔在电视剧中演得，个人觉得，非常不错。特别是发型，把他在整个事件过程中的憔悴状态演绎的很好。 老实说，个人当初看《七个会议》时因为题材是公司相关的，决定追一下，同期也有一部电视剧《半泽直树》，我也是抱着同样的理由追的。但两部电视剧明显是走不同路线的，《七个会议》中作为公司机器螺丝一样存在的员工，如何处理公司的丑闻和自身价值的冲突是一个很值得人思考的问题。隐蔽虽然”保护“了公司却置大众于危险之中，追求自身价值则会导致公司的信用、经营问题甚至不复存在。 剧中东山大叔演绎的课长在两种选择之间徘徊并最终选择了后者，结果和预想一样坏，但选择的过程和《半泽直数》的名言”下属的功劳是上司的，上司的错误是下属的“、”十倍偿还“不同，个人认为是”不违背自己心里的想法，即使对公司来说是痛苦的决定“。我想这正是作为一个社会人所需要坚守的理念：与其在错误的道路上越走越远，还不如回归正途无愧于心的走下去。
-
种牙记之种植手术
小时候由于蛀牙左边的一颗磨牙必须拔掉，所以手术前我左边是缺一颗牙的，而且缺的那颗牙连牙根都没有。今年和去年的体检都说要我装牙，最近反复考虑了下，为了自己的将来还是处理下，于是就开始了我的种牙记。 第一次去医院看牙之前做了一点功课，大致知道缺牙的处理方法主要有三种，一种是活动牙套，第二种是陶瓷牙，第三种是种植牙，价格逐个上升。上周周五请了一天假去医院看了口腔科，医生给出的选择也差不多，但是更详细一些。活动牙套适合老年人，我的话不用考虑。我的情况（没牙根）需要搭桥才能做陶瓷牙，价格有3000-10000不等，寿命平均十年左右。种植牙的话10000+，平均寿命20年左右。似乎选择很多，但是考虑到未来，其实我的选择只有两种：6000的陶瓷牙和10000+的种植牙。3000的陶瓷牙不做考虑，10000的陶瓷牙和10000+的种植牙价格差不了多少。后来进一步了解，陶瓷牙搭桥是要磨掉缺失牙前后的两颗牙齿，架在上面，两个被磨小的牙齿承受三颗牙齿本来应受的力。种植牙实际上是在原本牙根的地方装一个种植体，在种植体上装牙。由种植体单独受力。几天后我决定好了，种植牙，理由是平均寿命下的每年费用和对自己其他牙齿的影响。
-
从vim切换到emacs小记1
在阅读了《Unix编程艺术》之后，开始尝试emacs。据说有vi派，emacs派，但是基本没有vi+emacs派，我很好奇其中原因，但是在阅读完emacs自带的教程之后（c-h t），有点明白为什么基本没有两者都用的了。不过派系的想法终归派系，重要的还是使用方法。下面讲一下我的切换体验。 如何打开emacs 不要笑，很基础的问题。ubuntu下通过sudo apt-get install emacs安装之后，直接emacs出来的是GTK的emacs。以前没留意过是否有类似vi在CLI中的模式，最近才知道输入 emacs -nw 启动emacs的话就不会打开GTK的了。赶紧alias emacs=’emacs -nw’保存起来。
-
个人小结的Java中常见日志与异常处理实践
原本我以为日志和异常没啥东西，只要按照《Effective Java》中编码就行。但是实际情况告诉我写Java代码的人有些不知道《Effective Java》，还有些人只会依样画葫芦，甚至把错误的拼写比如accessable也一并画了下来。更让我头疼的是，两者加在一起导致的前人所有的异常都打印ERROR级别日志+抛出异常，后面的人想也不想一样的也全打ERROR级别日志+抛出异常。好吧，其实我想说打印日志也是有好的实践的，Java的异常也不是随便乱用的。 不是所有异常都需要打印ERROR级别日志 这很明显，但是似乎有人不明白什么时候不打ERROR级别日志。以下是个人建议的级别使用策略：