一指流沙，程序年华
事实上发现很难去标签化软件编码高手的特征。资深软件工程师和新手似乎看起来没啥区别，区别他们是异常困难，尤其这个群体中很多的人不愿意展现自己，他们可能藏在一个领域默默奉献着，不显山不露水。
软件开发中很多例行却看是平淡的活动，大家似乎都能做到。以产品交付为中心的文化里，人人都是螺丝钉，往往忽然一个人的价值点，很少有人能愿意去了解甚至去分析新手与高手之间的差距。软件开发中专业性总容易被主管们忽视，也因此严重影响了软件工程师追求卓越的过程。曾经发生过可怕的高层观点：精英做架构，资深做设计，随便招个高中生编码就行了。试图把软件产品开发也做成像其它物理产品一样的流水线，这多么年来证明是错误的。
五一放假正好有点时间，于是计划完成这个 Issue: Is it possible to add latex support…，要解决支持LateX，只需要集成MathJax。
在主题文件layouts/partials/script.html中增加如下，先采用了cloudflare的CDN，暂没有打包到主题目录中，国内可能稍慢些。
我司强执行力，很容易把事情做得极致，但有时过于极致反而带来不好的意外结果。我参与了公司C/Java等编程规范的评审，但让我受不了的是编程规范中条款事无巨细。连运算符或关键字之间几个空格都要写入规范，太多关于格式、命名等条款。这种在代码格式上的洁癖，可能是见仁见智。但我司的特点是一旦形成规范，就会强行执行，先是考试，再是落入到项目中，像有几个空格这种拿来考试不是折磨人吗，能使用工具解决的为什么不去开发一个工具来提升效率，而不是死记硬背的规范。
前天公司HR找我聊天，聊到问我的成就感是什么。我想表达的观点是成就感是内心一直能处于心态平和，心里踏实，不为事情所扰。尤其是作为一名技术人员，当前的工作是希望是不被打扰，不要去呈现价值，不要去讲故事而去获取更多的资源；而是把自己手上的工作尽自己最大可能努力去做好，自己问心无愧，自己也收获成长。
这似乎有点高大上，不食人间烟火；或者是一种上升到生活哲学的感悟。现实生活中，我们到处都有着功利心，成就感就是对功利的满足。人们更乐于朝着自己收益最大的方向努力，而不是原地享受安逸。个人很难超脱学古人淡泊名利，即使在相对单纯的技术体系，你也会发现人没有功利心的确是一种不容易的事情。
时间就像指间握不住的流沙，静静从身边溜走。
这些年来，我所从事的工作领域在变化，所使用的技术在变化，经历过一线比拼的激情，持续熬夜的艰辛，产品上线的喜悦，一直在公司从事基层研发工作。人生就像自己编写的程序，在程序化地运行着，但能在最好的年华，做自己最热爱的事，于我是一种幸福。
上世纪90年代，爸爸单位用电脑记账，我觉得很是神奇，买不起电脑就买了个学习机，按照说明书，用GBASIC语言输出满屏各种形状的图形，心中被巨大的喜悦填满，开始了编程的启蒙。高考那年，又被《第一次亲密接触》中互联网的桥段吸引，毫不犹豫报了计算机专业，但遗憾被调剂到信息管理专业，这两个专业之间关系不大，我与编程失之交臂了。
大一下学期买了电脑后，我开始“放飞”自己，各种操作系统只要出新的版本，我就会重装体验，此外就是打游戏，或者“泡”论坛，渐渐发现编程的乐趣，之后就在编码的路上停不下来了。参加过学校计算机编程比赛获三等奖，和室友一起搭建系里的网站，大学毕业去了一家互联网公司做程序员，直到2005年，我有幸加入华为，一晃已经十三年了。
Scala被有人戏称是 “太阳系最难的语言” ，那我们来看看他那些各种奇怪的符号使用吧，语言充满语法糖，真让人甜得受不了。一旦这些符号组合起来使用，那只能用 “惊为天书” 来形容啊。
(map1 /: map2 ) { case (map, (k,v)) => map + ( k -> (v + map.getOrElse(k, 0)) ) }
上面的看得懂吗，其实要实现的就是：合并两个Map集合对象（将两个对应KEY的值累加）。
说明：本文为学习笔记，下面内容多数来源于网上多篇文档的收集与汇总，在此感谢原作者们。
:scala中泛型使用[]指定泛型的类型参数，上下文界定是隐式参数的语法糖
: 表示上下文界定，如A：B 表示 B 可以进行隐式转化的A类型示例：
T:A:B 表示即同时满足AT这种隐式值和BT这种隐式值<: 与 :><: 表示只限定子类，如 T <: A 表示T必须为A的子类>: 表示只限定子类，如 T >: A 表示T必须为A的父类<: 与 :> 相当于java范型编程中的extends，super对泛型变量的限定。
示例：
T <: A with B 表示A和B为T上界T >: A with B 表示A和B为T下界T >: A <: B 表示同时拥有上界和下界，并且A为下界，B为上界，A为B的子类，顺序不能颠倒。一提到Cache，就想到08年我为公司写的消息缓存系统的惨痛教训。当时Redis与Memcached远还没有流行，公司对使用开源项目也是慎重，于是我和另一个同事自己撸了一个系统，但做着做着就变成一个带有强业务逻辑的Cache了。后面又扩大他的使用场景，也导致了一些问题。这个系统的要满足如下场景：
从上面的场景来，它比纯Key/Value的缓存复杂，即要高效使用内存，同一个Value缓存，存在多个Key映射，而Value只能缓存一份，Value有优先级与时序性，索引时需排序处理，又有点消息队列的诉求。
今天，我们大量在使用Redis来做缓存，Redis只作为Key/Value存储，上层复杂的缓存相关业务逻辑是在其外来叠加实现。但由于对于业务系统来说，永远都是具体情况具体分析，没有最好，只有最合适，所以也不得不要考虑通用问题：缓存穿透、缓存雪崩，缓存击穿。
昨天在公司发现采用@Aspect定义一个切面，对MyBatis的Mapper接口方法上标注自定义的注解，无法切入拦截。
Spring Cache提供了声明式的@Cacheable等注解，很方便地对Mapper接口方法来实现缓存。他们好用但简单，缓存的Key大多选择主键。但实际项目上有不少关系对象表（如下面的代码所示）；不能采用主键作为Key，因为大多数的查询场景是根据其关联的另一个字段查询。若以此字段作为Key，当存在批量插入，更新或删除时，都会影响缓存的数据。而Spring Cache的注解无法对参数为数组或List的生成Key。
于是想到自定义Cache注解来解决批量插入，更新或删除来刷新相应的缓存。对注解的拦截@Aspect声明的切面是最为简单的方式。核心实现代码如下：