mysql SQL_CALC_FOUND_ROWS 特性: 一条 sql 语句同时查出总数及分页结果

介绍了如何通过利用 mysql SQL_CALC_FOUND_ROWS 特性, 在一条 sql 语句里同时查出总数及分页结果

展示分页列表是一个常见的开发需求, 需要查询出总数及分页数据.

传统分页查询做法

传统上, 这个一般是通过两条 sql 去实现. 先是查询总数, 比如这样:

select count(*) from programmer where age >= 35;

然后再查分页结果:

select * from programmer where age >= 35 limit 0, 10;

如果是简单的查询还好, 但对于一些复杂的涉及很多条件的查询, 往往需要重复那些条件.

注: 在 mybatis 中, 你可以把公共的条件抽取出来做成一个可复用模块, 不过这样一来结构就相对复杂了, 也不是那么直观.

那么, 是否有方式可以避免上述麻烦, 一条语句就可以查出总数及分页结果呢? 那就要用到 mysql 里的 SQL_CALC_FOUND_ROWS 特性了.

继续阅读

利用 IDEA IDE 的轻量编辑模式快速查看和编辑工程外的文本文件

介绍了 Intellij IDEA 的轻量编辑模式, 可以用其取代诸如记事本或 Notepad++ 之类的轻量级编辑器.

作为程序员, 我们都知道 IDE 的很好用的, 它的文本编辑器功能也非常的强大, 用起来非常便捷. 在长年累月的使用中, 我们也变得对其非常熟悉, 以致于使用起其它简单地轻量级的文本编辑器来, 比如什么记事本, Notepad++, UltraEdit 等等呀, 觉得既不方便又不熟悉.

关键是很多的操作习惯或者快捷键之类的也不尽相同, 比如什么导航定位呀, 查找替换呀, 等等往往都是各有各的一套.

但有时我们又不得不用这些轻量级的编辑器, 因为有时我们仅仅是想简单查看一下一些文本文件的内容, IDE 的功能虽然强大, 但常常也是要你打开整个工程, 或者说对于工程以外的文本文件的查看或编辑就不支持了.

这种情况随着 Intellij IDEA 新版本的发布, 已经有所改变了, 这就是一个新的特性, 所谓的轻量编辑模式(lightEdit mode), 有了它, 基本可以告别其它的轻量级文本编辑器, 而全程使用 IDE 的编辑器了.

继续阅读

使用 .editorconfig 文件来统一编程风格

介绍了 .editorconfig 文件及如何使用它来统一项目的编程风格, 兼谈了一些项目管理的心得.

做过长期开发的程序员都知道保持编程风格统一的重要性, 统一的风格能够降低各种成本.

有一句名言是咋说的来着? 代码主要是给人看的, 其次才是给电脑去运行.

但另一方面, 大家又普遍是偷懒的, 对于这些长期会受益, 但短期收益不明显甚至带来麻烦的事, 许多团队中的成员不能说抵制吧, 但至少是积极性不高的.

此时, 假如你是一个团队的领导者, 怎么才能有效地保持项目中编程风格的统一呢? 下面介绍的这个 .editorconfig 文件的方式将能有效地帮助我们.

.editorconfig 文件及作用

其实它就是一个类似于 ini 之类的配置文件, 而它的名字 editor config 显然也暗示了它是用于配置(config)编辑器(editor)的.

至于前面开头的那个点".", 这个在 windows 系统下将不会有什么作用;

在 linux 之类的系统上, 这个表示隐藏文件, 因为这些配置文件通常而言不需要普通成员了解及改动, 所以设置为一般情况下不显示.

具体而言它的作用是: 帮助工作在同一个项目的使用不同的编辑器和 IDE 的众多开发者维持统一的编程风格.

EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs.

下面是一个在 IDEA IDE 中项目里该文件的截图:

.editorconfig file demo in Intellij IDEA

通常, 你至少需要在项目的根文件下放置一个.

具体配置项及含义

虽然这个文件没有后缀名(或者说只有后缀名), 但它其实就是一个普通的文本文件, 任何的文本文件编辑器都可以直接打开它.

.editorconfig file content demo

我们直接看下它的内容:

root = true

[*]
charset = utf-8
indent_style = space
indent_size = 4
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true

就是一行一行的配置项, 关于编码, 缩进, 换行等等的规定.

比如上述的 charset = utf-8 的就配置了工程的文本编码缺省都用 utf-8;

又如 indent_style = space 则规定了整个工程使用空格来缩进, 而 indent_size = 4 则规定具体缩进 4 个空格;

end_of_line = lf 则规定了使用 unix(linux) 风格的换行符(lf), 而不是 windows 回车+换行风格的 crlf;

等等...

更多的配置项及高级用法, 请参考其官网 https://editorconfig.org/.

比如, 除了在项目的根目录下放置此文件外, 你还可以在子文件夹内放置它, 以进行更细微的控制, 规则将综合起作用;

又如, 除了将缩进风格统一为 4 空格的粗暴方式外, 你还可以控制根据文件后缀名进行细微控制, 比如 js 才用 2 空格, 而 java 用 4 空格;

还支持各种通配符的设置等等, 这里不一一介绍

作用机制

当然, 你可能会好奇, 为什么在这个文件设置了这些, 它就能起作用呢?

自然, 这离不开 IDE(编辑器)本身对这些文件的支持(可能是直接集成或是通过插件的方式).

比如 Intellij IDEA 就直接集成了对它的支持, Visual Studio 也是如此;

而 Eclipse 和 Visual Studio Code 则可能需要安装插件, 在其插件库中搜 editorconfig 关键字即能找到相关插件.

后续的版本也许可能直接支持, 但目前据我所知是没有直接支持.

另: 除了重量级的 IDE, 很多轻量级的编辑器也是有插件支持的, 具体见官网介绍, 如 Atom, Sublime 之类的.

对于 IDE 而言, 一个很好的观察角度是看这个文件上的图标, 如果该文件上有特殊的图标(以及打开时有代码高亮之类的), 则说明是有相关支持的.

而如果是普通文本图标, 而打开也只是一个普通文本显示, 则说明没有得到支持, 则可能需要安装相关插件.

另一方面, 许多 IDE 本身会有这些代码风格的设置, 对于支持 .editorconfig 文件的(或是安装了插件后支持的) IDE, .editorconfig 文件配置的规则就会作用到这些设置上.

这就带来了一个好处, 无需让团队成员一一去设置, 也避免了一些成员由于犯懒或规范意识不高而不去做这些设置的问题.

引入时机及版本管理要求

显然, 通过了解 .editorconfig 文件的作用, 我们不能猜测到, 引入这个配置文件的最佳时机显然就是在项目的创建之初, 有了它, 各类规则就有了落地的具体载体, 团队成员有机会明确知道项目有哪些具体代码风格上的规范.

另一方面, 成员后续创建并提交的各类源代码文件也会受到它所配置规则的约束, 从而形成统一的风格.

如果没有一开始引入, 后期也是可以引入的, 自然, 越早越好.

而这个配置文件自然也是需要纳入版本管理(git 或 svn), 直接提交到代码仓库中的. 这样一来, 项目成员只要拉取了代码, 就能获取到这些配置了.

同时, 后续的新规则补充或旧规则调整都能很方便同步到各个成员中.

延伸思考: 如何做好项目管理

最后, 想借此机会谈谈如何去做好项目的管理. 比如你现在是一个项目的负责人, 自然, 你自己首先要有规范化的意识, 然后才能去推动整个项目朝着规范化方向前进.

可是, 任何一个有经验的管理者都知道, 事情没有那么简单, 你可能开了好几次会议, 形成了很多决议, 大家也似乎意识到了统一规范的重要, 但在后续的实际运行中, 你也还是可能发现大家慢慢又不遵循规范了.

甚至在一开始就没有遵循!

好的管理者一定是深谙人性的, 而人就是无时不刻想犯懒想省事的, 这或许是最大的人性.

很多时候, 甚至不需要去说别人, 我们想想我们自己是不是这样的?

因此, 很多事情如果你只是靠嘴去说说, 到最后你已经说到厌烦不想再说的时候, 事情最终就又还是回到老样子.

当你不想再说时, 你也犯懒了!

真要把事情做好, 你是需要一些技巧的, 这通常就表现为借助一些工具而非依赖于人的觉悟, 而这里介绍的 .editorconfig 正是这样一个工具, 有助于你达到自己的目的.

相比于各种工具与机制, 人的觉悟实在是太不可靠了, 是不值得依赖的.

另一方面, 好的管理者一定要有成本意识. 当你要做一件事情的时候, 你需要找到一个成本最低的方式, 如果你的方式需要大家做很多配合, 往往大家是不愿意的, 因为这给大家带来了成本, 而你反复去鼓动大家, 又给你带来了成本, 而最终事情却还是可能不能如你所愿.

因此, 很多时候你需要找到一个方便, 不那么麻烦的方式, 而这才能为大家所接受.

这通常也是阻力最小的方式, 而这往往又是最终成功的保障.

如果你只是在会议上对大家说, 不要怕麻烦, 长期来看这事受益很大, 但短视也是人性呀, 大家听到你的话可能不过是眨眨眼睛, 后面该干嘛还是干嘛.

把问题消灭在萌芽阶段, 这是你需要的, 也是成本最低的, 同时, 尽量少给大家带来麻烦, 甚至是大家不知不觉地就被规范起来了, 这才是最容易被接受的方案.

随风潜入夜, 润物细无声. -- 杜甫<<春夜喜雨>>

规范的透明化, 这是最高的境界, 这也是我所认为的 .editorconfig 这类工具机制背后的思想.

在技术层面, 你还能听过什么缓存透明化, 又或者什么透明地持久化, 这都表明这些东西起了作用而你甚至都没有意识到它们的存在, 无需你去关注.

任何东西, 你不主动去控制, 都可能走向失控, 这就是"水往低处流"的熵增原理, 因此管理好一个项目, 需要你的控制力.

但控制是需要成本的, 被你控制的人也需要付出成本, 因此你会遇到阻力, 怎么去平衡这些则是对你的考验:

拔最多的鹅毛, 听最少的鹅叫!

关于 .editorconfig 文件的介绍就到这里.

引入 lombok 简化代码及相关 IDE 设置

简要介绍了 lombok 的特性, 以及如何在 maven 引入和 IDE 中的设置(包括Eclipse 及 Intellij IDEA)

使用 lombok 可以简化一些样板代码的编写, 下面说说如何启用它, 包括了 maven 及 IDE 中的设置(Eclipse 及 Intellij IDEA)

具体例子

开发中经常会遇到一些纯粹作为记录的类, 如 VO, DTO 之类的, 在以往, 需要给它们一一生成所谓的 getter 和 setter. 虽然有 IDE 可以辅助快速生成这样方法, 可大量的这种简单的 get 和 set 方法的存在也是挺碍眼的, 可否简化呢?

答案是可以的, 方式就是借助 lombok 这个代理工具.

继续阅读

在开发者工具中查看响应头的字符集编码信息

介绍了如何在浏览器的开发者工具中查看响应头(Response Headers)下的 Content-type 中的字符集编码信息

要想查看某个文档的响应头中的字符集编码信息, 以 Chrome 浏览器为例, 首先打开"开发者工具":

可以按快捷键 F12, 或单击窗口右上角的选项按钮, 然后选择 "更多工具--开发者工具"即可打开"开发者工具"窗口.

如下图打开 我的网站 为例所示:

开发者工具

缺省情况下显示在原窗口下面, 可以选择最右边三个竖点的按钮, 然后在 dock side 中选择不同的显示位置.

继续阅读