不忘初心，方得始终

背景

实际业务中，往往会用数据库自增ID来作为业务对象的唯一ID；
但数据日渐增多的互联网行业，分库分表则成了行业的通用解决方案；
此时数据库自增ID就不能满足业务需求了，行业内有各种分布式ID生成解决方案，其中雪花ID就是其中使用较多的一种。

雪花算法原理

1 基本构成

雪花算法（Snowflake）是 Twitter 开源的分布式 ID 生成算法，可以基于时间生成全局不重复的、有序的、可自增的 64 Bit 的 ID，适用于分布式系统中的 ID 生成需求。
在标准版本中由以下部分组成：
符号位（1bit）- 时间戳相对值（41bit）- 数据标志（5bit）- 机器标志（5bit）- 递增序号（12bit）
0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000
一起来一共64Bit组成，其中：
1、最高位是符号位，用于区分是正数还是负数，这里始终为0，我们用不到；
2、41位的毫秒级时间戳，41位的长度可以使用69年；
3、5位datacenterId和5位workerId，加起来共10位，最多支持32 x 32 = 1024个节点
4、最后12位是毫秒内的计数，12位的计数顺序号支持每个节点每毫秒产生4096个ID序号

2 生成ID原理

- 阅读剩余部分 -

众所周知，IDEA 自带的热加载只支持方法内的热加载，而使用 HotSwapAgent 不仅支持方法内的热加载，并且可实现新增方法的热加载，甚至是新增类的热加载，可谓是提高开发效率的神器
本文主要介绍在 IDEA 下使用 HotSwapAgent 来进行 SpringBoot 下的热部署；
接下来我们开始配置 HotSwapAgent

1 安装 DCEVM

DCEVM 是个JDK的插件，提供类似 JRebel 的热加载功能，能够在运行时重新定义加载的类，实现“热加载、热插拔、热部署”，而 HotSwapAgent 插件则是实现了 Servlet 程序的热加载功能，并且 DCEVM + HotSwapAgent 开源免费，更适合广大开发者使用。
安装 DCEVM 需要和 JDK 版本相对应，你需要先确定自己的 JDK 版本是否是 DCEVM 所支持的版本
https://github.com/dcevm/dcevm/releases
写此文时，DCEVM 支持的最新 JDK 版本是Java 8u181
如果你的JDK版本不被支持，则需要去 Oracle Java Archive 这个页面下载对应版本 JDK 并安装
https://www.oracle.com/java/technologies/javase/javase8-archive-downloads.html
下载 JDK 需要自备 Oracle 的账号
下载并安装好对应版本 JDK 后，我们再次来确定 JDK 版本为对应版本

- 阅读剩余部分 -

念念不忘，必有回响

Typecho终于迎来了v1.2.0的第二个测试版本，相信离正式版发布已经不远了！
真是有生之年系列，距离上次发布1.1版本，已经过去了4年之久...

期间虽然一直没有发布正式版本，但是Typecho的开发版本其实一直保持在活跃中，作者也一直在修复BUG和开发新的功能，只是一直没有发布新版本而已；这次作者也是鸽了好久，准备发布一个新的版本，带来了许多新特性：

具体详见：新版的Typecho开发计划

其实本站从1.1版本发布之后，一直使用的都是Typecho开发版本；
我是直接在我网站根目录下把开发版本master分支的Github项目给clone下来，然后Nginx手动屏蔽敏感文件的访问；
这样的好处就是比较方便能够保持程序与最新开发版的更新，如果作者修复了BUG，我直接执行git clone命令即可更新到最新的版本，而不用等到作者多年后发布正式版...

这次看到作者发布第一个测试版本Typecho v1.2.0-beta.1时，我就跃跃欲试去更新了最新版，但由于这次作者的改动比较大，而我也没有去手动测试，就直接头铁的在线上环境更新了程序，然后果不其然网站直接就挂掉了... ，虽然作者说这次更新会兼容以前的插件，但是我所用的众多插件还是都不兼容，博客主题也有不兼容的情况... 数据也进行了升级，网站直接打不开也没法回退版本了...

还好我有每日的自动备份（定期备份真是一个程序员的基本素养），先把网站恢复到上次备份... 看来新版本还是有很多BUG啊

经过几天测试，我将测试出来的BUG都提交到了Typecho项目的issues，作者回复的很及时，确认是BUG的话基本上当天就修复完毕，经过一周测试，作者发布了第二个测试版本Typecho v1.2.0-beta.2，此时最新版本和本站已经基本没有什么兼容性问题了，除了又拍云的UpyunFile插件有点不兼容，不过这个已经定位到BUG，作者也表示需要自己修改插件实现，手动修改一下函数调用方式即可；
又拍云插件UpyunFile适配Typecho1.2.0：https://github.com/noisky/UpyunFile

到此兼容问题全部解决，终于可以放心升级了

- 阅读剩余部分 -

最近拖延症犯了，一个文章标题写了一个月才写了个标题...

前言

自从入坑Drone CI/DI以来，我极力推荐在小微项目上使用Drone来完成自动构建，主要是轻量化，安装配置方便 ,
只需写一个docker compose文件即可完成Drone的安装配置，
只需写一个.drone.yml即可完成接入，极为方便；

Drone更深一层探究

经过我的不懈努力，经主管同意，最终也在公司项目上使用上了Drone来逐步替代Jenkins进行小项目微服务的自动构建部署 ；

但是实际使用中发现一个问题，即SpringBoot工程，通常是一个主工程下包含多个微服务子工程，使用drone不太好控制其中某一个工程的自动构建部署，总不能每次都重新构建整个服务，然后重启所有工程吧，这样效率也太低了 ；

//多工程目录结构，本文主要演示SpringBoot多工程项目自动构建部署
demoParant
├── common   //公共工程
├── api      //API工程
├── user     //用户工程
└── back     //后台工程

能想到的最简单实现的方式就是来通过不同的分支来触发不同的构建任务，这样理论上可行，但是实际操作会产生一堆分支，显得极为不整洁，并且正常开发也是开发一个分支，测试一个分支，生产一个分支，太多了操作起来也不方便 ；

所以最理想的方式也就是在同一个分支下，通过某种方式来触发不同的构建任务；

Drone的启发

在Drone CI下有一个默认功能，即在Commit log中输入[CI SKIP]即可跳过本次自动构建，于是我就想能否通过Commit log来控制本次部署具体哪个子工程，这样下来我只要在输入commit log的时候输入需要构建的工程，即可完成对应工程的自动构建部署，并且不影响同项目下的其他工程；

初步设想的原理就是在drone执行部署命令时，通过自定义脚本完成工程部署，并将commit log作为参数传入脚本，在脚本中判断commit log中是否指定某些工程的运行的参数，如果不指定则默认运行所有工程 ；

例如：我提交commit日志update Admin.java; add admin management interface; [CI API] [CI BACK];
这样一来，经过drone自动构建后，只重新部署了API工程和后台工程；

具体实现

具体实现可参考如下脚本：

- 阅读剩余部分 -

其实网站很久之前就用上了极验的滑动验证码；
不过之前的验证码是基于我自己写的API实现的，并且是纯前端实现，无法屏蔽机器自动发的辣鸡评论...
偶尔看到一个Typehco插件Geetest for Typecho --> http://zsduo.com/archives/56.html
感觉写的还不错，不过没有评论的验证码功能，就自己改了改，
保留了插件原来的后台登陆验证码，新增了评论验证码，并且适配了网站的主题 ；

普通评论

- 阅读剩余部分 -

小米新LOGO发布了，从方形变成椭圆形；
竟是花200w请日本的设计大师原研哉耗时两年制作的

本站网站图标已经使用好多年了；
既然小米图标值两百万，那咱们也来动手制作一个“价值两百万”的网站图标；

- 阅读剩余部分 -

终于终于要开始DIY自己的第一台主机辣~
其实从准备上大学的时候，就写好了配置单准备DIY自己的主机了，但是因为当时学习宿舍给分到了6人间，无奈只能买了个联想的笔记本去上大学，一用就是四年；毕业后工作拿到第一个月的工资后，又准备DIY主机来着，但是由于当时的工作环境，一年得搬家几次，无奈又买了一台小米笔记本...
现在工作相对稳定了，再不DIY自己的主机，以后怕是没得机会了...
其实现在的大环境下，DIY主机并不是很好的选择，因为新显卡太难买了，所以想着先配一台i7的主机，显卡以后再说吧...

- 阅读剩余部分 -

最近在公司测试服务器上使用acme.sh申请ZeroSSL证书，在使用EAB注册ZeroSSL账户时一直不成功，
提示Register account Error: {"type":"urn:ietf:params:acme:error:malformed","status":400,"detail":"[External Account Binding] The JWS Signature MUST be present"}
在打开Debug模式后，看到报错：Usage: _hmac hashalg secret [outputhex]
推测是OpenSSL版本过低导致算法兼容问题，遂准备升级机器上的OpenSSL版本

开始升级

1 系统环境

系统：CentOS release 6.8 (Final)
OpenSSL版本：OpenSSL 1.0.1e-fips 11 Feb 2013

2 下载最新版本OpenSSL

打开OpenSSL官网，发现最新版本为openssl-1.1.1k

//下载最新版本
wget https://www.openssl.org/source/openssl-1.1.1k.tar.gz
//解压
tar -zvxf openssl-1.1.1k.tar.gz
cd openssl-1.1.1k

- 阅读剩余部分 -

网站一直以来都是使用的Let's Encrypt SSL证书，主要是因为Let's Encrypt浏览器兼容性较好，支持ACME自动化部署，支持泛域名证书等，但是今天起网站开始放弃Let's Encrypt证书，全站更换ZeroSSL提供的SSL证书。

为什么放弃Let's Encrypt证书？

由于Let's Encrypt证书的OCSP验证域名由于未知原因无法访问，不过网站前一阵子给服务器开启了OCSP装订，变相解决了部分浏览器访问缓慢的问题；
但是经过测试，发现有些浏览器，比如IOS端 Chromium 系的浏览器：Chrome、新版Egde等，就算服务器开启了OCSP装订，还是会去强制访问OCSP验证证书有效性，虽然超时时间只有3s，但是问题没有得到解决就很不爽；
不过也没有更好的解决办法了。

并且Let's Encrypt的X3根证书也将到期，之后会使用自己签发的根证书，虽然根证书更换后OCSP无法访问的问题会得到解决，但是新的根证书时间太短导致安卓7以下以及16年以前的一些设备没办法信任这个证书导致老设备的兼容性问题；

看来只能更换SSL证书来彻底解决该问题了。

为什么选择ZeroSSL？

- 阅读剩余部分 -

1 前言

作为一个计算机爱好者，选择统一的密码还是每个软件一个单独的密码，永远是个困境；
一个人要记住太多的密码是不太现实的，保持密码以书面形式又是非常不安全的；
对于数量越来越多的账号密码，一直以来，我都在寻找一个安全、快速、方便的密码长期保存方式；
从手写笔记到手机备忘录，
从txt文档到word文档，
从自己手动备份到onedrive自动同步...

现如今比较流行的方式是使用密码管理工具进行密码的统一管理，这类软件一般拥有多平台客户端、浏览器插件等，密码一般加密保存到本地或者云端；

密码管理工具很多，有人说最好的密码管理工具是 1Password，但是他实在是卖的太贵了，暂时不考虑；
再对比各大软件，其实各有特色。有的倾向于将密码库储存到云端，有的可将密码库储存到本地进行自己保存，有的开源，有的是私有化，有的还提供私有化部署
最终我选择使用Bitwarden来搭建私人密码库，比较全的客户端覆盖，提供开源免费版，还提供私有化部署，满足了我对密码库的所有要求；

2 Bitwarden Server

- 阅读剩余部分 -