行万里路，读万卷书

最近要在 Spark job 中通过 Spark SQL 的方式读取 Elasticsearch 数据，踩了一些坑，总结于此。

吾日三省吾身，记录一下近期关于工作的几点思考。

1. 好记性不如烂笔头，随手记录的习惯永不过时。

最近在做 AWS cost saving 的事情，对于 Kafka 消息集群，计划通过压缩消息来减少消息存储所占空间，从而达到减少 cost 的目的。本文将结合源码从 Kafka 支持的消息压缩类型、何时需要压缩、如何开启压缩、何处进行解压缩以及压缩原理来总结 Kafka 整个消息压缩机制。文中所涉及源码部分均来自于 Kafka 当前最新的 3.3.0-SNAPSHOT 版本。

太久没更新博客了，最近准备拾起来。为了“改头换面”，今天想调整一下 sidebar 上的头像，因为是新电脑，没有 hexo 等环境，于是按照之前分享过的一篇博文，安装 hexo，替换 source 目录下的头像图片并调整 _config.xml，本地预览一切正常，然后直接执行 hexo d 部署完成，访问网站域名 www.yangbing.club 发现直接404了，刷新了多次，用无痕浏览，等了许久再试，还是老样子，这可把我吓坏了，从未遇到过这等情况，等于博客直接挂了。

不知不觉工作已三年半，准确的说是三年零五个月。在这过程中，在技术和业务上的成长，多多少少都会有一些，但最大的收获，还是长见识。聊聊几点感受吧。

hexo是当前最火的静态博客框架，支持Markdown格式文章编辑并自动生成对应的静态网页，简单高效令人爱不释手。
使用hexo写博客的流程通常是，

1. 通过hexo new post_name命令，会自动在source/_post目录下生成一个待写的post_name.md文件
2. 编写完该md文件后，用hexo generate编译生成对应的HTML文件
3. 发布之前，可以用hexo s本地预览，然后通过hexo deploy发布到远程仓库的master分支，然后你的个人站点就能看到刚才新加的文章了

　　当我在Google输入“Long类型的比较”时，会出现多如牛毛的与这个问题相关的博文，并且这些博文对此问题的看法如出一辙，都“不约而同”地持有如下观点：

对于Long类型的数据，它是一个对象，所以对象不可以直接通过“>”，“==”，“<”的比较。若要比较是否相等，可以用Long对象的equals**方法；若要进行“>”，“<”的比较，需通过Long对象的longValue**方法。

那么问题来了，这个观点真的全对吗？或者准确地说，后半段关于“>”，“<”的说法真的对吗？起初我也差点信了，按理说Java中并没有像C++中的操作符重载之类的东东，对象直接拿来用“>”或“<”比较确实很少这么干的，而且有童鞋可能会说，既然大家都这么说，当然是对的无疑咯。那么今天笔者想告诉你的是，它是错的！Long类型可以直接用“>”和“<”比较，并且其他包装类型也同理。不信？先别急着反驳，且听笔者娓娓道来。

　　无规矩不成方圆，编码规范就如同协议，有了Http、TCP等各种协议，计算机之间才能有效地通信，同样的，有了一致的编码规范，程序员之间才能有效地合作。道理大家都懂，可现实中的我们，经常一边吐槽别人的代码，一边写着被吐槽的代码，究其根本，就是缺乏遵从编码规范的意识！多年前，Google发布Google Java Style来定义Java编码时应遵循的规范；今年年初阿里则发布阿里巴巴Java 开发手册，并随后迭代了多个版本，直至9月份又发布了pdf终极版。这两大互联网巨头的初衷，都是希望能够统一标准，使业界编码达到一致性，提升沟通和研发效率，这对于我们码农无疑是很赞的一笔福利呀。笔者将两份规范都通读了一遍，其中列举的不少细则跟平时的编码习惯基本是符合的，不过还是有不少新奇的收获，忍不住记录在此，供日后念念不忘~

　　好久没写博客啦，一晃竟已有5个月了，实在是惭愧的很，待整理的checklist还是挺多的，努力一一补上！今天这篇博文源于工作中的一个case：为Struts2中的特定action添加监控日志。对Struts2熟悉的童鞋可能会说，这个不就是常规的aop功能吗，直接利用其自带的拦截器（Interceptor）机制就可轻易实现，so easy！但最终笔者并没有这么干，为何呢？后面会说。这期间，笔者也走了好几条弯路，皆以失败告终，其中牵涉到aop代理的好一些细节知识点，以及一些常见的aop误区，如果没有这些弯路的尝试，可能都不会注意到它，故记录于此，引以为鉴。

　　Jar 包冲突是老生常谈的问题，几乎每一个Java程序猿都不可避免地遇到过，并且也都能想到通常的原因一般是同一个Jar包由于maven传递依赖等原因被引进了多个不同的版本而导致，可采用依赖排除、依赖管理等常规方式来尝试解决该问题，但这些方式真正能彻底解决该冲突问题吗？答案是否定的。笔者之所以将文章题目起为“重新看待”，是因为之前对于Jar包冲突问题的理解仅仅停留在前面所说的那些，直到在工作中遇到的一系列Jar包冲突问题后，才发现并不是那么简单，对该问题有了重新的认识，接下来本文将围绕Jar包冲突的问题本质和相关的解决方案这两个点进行阐述。