最近折腾博客比较多，也看了不少使用Hexo博主所用的评论系统，觉得Valine不错，NexT也天然支持（配置也就简单）。正想切换时发现它存在安全性问题，于是就调研了一下可用的评论系统，简单总结：
我对评论系统的需求：
这几条限制加上之后，可选项也就不多了，最终选择了Waline。本文所用版本：Hexo v5.4.0，NexT v8.5.0。
希望在Hexo的NexT主题中增加自定义分类的菜单，即一个指向特定分类的链接，且页面显示的是类似主页的标题+摘要风格。
之前有一个比较粗暴的实现：# Hexo添加自定义分类菜单项并定制页面布局。由于直接修改了源码，属于侵入式实现，导致以后升级Hexo和主题时需要手动再改代码，不推荐。
本文采用Hexo扩展简洁地定制新的分类页面布局，并解决了之前实现在升级插件或主题后需要修改源码的问题。所用版本：Hexo v5.4.0，NexT v8.5.0。
Blogroll is natively supported in NexT theme. All links will be shown in the sidebar. However, as your links increases, the sidebar length increases as well. It makes the page lengthy and distracting. Therefore, we consider creating a dedicated blogroll page.
After searching, most of the existing approaches need to modify NexT source code (theme swig template files). The implementation is a little bit complicated while breaks the theme's integrity. When you update the theme later, you will need to manually merge or rebase the master to your code.
Actually, there is a straightforward solution. Consider that we can embed html to markdown, creating a new post with customized css/html would be enough. :-)
Hexo的NexT主题可以天然支持友链，即在NexT主题的配置文件_config.yml中有一个# Blog rolls块，可以添加友链，然后在左边栏的底端会显示它们。但这样的问题在于边栏的空间有限，友链比较多的话会影响布局，而且分散主题。于是考虑单独创建一个友链页面，搜索发现已经有成型的方案，大体思路与
#
Hexo添加自定义分类菜单项并定制页面布局
一样，增加菜单项和友链模版，再修改主页模板。这样做可以解决问题，但是不够优雅，属于侵入式的定制（直接修改了主题文件模板），但绝大多数人都采用了这种方案
:-)。
有没有更简单的方案呢？有！考虑到markdown天然支持内嵌html，我们要做的只是用html写一篇新博客。
Recently I would like to simplify permanent link for each post. From:
/2021/03/21/migrateopsmanager.en/
To:
/migrateopsmanager.en/
Shorter URL is more concise and readable, as the date string makes no sense to users. But what's the meaning of URL backward compatibility?
最近一直想简化每篇博客的永久链接，现在的永久链接大概长这样：
/2021/03/21/migrateopsmanager.en/
希望能把中间的日期去掉，变成这样：
/migrateopsmanager.en/
原因在于短链接更作为标识更为合理，而URL上带有日期字符串并没有实际的用处，除非重名的博客太多。但这不可能发生，因为所有博客都写在source/_post文件夹，博客重名会引起文件名冲突。
生产环境有个SQL Server云数据库，花钱不少，性能却很差。最近发现跑一些并不太复杂的存储过程却需要好几分钟。其中一个常用的存储过程是将几张表通过一个键值关联并返回结果，这几张表都在千万级大小。分析了下执行计划，发现index seek花去了90%以上的时间，进而发现这些表的索引碎片化都极为严重。由于这个老DB几经易手，没人知道这些表和存储过程是做什么的，于是需要手动分析这些表的schema和存储过程所依赖的表。基于这些结果再对索引重建提升性能。下面就是用来分析DB的一些重要Query。
We have a costly SQL server database with bad performance. Specifically, some store procedures (join several tables on primary key, each table has ~10M rows) were executed for several miniutes. The execution plan showed that the index seek costs 90% of the total time. Finally we found the root cause is the indexes have very high degree of fragmentation. Since its DBA had changed many times, we need to analyze the database schemas, table disk usage and storage procedure dependency tables. Based on these results, we cleanup tables, store procedures and rebuild the indexes to improve the DB performance. Here are the queries to accomplish these tasks.
Recently we want to deploy MongoDB Ops Manager and MongoDB deployments in different data centers to improve disaster recovery. If they are deploymented in the same data center and unfortunately it fails, you cannot restore the backup data to a new cluster as both Ops Manager and deployments are unavailable.
Of course, we don't want to re-deploy the existing MongoDB deployments in Kubernetes. But how to make the deployments sending data to the new ops manager URL?
.NET中使用MongoDB非常简单，一般来说可以直接使用BsonDocument，也可以使用定义好的数据类型对文档进行CRUD操作。本文通过实例对比一下两种方式的优劣，通常，通过强类型Collection对文档进行操作更为便捷。