虽然之前写的评论系统也有楼中楼的实现，但是因为账户并不是对接的第三方网站，用户评论还需要手动添加邮箱用户名什么的，也无法验证是否真实。 最关键的是，我还要注意 XSS 漏洞，写个博客还要花精力在 Web 安全上面，有点不值得。 所以想想，还是使用第三方的评论系统吧。市面上看了看，感觉就 giscus 的风格跟我现在的博客风格类似，那就决定是你了。
1. 什么是 giscus？
giscus 由 GitHub Discussions 驱动的评论系统，详细介绍大家看官网就行，我使用它的原因主要就下面两个：
开源免费。这个很重要😁 使用 Github Discussion 作为存储后端，无需自行建立存储。
2. 配置 giscus
一般在用 OpenSSH 服务器的系统上进行 ssh 免密登录时，我们只需要在本地生成密钥对，将私钥留在本地，将公钥上传到目标服务器上的 .ssh/authorized_keys 就可以了。 然而 OpenWrt 上的 ssh 服务器却用的 Dropbear ，它是一种在较低内存和处理器资源的嵌入式系统中替代 OpenSSH 的软件，因此使用起来用诸多的不同。
1. 免密登录到 OpenWrt
如果本地是用 ssh-keygen 生成的密钥对，那么只需要将公钥上传到路由器的 /etc/dropbear/authorized_keys 中就行了：
cat ~/.ssh/id_rsa.pub | ssh root@192.168.1.1 'cat >> /etc/dropbear/authorized_keys'
2. 从 OpenWrt 登录到其他机器
原文地址： https://blog.tinned-software.net/change-ssh-port-in-centos-with-selinux/
Since version 4 of CentOS, SELinux is providing an additional layer of security to the Linux distribution. CentOS describes it like this: “Security-Enhanced Linux (SELinux) is a mandatory access control (MAC) security mechanism implemented in the kernel.” In other words, it controls with rules what a user or process is allowed to do.
从 CentOS 4 开始，SELinux 针对 Linux 发行版提供了一个额外的安全层。CentOS 描述其为：Security-Enhanced Linux(SELinux)是一种在内核中实现的强制访问控制(MAC)安全机制。换句话说，它通过规则控制用户或进程能都被允许做什么。
In my experience, keeping SSH on the default port 22 is a bad idea, as you will notice a lot of login attempts shortly after your server goes online. One of the actions (of course not the only one) to secure the server is to just change this port.
根据我的经验，让 SSH 服务使用默认的 22 端口是一个糟糕的主意，因为在你的服务器上线后不久你就会注意到非常多的尝试登录的记录。其中一种保护服务器安全的方式就是更换默认的 22 端口（当然你不止这一种方式）。
这道题曾经是谷歌的一道面试题，因为太过于经典，以至于谷歌取消了这道面试题。。。
1. 题目描述
给你 k 枚相同的鸡蛋，并可以使用一栋从第 1 层到第 n 层共有 n 层楼的建筑。
已知存在楼层 f ，满足 0 <= f <= n ，任何从 高于 f 的楼层落下的鸡蛋都会碎，从 f 楼层或比它低的楼层落下的鸡蛋都不会破。
每次操作，你可以取一枚没有碎的鸡蛋并把它从任一楼层 x 扔下（满足 1 <= x <= n）。如果鸡蛋碎了，你就不能再次使用它。如果某枚鸡蛋扔下后没有摔碎，则可以在之后的操作中 重复使用 这枚鸡蛋。
页面作为一种特殊的GUI软件，在前端工程中，很少提到自动化测试，业内也基本没有相对成熟的方案。 究其原因，主要是产品迭代速度实在太快，导致测试脚本无法跟上UI的快速变化，再加上人力原因，导致页面基本不做自动化测试。 虽然在产品快速迭代期，自动化测试无法落地，但是一旦进入稳定期，引入自动化测试还是能帮助较少开发成本。
1. 什么是测试？
测试其实就是在已经开发完成的软件之上采用人工或非人工的方式验证软件是否符合预期，是否会造成损失等潜在问题的一种方式。
多数情况下，前端代码都是研发手工自测，或是提测后由QA人员手工测试。
手工测试当然也是没有问题的，但是通过自动化的测试工具，可以更加快速高效且准确定位问题所在。
平时工作生活中基本都会接触到各种代理，nginx反向代理、v2ray正向代理，还有openwrt中FQ常说的透明代理。至于这三者有什么区别，下面逐一进行简单的介绍。
1. 正向代理(Forward Proxy)
首先，无特殊说明的情况下，正向代理 一般就是我们平时说的 代理。
正向代理服务器位于客户端与服务端之间，用于转发客户端请求，因此客户端需要做特殊配置。
作为一个博客爱好者，我是很喜欢RSS/Atom Feed的方式，可以很方便的订阅别人的博客、新闻等内容，经常浏览别人的博客，发现RSS Feed Reader都会显示一个添加订阅的图标，挺方便的。 但是作为一个前端开发，自己的博客居然没有RSS/Atom订阅，不能忍，果断花2小时加上再说。
1. 什么是RSS/Atom
引用维基百科的解释：
RSS （英文全称： RDF Site Summary 或 Really Simple Syndication），中文译作 简易资讯聚合 ，也称 聚合内容 ，是一种 消息来源 格式规范，用以聚合多个网站更新的內容并自动通知网站订阅者。使用RSS后，网站订阅者便无需再手动查看网站是否有新的內容，同时 RSS 可將多个网站更新的內容进行整合，以摘要的形式呈现，有助于订阅者快速获取重要信息，并选择性地点阅查看。 Atom 是一对彼此相关的标准。Atom供稿格式（Atom Syndication Format）是用于 网站消息来源 ，基于 XML 的文档格式；而Atom出版协定（Atom Publishing Protocol，简称AtomPub或APP）是用于新增及修改网络资源，基于 HTTP 的协议。 它借鉴了各种版本 RSS 的使用经验，被许多的聚合工具广泛使用在发布和使用上。Atom供稿格式设计作为RSS的替代品；而Atom出版协定用来取代现有的多种发布方式（如Blogger API和LiveJournal XML-RPC Client/Server Protocol）。 Google 提供的多种服务正在使用Atom。Google Data API（GData）亦基于Atom。
简单来说，就是RSS/Atom提供了一种统一的数据格式规范，网站可以将内容通过这种规范进行编码生成，订阅者通过RSS/Atom阅读器解析这些数据，就能实现在不打开网站的情况下实现网站内容的阅读。
不知道大家平时是怎么管理 Docker 的？是使用一大堆的窗口和命令吗？ 虽然Docker cli命令还是需要知道并熟悉的，但平时还是喜欢使用GUI工具多一点，毕竟只管的图形化界面还是符合我们的习惯的。 在开源社区里 Docker 有不少好用的图形化管理客户端，可以简化我们的工作，提供效率。 下面介绍5个比较流行的 Docker 客户端工具。
Portainer
Portainer 是开源的，是 Web 应用的形式。
github 上项目地址：https://github.com/portainer/portainer
事情的起因是因为公司的内网有一个全局的翻墙透明代理，但是使用体验不佳，而我自己是常年自备梯子的。两者同时存在的情况下经常导致有些应该能打开的网站无法打开，查看原因是因为DNS被污染了。 其次，因为经常需要浏览网页，我也不想被公司知道我访问了哪些网站(逃XD)，毕竟查DNS记录是最简单的。 所以我就查找一番资料，在本地搭建了一个防污染的DNS服务，同时也能保证内网的正常访问。
1、 方案选择
很多翻墙软件其实都内置了dns解析，但每个都不是那么好用。
以我使用clash pro为例，它的DNS配置其实还挺复杂，自己的概念比较多；其次它的DNS解析请求是并行请求，类似于smartdns，但很多时候我们并不想让所有人都知道我们要访问这个网站了；而其中最大的问题是，无法指定域名使用DNS服务。
鉴于上述问题，我们基本只剩一条路了：自建DNS服务。
事情起因就是因为我老是会折腾Openwrt，虽然每次都会做配置备份，升级之后也能快速恢复，但是网络还是会受一段时间影响，所以总是会被骂。 于是我就想，能不能建两个Openwrt实现主备，在其中一个掉线后能快速切换到另一个，保证内网网络正常，也能避免挨骂的情况出现。
1、方案选择
开始我想的是通过切换dhcp服务来实现切换，就是通过开关dhcp服务来实现，保证网络中只有一个dhcp服务。
这对于使用了dhcp服务分配IP的客户端来说应该没啥问题，但是如果客户端是static静态IP分配的话，就有问题了。因为两个Openwrt在同一个网络中，DHCP切换带来还有网关的切换，动态分配IP的客户端可以接收正确的网关地址，但是静态分配的机器还要手动修改网关地址，这显然不极客。
于是就想到了Linux下常见的主备方案——keepalived。