前一段时间，公司某个项目组某个项目因为失误，出现了一个严重 bug，动态 SQL 导致没有 where 条件，就把数据库某张表里面的数据全部更新了，虽然事后 DBA 同学很给力的恢复了，但是运维的同学讨论，让所有的项目都不许写动态 SQL，必须根据 ID 更新，并写了一个 sonar 插件，扫描代码，发现有动态 SQL 就报 bug，不过还好暂时没有强制要求改，个人认为如果强制要求，这不就是典型的因噎废食吗？没有动态 SQL，这代码量得增加多少？我们研发要不要按照代码量算钱？前一段时间，看《即刻时间》丁奇（原名林晓斌）的 《MySQL 实战 45 讲》里面有一句话关于 sql_safe_upd[……]
明天就是十一假期了，公司也没多大事，刷知乎，看到有人吐槽曾经的一个合作伙伴连 md5 都写不对，告诉对方写错了，对方顾头不顾腚的修，还是没修对，然后测了一下自己写的想亏写对了，不然又遗留 bug 了，不过看下面评论，有人提到 Apache Commons Codec 里面都已经写好了，看了一下确实，反正也无聊，也写不了大文章，写着玩玩。
1. 先看自己手写的 md5 // 今后大家不要这么写了，太傻了
package cn.bridgeli.demo; import org.slf4j.Logger; import org.slf4j.LoggerFactory;[......]
1. json 转 JavaBean 大小写不敏感
在工作中，我个人经常使用的 json 的工具类是 Google 的 gson，前几天做一个需求的也自然而然的使用这个，但是在和其他部门联调的时候，发现他的属性全是小写，而不是刚开始约定的小驼峰，所以导致他传过来的字符串，我这边转不成 Java bean，在和他讨论的时候，他说他一直就这么写，而且别人使用的时候是没有问题的，然后就找到其他的使用的同学，他竟然说他没在意过这个问题，线上测试了一下，确实没有问题，然后就看一下怎么实现的，然后突然发现，他使用的是 alibaba 的 fastjson 转 Java bean，然后测试了一下，发现[……]
做技术转眼很多年了，也参与过很多系统的开发了，见过各种同事写的 error message，在我看来有些是非常典型的程序员思维，自己感觉一点问题都没，孰不知用户一头雾水，每次提出修改的时候，有些人还振振有词改不了，我提出自己修改意见之后，还有人说不行，前几天和我们半路出家的产品经理聊这个问题，今天闲来无事写一篇文章简单总结一下自己的想法，供大家讨论。
首先开宗明义：个人认为 error messge，不仅是提示用户为什么报错，他遇到了什么问题，而且是告诉用户如何解决他遇到的这个问题，所以个人最好的 error message 应该具备以下要素：
1. 准确
这个不是废话吗？如[……]
由于某些不可抗拒力原因，自从开博以来断更了一个月，昨天晚上突然发现竟然解封了，今天立即写一篇小文章感谢党感谢政府感谢人民。话说，这一周有一个实习的同学，在写一个小东西的时候，发现一个问题，排序没有生效，刚好之前我也看过另外一个问题，现在算是总结一下。
1. ORDER BY 不生效
代码大概就是：
SELECT * FROM t ORDER BY "id DESC";
我们其实可以很明显的看出来这个 SQL 有问题，ORDER BY 的后面多了引号，关键是这个 SQL 报错吗？如果 id 是随便写的一个不存在的列报错吗？答案是都不报错[……]
上周产品经理提了一个类似于 LBS 的应用，第一时间想到了忘记了之前什么时候看 Redis 的 API，发现 Redis 自 3.2 版本之后，新增了一类关于地理位置相关的 API，于是拿来测试一下，发现特别好用，写一个小例子作为笔记。
首先需要说明的是，由于我们公司的 JDK 的版本是 1.7，所以我采用的 spring-data-redis 的版本是：1.8.20.RELEASE，最新二点几的版本已经不支持 JDK 1.7，而一点几和二点几的版本的 API 有略微的差异（下面会说明，还有一点点我的小感悟），废话不多说，直接看例子：
@Override[......]
前几天同事分享了一些关于 Guava 的一起基础用法，我之前没用过，感觉挺好的，所以记一些常见的方法。
一. 基础工具类，字符串相关的
其实这些在 apache commons-lang3，算是重复造轮子吧，简单说一下。
1. 判断字符串是否为空，之前看到很多人自己定义，这些可能是一些老程序员吧，apache commons-lang3，Guava 的如下：
boolean nullOrEmpty = Strings.isNullOrEmpty("");
2. 补全字符串(在前面补全和后面补全)
[......]
一、CAP 理论
CAP 理论是分布式计算领域公认的一个定理，是分布式架构师必须掌握的理论，目前网上关于这块的资料也很多，各种说法，其实 CAP 理论自身也是一个不断发展的过程，相比之下比较准确的说法应该是：在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。也就是说必须是相关连接并且共享数据的分布式系统才是我们讨论 CAP 的基础，另外就是 CAP 理论关注的是对数据的读写操作，而不是分布式系统的所有功[……]
这个问题其实不能称之为问题，给服务器命名应该算是一个常识性问题，任何人都可以想到的，其实不仅是服务器，在我们生活中的一切都有名字，如果我们生活在一个没有名字的世界中，你想想有多可怕把？但为什么写这篇文章呢？因为我们公司很奇怪，不知道是运维疏忽还是啥，每次通过跳板机登陆线上服务器，必须通过 IP 地址才行，所以每个人一定要记录自己负责的服务器的 IP 地址才可以，否则一筹莫展，但是 IP 地址，大家都懂得，不然也不会有域名的存在了，大家都通过 IP 访问互联网就好了，前几天看公众号，刚好看到知书堂有位老师写过一篇文章来说这个问题，所以转载过来，供大家给服务器命名参考，后续也会给出我自己的小建议。[……]
前两天在写一个东西的时候，测试的同学说发现一个问题，排序分页，第二页和第一页有重复数据，当时我看了一下，确实有这个问题，然后就想到几年前我就曾经遇到过这个问题，淘宝数据库内核月报上也做了说明，所以这个时候就体现出了老程序员的价值：踩过的坑多，坑坑相连也就都成了平地，考虑到很多人不知道这个问题，所以把原文转载过来，以期能够让更多的人看到，原文如下：
1. 背景
6.5 号，小编在 Aliyun 的论坛中发现一位开发者提的一个问题，说 RDS 发现了一个超级大 BUG，吓的小编一身冷汗 = =!! 赶紧来看看，背景是一个 RDS 用户创建了一张表，在一个都是 NULL 值的非索引字段上[……]
近期评论