随笔
看着川川熟睡的样子，看着他俩在我面前嬉闹的跑过，我总感觉特别恍惚； 不知如何和他们相处，甚至也不知如何与不知如何是好的自己相处； 于是我只好查查知乎学样子，学着做好一个为人父的样子； 在心情舒畅的时候，我放任他们自己翻箱倒柜、在地上躺水打滚、接住他们发出的各种听不懂的咿咿呀呀，想的是让他们洒脱自由地探索这个世界，给予最积极的回应；心情烦躁到收不住火的时候，也免不了大吼几声，事后愧疚不已，接应他们的目光时也有些闪躲； 如何陪伴他们让他们能够适应这个不完美的世界？如何让自己撇去浮躁能够自如的处理这一切？ 我想：生命本来就是荒凉的，生活本来就是凛冽的； 人生很长，余生漫漫； 令人心烦的工作……日渐老去的父母……还有各种空洞又悠长的忧伤…… 我想我终究对他俩还是有期待的，期待他们有明媚的性格，健硕的人格，充盈的内心，潇洒的生活； 人生很短，倏然过半； 每一天都是旧的，每一天又都是新的； 以为没什么可怀念的过去，过去却时常冒出来……总想着的未来，未来却已到来；这个世界本没有完美的事，不如意总是常态； 希望我们都够心存温柔、感念过往、一起寻找美好；
萦绕在我记忆里的老家两层楼房，总是二层左侧还没有盖起来的样子。经过危险的没有扶手的楼梯才能上二层。 不知为何：在我无数次的梦里，楼梯和二层玉制板总是摇晃不止，我虽胆战心惊却仍旧不知疲倦的跑上跑下。 小时候的美味在我的味蕾深处，从未遗忘。 夏天里的丝瓜、长豆角、苦苦的小萝卜菜……母亲做坏了长虫子的豆豉酱、到年中还有的腊鱼、腊肉；雪白雪白的猪油炒饭；豆糕、糍粑、薯片； 尤其记得薯片的做法：把红薯去皮洗干净和糯米一起蒸熟，加入橘子皮，揣成泥状，均匀摊薄然后糊在被子面上晒干，再从被子面上撕下来，成一层半透明的硬胶状的干薯皮，用剪刀剪成菱形、平行四边形的形状储存起来。吃的时候就用热沙炒熟成砖红色，吃起来夹着淡淡的橘皮香味，淡甜香脆； 5毛钱两块的麻酥、一升米加一包糖精炸出来的乐口笑……都是晚上不吃完不睡觉零嘴； 小时候村里有人家盖房子，会有大货车来送砖，我总是和村里小伙伴一起给人家搬砖，搬一车砖换取几毛钱的劳动成果；带着一身脏兮兮的衣服回家，总免不了母亲几声轻柔的责备； 但记忆里母亲从来没有责骂过我，即便教育我的时候，也只提是反面教材的别人家的孩子，于是我就知道像那样就不对； 老家里
小时候的记忆现在已经模糊了，即便有一些清晰的我想应该也仅是自己在某一些记忆碎片上『添油加醋』拼凑而成的； 我的父亲在家排行第三，前面是两个哥哥，我的大伯和二伯；家里穷只有一幢土砖房，到父亲娶我母亲的时候，只能和大伯一家共用那幢老房子；我家在房子左侧，大伯家在房子右侧，共用一个大门进入；整幢房子有几居室已经不记得了，只记得进我家屋门是一个卧室，卧室后面是厨房，而我的人生记忆放佛也是从这厨房开始的； 相比做素菜，母亲较擅长会做荤菜，那个年头的荤菜是罐子煨排骨汤、煨鸡汤；很简单粗矿的做法，罐子煨排骨汤是将盛满排骨肉加汤料的罐子放在将要烧尽的灶膛里，慢慢煨；往往是就着晚餐的灶火做，第二天吃，煨鸡汤也是同样的道理；最开心的要数快到过年的腊月二十八了，老家称这一天为还福；这一天，大家会早早在四五点就起床，父亲母亲往往会比我和妹妹起得更早，他们要忙碌祭祖的用具，在祭祖磕头的时候才叫我和妹妹起床；而在老屋里的祭祖环节已经不记得了，但记得一家四口围坐在厨房的餐桌上吃还福这一天的早晨大餐，烧豆腐、青蒜炒腊肉、油煎腊鱼干、鱼丸、肉丸、再次热好头天晚上煨好的排骨汤和鸡汤；记忆里的罐子煨好的汤上总漂着零星黑
做为系统架构师入职有一段时间了，虽然磕磕绊绊，总体来说还算有一些进步； 这里也梳理一些思考，既做总结，也为后面行事方式提出一些想法； 首先就是业务研发人员和架构师的工作职责区分； * 业务研发人员，工作职责倾向于业务需求实现，着眼于项目如期、有质量交付； * 架构师，工作职责倾向于业务需求确认，评估业务当前的、未来可能的演进状况，给出合理的系统画分、边界职责、开发规范；着眼于提高团队研发效率、保证系统的可扩展性； 一度我还是一厢情愿的想二者不应独立来看，无论从个人成长、团队整体绩效，二者应该职责合一；后来慢慢发现现实很骨干；这其中的原因，我总结如下： * 人各不同，理解问题的视角、层次不尽相同，也无法苛求一致； * 业务需求实现研发和架构合理化演进在某些层面的认知可能存在冲突； 有的人意愿沿用规则，有的人意愿创造规则；有的人被动适应变化，有的人能主动创建变化；个人的视野、思考问题的深度是受限于个人的认知；对待团队成员我们不能像对产品一样统一规格要求；这里不展开叙述； 业务需求研发强调按时按量交付，架构合理化强调研发提效和未来扩展可能，二者在某些层面可能带来冲突；症结
小时候的与人相处是一种『适应式』的，总是有样的一些困惑：张三好霸道好厉害好强硬，我要离他远一点；李四说话做事好洒脱啊， 我怎么总是唯唯诺诺、与人相处如履薄冰呢？ 职场中难免遇到一些『难搞』的人，那些『难搞』的人会让人觉得他们自大、自私又小气，不知道站在我的立场考虑问题； 总结起来戳中自己厌恶点的可能是『他不尊重我』、『他盛气凌人的态度让人很讨厌』、『他太 low』等等； 另一方面会反思或者自我怀疑『是不是我自己坐井观天一叶障目』『是不是我自己忽略了什么本质的东西』『是不是我自己也不够尊重他』，会随着矛盾的激化自我怀疑也加深，最终不能自已的退让；虽然心里也如孔乙己一般心里暗骂他这个人太差劲，骂他是『两只小蜜蜂，飞到花丛中，飞在下面的那一只』，但也改变不了现实局面的失败； 这里倒不是非要把与人相处说成『博弈』或者『较量』，但是某种程度上又确实很相似。而且很多时候确实无法跳出来这个框框思维找到一个共赢的解决办法， 觉得这就是一个零和局面。 这里可能存在如政治、利益、个人能力、或者单纯的个人喜恶各种不同的层面原因导致『横看成岭侧成峰』的现状， 但我们也必须清醒的认识到不论看成的是『岭』
java
近一年半在做物联网相关的项目，MQTT 是物联网技术中非常常见且协议。EMQ 是对 MQTT 协议实现的很不错的 Broker。当前的稳定版本是 V3.2.7； 下面我罗列一下使用中的一些实践和想法； 如何正确获得设备端连接断开事件 有三种做法： * 订阅EMQ 的系统主题$SYS/brokers/${node}/clients/{clientId}/disconnected； * 使用 web hook 插件； * 客户端使用遗愿； 第 1 种做法 可使用通配符方式只订阅一个主题，缺点就是所有客户端的离线都收到消息，需要在消费的时候再做判断，是否要关心，再触发具体的关心的设备类型的离线。 但是如果不使用通配符方式订阅的话，就得设备挨个订阅主题，这样就增加了很多订阅主题，给消息路由带来压力，是极不划算的做法； 第 2 种做法 缺点和第 1 种做法一样，收到的是所有设备的离线回调，需要在 controller
java
最近做个动态代理测试，鬼畜地写了如下代码： public interface SayHello { String say(String message); } public class SayHelloInvocationHandler implements InvocationHandler { private SayHello target; public SayHelloInvocationHandler(SayHello target) { this.target = target; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { if(StringUtils.equals(method.getName(), "say")) { System.out.println(proxy.getClass()); //打印第一行
java
Java8 往函数式编程迈入了一大步；引入了函数式接口的概念；并使用 lambda 表达式在语法上大大简化函数式接口写法； 帖上一段简单的示例代码： Runnbale run = () -> System.out.println("Hello Jack!"); new Thread(run).start(); lambda可以粗暴看作为匿名类的实现，提供了轻量级的语法上的实现，但远不止如此，比如还有改变 this 的指向； 在使用 lambda 的时候有几个要注意的地方： * 声明：函数式接口是指只有一个函数的接口，可以使用@FunctionalInterface注解来进行显示声明，这样编译器会验证接口是否满足函数接口的要求；也可以不使用@FunctionalInterface来显示声明，接口满足只有一个函数的要求即可，不包含有default默认实现的函数； * 类型推导：使用lambda的时候，简化的语法形式对指向类型变得泛化无法明确，对后续程序执行变得不安全，编译器自动根据使用上下文所期待的类型（即目标类型）来进行推导出来的具体函数式接口；例如我写了两个lambd
java
这里整理一下之前一直理解得不是很清楚的 Java 的引用； Java 开发不像 C 语言有指针，不能通过编码回收内存，完全靠垃圾回收器不定时来进行垃圾回收； 虽然垃圾回收器的工作是靠 JVM 来自动控制，但是做为 Java 程序员仍然可以通过编程在一定程序上与垃圾回收器进行交互，以帮助程序员稍微精细的控制内存回收，帮助垃圾回收器更好的管理内存的回收工作； Java 中有存在着四种引用类型：强引用 、软引用、弱引用、虚引用；四种类型的引用强度由强至弱，依次递减。 强引用 强引用是 Java 中最常见的也是最直接的引用方式，例如 Person p = new Person("Tom"); 这样的代码就会生成一个 Person对象，和一个指向此对象的强引用；通常一个对象可能有多个强引用，只要对象存在强引用，垃圾回收器就不会回收这块内存。堆中的存在强引用的对象越来越多，最终内存不够用时，JVM就会抛出 java.lang.OutOfMemoryError这个错误！ 软引用
java
周末在家，闲来无事，就想写一个服务器端自动扫描并注册，客户端自动扫描并代理的 RPC 组件，基于 Spring； 整理了一下思路，这个组件分三个部分：core、server和client；如下： 分三个步骤完成： * core：服务定义，数据序列化方式； * server：服务类自动扫描并注册、服务暴露； * client：客户端接口自动扫描并代理； 第一步 core * 服务定义：一个服务狭义地理解为一个函数，这里面就包含函数的入参数和出参；另外一个层面的问题，怎么样定位服务呢？站在 Java 角度，我使用ServiceNamespace和ServiceMapping两个注解，ServiceNamespace是一些同类服务的命名空间，ServiceMapping是具体服务入口；默认有一个 value 值，即为命名空间的名字和服务的名字； * 数据序列化方式：我这里选择了 ProtoStuff； 下面贴出相关代码： package io.http.rpc.core.annotation; import
elasticsearch
最近服务器架构扩展，涉及到 elasticsearch 的数据迁移问题，直接拷贝 {elastic_root}/data/ 目录下的数据显得过于笨拙，或者也不太可行？具体没有尝试！接着发现一个神奇的工具：elasticdump，竟然还是用 node 写的，真是太赞了！！！ elasticdump 在Github上的地址：https://github.com/taskrabbit/elasticsearch-dump 本地全局安装方法： npm install elasticdump -g 迁移analyzer： elasticdump \ --input=http://production.es.com:9200/index_name \ --output=http://new_production.es.com:9200/index_name\ --type=analyzer
comment
RFC 中有一个很特别的非技术类型的规范：RFC2119； 这个规范里规定几个常用语气词：MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL 的语气强度； 整理如下： * MUST （或者 REQUIRED、SHALL）：绝对要; * MUST NOT （或者 SHALL NOT）：绝对不要; * SHOULD （或者 RECOMMENDED）：一般情况下要，建议要，可以有例外情况; * SHOULD NOT （或者 NOT RECOMMENDED）：一般情况下不要，建议不要，可以有例外情况; * MAY （或者：OPTIONAL）：可以做，也可以不做; 在软件开发的过程中面对面的交流、