英语/日语翻译：沉浸式翻译

我的日常要看到很多英文文章和网站，因此，可以借助沉浸式翻译，帮助我快速翻译多种语言为中文，从而降低我在阅读不同语言内容的障碍。

快速搜索：超级搜索

超级搜索支持我快速的选中词汇并进行搜索，对于一些特定的场景下，会非常有帮助。比如我在浏览网页的时候，发现了一部电影，想快速在豆瓣电影中找到并标记，就可以借助超级搜索，配置一个搜索关键词来实现。

SEO 检查器：AITDK

AI TDK 是我用来检查自己的网页是否完成了一些基本的 SEO 设置的工具。当我上线了一个新的网站后，就会打开 AITDK，然后查看哪里的信息还不完整，需要补充的。就可以继续去补充相应的内容。

JSON 查看：JSON Viewer

在开发的时候，经常会有要查看服务端返回的 JSON 的情况， 借助 JSON Viewer 可以将不容易看明白的 JSON 给格式化了，方便你快速定位要看的 JSON。

广告拦截：AdGuard

广告拦截我选择了 AdGuard，有了它，我看 Youtube 再也没有广告了。。。

复制为 Markdown：Copy as Markdown

因为经常要将部分内容复制为 Markdown，方便在我的其他工具中使用，所以我安装了这个 Copy as Markdown 插件，方便自己随意复制。

页面增强：篡改猴

当我需要对一些网页做一些快速的改造，但同时又不想写成 Chrome 插件的时候，就会选择写成油猴脚本，然后放在篡改猴里来用，非常方便。

灵感记录：Memos

我自己部署了一个 Memos ，用于记录自己的灵感和想法。因此，我使用了一个 Chrome 插件，来方便我记录。

漏洞风险：可以在其他应用借助小宇宙端内跳转任何网页。

此文章发布前，小宇宙已经修复了这个问题，所以你们可能不能复现这个问题了。

先看漏洞效果，这个漏洞的问题是你可以在小宇宙里跳转到任何网站，甚至是 PornHub。不过这个 Bug 不重要，重要的是发现 Bug 的过程。

0. 背景

在一天晚上，我在和朋友聊小宇宙的 URL Scheme，想要做个功能，可以实现一键打开小宇宙的节目页面。但卡在我面前的是，我不知道小宇宙的 URL Scheme 到底是什么。于是便开始了我的 Hack 之旅，也就找到了小宇宙的这个安全漏洞。

1. 找到小宇宙的 URL Scheme

由于 Scheme 是在 App 中定义的，所以当我想到要找 Scheme 之后，第一反应的是去拿 iOS App 的 Info.plist（因为 iOS 是将 Scheme 定义在 info.plist 当中）。

过去需要通过 IPA 备份、越狱等方式来获取到这个文件，不过得益于 M 系列支持在 macOS 上运行的原因，现在 IPA 的获得变得非常的简单。 先在 App Store 安装小宇宙，并在「应用程序」中找到小宇宙。

然后右键点击小宇宙，点击「显示包内容」

然后看到这样的内容，WrappedBundle 是一个假的应用程序，所以继续点击 Wrapper 往里跳转。

然后会发现里面还有一个 Podcast 应用，这个才是真正的小宇宙的 IPA 包。然后继续点击「显示包内容」

在包内容当中可以看到 info.plist 文件，使用 Xcode 或者 VSCode 打开 info.plist 文件。

在 info.plist 文件中，搜索 CFBundleURLSchemes ，找到了小宇宙的 URL Scheme（里面有很多个，但很多都是其他应用的，试一下就可以发现）：cosmos://。

2. 找到 URL Scheme 能够打开的页面

找到了 URL Scheme，只能通过 cosmos:// 打开应用首页，无法满足我的需求，于是开始继续寻找可能的 URL Scheme 。一般来说，这个时候就只能继续反编译 IPA 包或者 APK 包了。不过对于我来说，这些不是一个好的选项（成本太高）。

然后想到，小宇宙的网页似乎是提供了打开客户端的能力，所以可以从网页版找到突破口。通过简单的搜索，果然让我在网页前端找到了突破口。找到了 7 个 Scheme 。

当然，中间存在一些重复的 Scheme。所以最终梳理出来的 Scheme URL：

• cosmos://page.cos/discover:打开发现页
• cosmos://page.cos/shownotes/EPISODE_ID：打开节目的 Shownote 页面
• cosmos://page.cos/episode/EPISODE_ID：打开节目的详情页
• cosmos://page.cos/webView?url=：意义不明，看起来像是打开一个特定的 URL
• cosmos://page.cos/web?url=:意义不明，看起来像是打开一个特定的 URL

3. 发现问题 URL Scheme

前面的三个很正常，但后面的两个带 URL 的引起我的注意 —— as a Hacker，你知道的，任何一个可能的输入框都可能成为我们的注入点，于是乎，我就构建了一个链接，来打开我的 Blog

cosmos://page.cos/web?url=https%3A%2F%2Fwww.ixiqin.com

将这个链接使用 Safari 打开，就会自动唤起小宇宙，并打开我的播客。

至此，我发现了小宇宙这个跳转注入漏洞，并快速将其反馈给小宇宙官方同学。

复盘：如何规避这样的问题

在这个 Case 当中，小宇宙因为没有设置 URL 跳转的白名单，导致实际上出现了跳转恶意网站的风险。理论上，作为应用提供商，出于安全合规的视角，最好是控制 URL 跳转的域名和空间，避免被恶意滥用。

或者也可以参考我们现在见到的很多网站，在外部跳转时加一个风险提醒。

如果在这个 Case 当中，小宇宙在一开始就限制了可以打开有限域名，那也不会出现如今我这次的漏洞问题。

这个问题风险大么？

取决于如何定义和如何使用。如果只是跳转一些常规网站，自然是风险不大的。但如果不受限制的，比如跳转到一些诈骗网站，可能风险就是大的。

本文整理了一位学霸总结的 77 条学习感悟，从小学到大学，涵盖学习方法、心态培养、学科技巧等方面。内容既有深刻的经验分享，也有幽默的现实洞察，让人读来受益匪浅。希望这些建议能给你或你的孩子的学习之路提供有价值的参考。

1、小学时代如果能写一手工整的字，具有准确的数学运算能力，OK，完美了。对以后的学业生涯够用了，所以尽量给孩子五彩缤纷的童年吧。

2、小学和中学这十二年的学习内容，都是几百年甚至几千年以前（阿基米德啊、牛顿啊、笛卡尔）人类创造的东西，思辨性不高，真的不难。

3、如果想要拿诺贝尔奖或者当选两院院士，这个要看天赋和智商，但是学那些几百年以前的东西，考个好的大学，基本和智商无关。和什么有关？情商！

4、学习不好的同学，基本都是严重拖延症患者，今天的事能拖到下个学期。（oh my god! 这真是一件恐怖的事情！）

5、勤奋永远是真理吗？！教育学理论里面有个“有效时间”的概念，看你的心用在学习上面的时间是多少。所以看到班上很多拼命学的学不好，玩的反而学的好的，不要惊讶。

6、总是期待天才，我就读的都算是不错的高中大学，读书读到现在都没有看到无师自通的天才。同学的差距是有的，差距在哪里？接受能力和专注程度，这些都是情商的范畴。

7、时代发展的当今，似乎城市里面的孩子更容易在学习方面出人才，我大学的同学只有不到三分之一的农村孩子。(寒..... [ 阅读全文 ]

前言

很久很久以前，久到我都已经快忘记了，只记得那是一个夏天，我刚搭建完个人网站并尝试接入 Google AdSense ，当时还写过一篇关于 个人网站接入 Google AdSense 心得 的文章 ，今天终于收到 Google 邮寄过来的 PIN 码了。

就一张对折密封起来的纸，皱皱巴巴的很简陋，感觉还没普通信封靠谱，难怪很多过来人会说容易寄丢呢？

好在我是顺利收到了，这篇文章就简单记录一下 PIN 码的认证过程吧！

[...]

前言

你们的博客网站有隔三岔五就收到这么多的垃圾评论吗？

这里所说的垃圾评论专指机器人通过自动化脚本或直接调用接口发起的评论，由于评论不经过前端页面，因此并不会给网站带来任何流量。说到垃圾评论，真的是非常恶心，如果仅仅是偶尔来一两条我都所谓，大不了隔段时间集中删一次，但实在架不住它短时间内狂轰乱炸，尤其是像我这样接入了邮件通知的，一旦开始，手机就响个不停，烦得要死。

[...]

前言

通过上一篇文章 如何基于 Typecho 实现中英双语网站（上），我们已经把 中英双语网站 的基本框架搭建好了。实际上很多支持多语言的网站，也就这样了，例如著名的 YouTube 就是如此，至于具体的内容显示什么语言，则完全是由内容的创作者决定的。

上一篇文章也提到了，Typecho 其实并不是很适合做多语言网站，因为，一方面需要修改源码，另一方面，开发一个不同国家的人都来发布创作内容的网站，想想也不是个人应该考虑的。 Typecho 还是更适合作者自己创作，然后向用户展示的场景，这时如果要实现多语言，就不得不将文章的内容也进行翻译了。

[...]

前言

我在前面谈 Google Adsense 的文章（如 一组数据让大家直观感受一下出海的重要性）中多次提到过，要想让网站中的 Google Adsense 有更高的收益，就一定要考虑出海，而出海就离不开多语言这个话题。理论上网站应该支持尽可能多的语言，但每增加一种语言，网站的复杂度和维护难度都会成倍增加，因此，对我们而言，性价比最高、最常用的无疑还是 中英双语网站。

比较遗憾的是，我查过一些资料，也读过 Typecho 的源码，并没有找到一种简单直接的多语言方案（直接部署并维护多个站点除外）。虽然 Typecho 本身就提供了多语言翻译功能，但需要管理员在后台切换，并且切换后会全局生效。也就是说， Typecho 并不能满足 内地显示中文，海外显示英文 这种看似简单的需求，其本质还是仅支持单一语言。换句话说，要想实现常规意义上的多语言网站，就必须修改 Typecho 源码，至少我暂时还没有找到仅扩展 插件 或 主题 就能同时支持多语言的方案。

[...]

前言

通过前面三篇文章，我们已经把个人网站接入支付宝支付时需要做的准备工作全部准备就绪了，如果还不清楚，可以先行了解一下：

1. 独立开发如何接入支付宝和微信支付
2. 独立开发者应该如何注册个体工商户
3. 为个人网站接入支付功能 - 支付宝准备篇

接下来就该正式写代码实现了，但考虑再三之后，我还是决定不过多介绍开发细节，因为这涉及到 沙箱环境 和 SDK 的使用，感觉解释起来会比较墨迹，而且想来有开发需求的人看了上面的文章之后，再自行参考官方API开发文档，思路可能会更清晰，毕竟官方文档支持在线调试，效果也更直观。
看过我往期文章的应该知道，我的网站都是基于 PHP 的 Typecho 二次开发的，因此，我这里就以 PHP 为例，简单梳理一下 电脑网站支付 的接入要点吧。

[...]

Advanced Media Offloader 提供了 Bulk Offload 功能，可以实现将历史的文件上传到对象存储中，从而降低本地的存储压力，使得站点自身变得无状态。

但其默认的 Bulk Offload 功能每次只能加载 50 个图片，如果附件太多，则需要点击 N 次，十分麻烦。

不过，可以通过简单的修改，来实现一次上传，将多个图片进行 Offload。

在 WordPress 后台的插件管理器中，找到 Advanced Media Offloader 插件，并将includes/BulkOffloadHandler.php文件打开，找到其中的 get_unoffloaded_attachments 函数，修改函数定义中的 $batch_size = 50 为你想要的大小即可使其一次批量加载多个文件了。

修改后效果：

前言

通过前面两篇文章：独立开发如何接入支付宝和微信支付 和 独立开发者应该如何注册个体工商户，我们知道，个人开发者也是可以比较简单、且体面的为自己的产品接入支付功能的。

众所周知，对接支付相对而言还是比较麻烦且敏感的，但无论是开发网站还是APP，只要涉及到支付，就很难绕开这个话题。而且不同的业务场景、产品形态，需要对接的支付方式也不太一样。不仅如此，在国内，支付至少要支持支付宝和微信两种方式，其复杂性就再一次翻倍了。

因此，接下来我将以我自己的网站为例，分两篇文章介绍一下我是如何以尽可能简单的方式接入支付宝支付的，微信支付后面再说。

当然，思路仅作参考，正式对接起来，还是应该多多查阅官方文档，官方文档才是最靠谱的。

[...]

在 使用 Caddy 处理 WordPress 当中，我提到在用 Caddy 处理 WordPress，且为了性能做了很多优化。

我的博客经历了三重优化：最基础的 PHP OpCache + Redis 数据查询缓存 + 静态化缓存。

其中一个比较有效的，便是在整个站点上加入静态化缓存，绝大多数游客看到的其实是预先生成好的静态页面，从而减少了数据库加载、渲染、计算的成本。

而想要实现静态化，则需要借助于 Cache Enabler 插件和 Caddy 配置来完成。

安装插件并启用

安装 Cache Enabler 插件，并启用插件，启用后，在后台设置中，配置过期时间和对应的清除策略，并保存。这个时候，Cache Enabler 就会自动帮你去生成不同的页面了。

配置 Caddy 路由转发

首先，你应该在你的 php_fastcgi unix//run/php/php-fpm.sock 前面加入缓存的代码并重启 Caddy，具体如下

缓存配置如下

     @cache {
		not header_regexp Cookie "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in"
		not path_regexp "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(index)?.xml|[a-z0-9-]+-sitemap([0-9]+)?.xml)"
		not method POST
		not expression {query} != ''
    }

    route @cache {
        try_files /wp-content/cache/cache-enabler/{host}{uri}/https-index.html /wp-content/cache/cache-enabler/{host}{uri}/index.html {path} {path}/index.php?{query}
    }
       

这部分配置先定义了一个 @cache 块，用于后续判断，并在其中加入了多种条件判断，说明了不使用缓存的情况：

• 如果用户有以下 Cookie，就不使用缓存：
  • comment_author（评论作者）
  • wordpress_[a-f0-9]+ （WordPress 的会话 Cookie）
  • wp-postpass（密码保护文章的 Cookie）
  • wordpress_logged_in（登录状态的 Cookie）
• 如果当前请求命中了以下路径则不缓存
  • /wp-admin/（后台管理页面）
  • /xmlrpc.php（XML-RPC 接口）
  • 所有 wp-*.php 文件（WordPress 系统文件）
  • /feed/（RSS 订阅）
  • sitemap 相关文件
• POST 请求不缓存（比如评论）
• 带查询参数的缓存不请求。

随后，通过 route @cache 定义了命中缓存部分的查找顺序：

1. 先找 HTTPS 版本的缓存：/wp-content/cache/cache-enabler/{host}{uri}/https-index.html
2. 再找普通缓存：/wp-content/cache/cache-enabler/{host}{uri}/index.html
3. 如果找不到缓存，就尝试原始路径：{path}
4. 最后尝试 PHP 文件：{path}/index.php?{query}

查看效果

打开一个无痕窗口，访问你的网站，如果在 html 底部看到 <!-- Cache Enabler by KeyCDN @ Sat, 04 Jan 2025 03:05:34 GMT (https-index.html) --> ，则说明你已经成功启用静态化缓存了！

参考资料

• 如果你使用 WP Supercache 、 WP Rocket、WP Fastest cache、W3 Total Cache，则可以参考 https://caddy.community/t/example-configure-wordpress-with-a-static-cache/8215 进行相关配置。

在用了很久的 Docker 托管 WordPress 后， 近期我把 Blog 迁移到了腾讯云的香港轻量云主机上，以获得更快的访问体验。在这次迁移后，出于 Hack 方便的目的，我将 Nginx 替换成了 Caddy。你目前访问的站点便是一个基于 Caddy 托管的 WordPress 站点。

安装 Caddy

安装 Caddy 的过程不需要太过赘述，遵循 Caddy 官方安装文档当中的指南安装即可。

安装 PHP

完成了 Caddy 的安装后，则是安装 PHP，这里我使用的是 ondrej 维护的仓库

sudo add-apt-repository ppa:ondrej/php
sudo apt update

执行上述命令安装 PPA 仓库，就可以继续执行 apt install php 来安装 php & 对应的版本。此外，记得安装相关的依赖包

apt-get install php-fpm php-mysql php-curl php-gd php-mbstring php-common php-xml php-xmlrpc -y

配置 Caddy

完成安装后，就可以正常来配置 Caddy 。得益于社区的集成和 Caddy 官方的支持，Caddy 配置 WordPress 的支持非常简单，可以直接使用 Caddyfile 格式来撰写。

example.ixiqin.com { # 这个配置是给 example.ixiqin.com

    root * /data/caddy/example.ixiqin.com # 我的网站文件都放在 /data/caddy/xxx 下，/data 是我挂载的数据盘

    log { #日志配置
        output file /var/log/caddy/example.ixiqin.com.log  # 日志路径
        format console # 日志格式
    }

    request_body { # 请求体大小
        max_size 20MB # 最大 20MB
    }

    encode zstd gzip # 支持 gzip 和 zstd 压缩
    file_server # 直接提供静态文件（比如图片啥的）
    php_fastcgi unix//run/php/php-fpm.sock # 使用 php_fastcgi 调用 php-fpm 来处理动态 php 文件。
}

只需要这样的配置，你就可以完成一个最基础的 WordPress 的站点的配置。

其他配置

对静态文件提供单独的 404 返回

按照上面的配置，其实所有的请求都会转发给 php-fpm 来处理，从而造成额外的 PHP 资源浪费。因此，可以在配置当中加入如下代码，来让 Caddy 直接返回，从而避免对 PHP 性能的浪费。

@static_404 {  
  path_regexp \.(jpg|jpeg|png|webp|gif|avif|ico|svg|css|js|gz|eot|ttf|otf|woff|woff2|pdf)$  
  not file  
}  

respond @static_404 "Not Found" 404 {  
  close  
}

配置缓存头

除了静态文件的 404 处理，你还可以在 Caddy 当中配置静态文件的缓存，从而让浏览器更多的应用缓存，减少服务器的流量，提升加载速度。

@static {  
  path_regexp \.(jpg|jpeg|png|webp|gif|avif|ico|svg|css|js|gz|eot|ttf|otf|woff|woff2|pdf)$  
}  
header @static Cache-Control "max-age=31536000,public,immutable"

前言

在上一篇文章 独立开发如何接入支付宝和微信支付 中讲到了为什么独立开发者应该注册一个个体工商户。总结来说，最主要的目的就是 为了以最简单直接、且正规的手段，解决个人开发线上支付的问题。

考虑到注册个体户流程比较简单，而且不同地区注册方式又都略有差异，本来不打算写这篇文章的，但为了确保内容的完整性，并且也考虑到很多个人开发者可能跟我之前一样，并没有了解过个体工商户的注册流程，所以，最后还是决定以自己为例，简单介绍一下吧！

[...]

前言

无论是开发网站、APP、小程序、游戏，还是一些其它类型的应用，支付都是一个十分重要的环节，但众所周知，对于个人开发者而言，这个环节却并不怎么友好，甚至可以说是一只拦路虎。这次我也花了不少时间查阅资料，并且也阅读了大量支付宝和微信的官方文档，最终确定了一条相对而言比较靠谱的方案 --- 个体工商户。

[...]

前面有朋友问，我博客评论中的外链跳转过渡页是如何实现的？其实，在 本博客的源码 中就可以很容易找到具体的实现代码。不过，为了方便理解，我还是简单梳理一下实现思路。

实际效果

先看看效果图：

上图是点击评论者头像后跳转的页面，然后点击“继续访问”就可以打开目标网站了，当然，这需要评论者在评论时填写网址才行。

该页面比较简单，是模仿“知乎”实现的，网址路径中也用到了一个 target 参数，这个比较关键，后面会多次用到，接下来看一下详细的实现过程。

[...]

我写博客经历过两个阶段 ：

1. 2012 ～ 2014 年：买虚拟主机、云主机，折腾性能和技术。在这个阶段，我的博客也经历过几轮变迁，也因为我自己没做好生产环境和测试环境的分离，导致数据丢了不少。目前的博客只能回溯到 2016 年便是因此。
2. 2016 ～ 至今：不再折腾博客，开始专注于内容写作，并且保持每年都有更新，做一个活博客。

写了十年，我也算是没少搞和 WordPress 相关的事情，不过，时间久了，脑子里那些工程师的想法，难免重新冒出来 —— 我是不是应该自己写一个 Blog 系统。对于曾经的我来说，可能是不容易的，我并没有那么丰富的开发经验。但对于如今的我来说，确实是不那么困难的事情。

不过，写总是要有个目的和收益评估，不能「为了写而写」，而是应该有一个明确的目的，评估 ROI。

我为什么想写？

• 觉得 WordPress 还是太臃肿，有不少我用不上的能力。
  • 那么我自己的 Blog 系统应该有一个明确的 Feature List。这样才能避免需求无限的膨胀。
• 我的需求已经逐步稳定下来，不太需要新的主题/插件了。
  • 这些年的确主要是更新内容，博客的形式、内容啥的，基本上都是稳定不变了。

我为什么不能写？

• 写 Blog 对于我来说没有什么特别的收益。
  • 毕竟这玩意没办法卖，除非写的过程中有别的收益，可能还好，不然大概率亏本。

我如果要写一个 Blog 系统，我需要哪些 Feature？

• 文章系统：包含标题、描述、内容、Slug、目录、标签几个核心属性和实体。
  • Slug 需要自动翻译：我特别依赖这个功能。懒得自己翻译 Slug
• 支持图片自动上传 S3
  • 我现在的图片都是用的外链，这样服务器自身的压力没那么大。
• 支持评论
  • 评论还需要能够自动发送邮件更新。
  • 评论要能实现反垃圾。
  • 历史的 600+ 评论可导入
• 简洁稳定的主题设计
  • 坦白来讲，这几年我很少做主题方面的变更了，基本上就是在几个景点主题上来回切换。
• 支持 RSS Feed 等能力
• 支持在线编写（可能非必需，最近开始逐步用 Ulyssess 写作，其实对于网页写文章的诉求越来越小了，maybe Hexo 是可接受的方案。）

在软件领域，我们有非常经典的 IaaS、PaaS、SaaS 模型，我们使用这个模型定义着我们的产品。

但另一方面，这个定义也局限了很多人的想法 —— SaaS just Software as a Service。

实际上，如果你是一个独立开发者 / 直面用户的岗位，你需要深刻的明白 —— SaaS 更大的价值不应该是 Software ，而应该是 Solution —— 用户从来不关心你是不是有 Software，用户只关心你的 Solution 能不能解决你的问题。

如果你不知道你的 Software 是在解决谁的问题 —— 不妨想想，是不是你没有找到你的Software 到底应该如何放在 Solution 当中 ，以及那个 Solution 对应的问题到底是什么。

持续关注用户的问题，尝试提供靠谱的 Solution 去解决他的问题 —— 而不是关注你的 Software。除了你，没有人真正在意你的 Software。

小时候家长或者老师要求你写日记是一回事，长大了以后自己主动要做一个blog又是另外一回事。前一件事，那是上面要求的，总有种抗拒的心理，到现在为止，如果某件事不是我主动去做，而是别人强制的，我依然会有抗拒心理。主动做一件事，出来的效果完全不一样。我觉得那些主动写日记的孩子，尤其是把纸质日记本做得很漂亮，做成了手账的孩子，他们一定不会觉得做那个东西是一个负担。当然，如果那个手账不是他们发自内心，而是被强制要求的，另当别论。现在我依然没办法理解那些在课本边边角角涂鸦各种东西的人的脑洞，为什么可以这样？所以你要我做手账，你要我在文字的前后左右画花花绿绿，贴上各种好玩的东西，甚至把那个东西搞成立体的，对我来说太难了。有时我觉得自己是一个矛盾体，首先我的脑洞完全就是一个理科生，但是在写blog这个问题上，不用其它形式，光靠文字，这感觉又很文科。因为实际上某些东西可能做个表做个图或者涂鸦一下，更能表达，但貌似我就是不太擅长用那些东西输出，文字才是我最强有力的武器。

之所以选择文字，另外一个原因可能是抠门。文字，无论是写下来还是存储下来，所占的空间都非常小。我轻而易举就可以把它们移动，把它们以各种方式保存，但如果我存下来的是图片视频又或者是其它多媒体，我就很难保证我能不能完整地把它们存下来，而且存很多个版本，因为保存那些东西要付出代价。在U盘还没有那么大的年代，只能存在硬盘里，存到一定程度就刻录成光盘，但无论是硬盘还是光盘，都会有一定的寿命，但因为那些东西可能太多，你不可能把那上传到某个地方，哪怕你已经很保险上传到很多个网盘。很早以前我就已经意识到这个问题，所以我尽量不用多媒体，但有些东西你只能用多媒体，比如橡皮章，除了图片，没办法表达那个东西。因为我的blog运营时间足够长，所以我经历了很多这样那样的丢失。图片很多，但图片放在哪里呢？BlogBus自己的空间吗？但是那里根本放不下我那么多的图片，于是我就用外链的方式，放在各种图床，结果我用的那些图层一个又一个挂掉，最终结果就是引用的那些东西，全部都不可打开。最后好不容易换到WordPress，算是自己说了算，但关键是图片太多，当你一看备份的文件，会发现原来那个东西占很多地方，占很多地方的后果就是会让我搬家非常不方便。当然了，搬家这种事不经常干，而如果我不把图片存在WordPress自己的网站里而存到外面，结果会跟之前跟那些图床一样，某一天就打不开了。归根到底，我得出了一个结论，文字是最佳的长期储存方式。

大概现在的人都比较习惯于视觉冲击，喜欢看图，喜欢看短视频，但我的经验告诉我，那些东西都是过眼云烟，很快就会被忘掉，很快就会找不到。哪怕你觉得现在你在一个比较大的服务商那里，但说不准每一天那就挂了。如果你没见识过这种，只能说那是因为你经历的时间还不够长。

我早就不在乎别人怎么看了，但我知道我正在做正确的是以前在做，现在在做，以后也要一直做。

前言

前面的文章说过，我在开发 一起学笛子 网站的时候，用的是邮箱验证的方式，这篇文章将详细介绍一下具体的实现过程。

实际上，在 一起学笛子 这个网站中，有两处用到了邮箱验证，一个是注册，另一个是重置密码（忘记密码），而且这两个地方的用法是一模一样的，所以，我接下来还是以熟悉的注册场景举例说明。

[...]

前言

前面我在 typecho如何实现前台登录/注册 一文中详细介绍了一下 前台登录/注册 的实现原理与细节，当时是以登录为例说明的，因为登录比较简单，代码量也比较少，但考虑再三之后，还是决定单独写一篇关于注册的文章，毕竟注册还是要复杂一些，而且还涉及到邮箱验证。不过，这篇文章就不再解释原理了，而是直接贴出核心代码，然后对部分要点做一些简单的解释，方便后续有需要的人可以直接复用。

[...]

前言

前面我已经写过好几篇关于 Google Adsense 的文章了，虽然收益甚微，但记录的都是亲身探索的过程，可能贵在真实吧，因此，也吸引了很多朋友的关注，其中也包括一些做的比较出色的先行者。他们无一例外，都极为重视项目出海，而我也多次提到过出海的问题，并且也一直在构思出海障碍小的项目，一起学笛子 就是这样一个项目。

[...]

前言

Typecho是一款很好的博客系统，通过 主题 和 插件 开发几乎可以随心所欲的定制自己的博客网站。但也仅限于博主编辑文章，读者阅读+评论这样的类博客网站，如果希望做更复杂的扩展，就未必能很好的实现了。

本文即将介绍的前台登录/注册功能就是一个这样的功能，虽然通过 主题 和 插件 也能实现，但二者必然紧耦合，撇脚不说，插件的通用性也是个问题。

[...]

飞书执行季 OKR 已经很久了，相比于过去的双月 OKR，我认为这确实是一个好的事情。季度 OKR 可以让我们在一个更长期的事情上来完成我们要达成的目标而无需担心自己所做的事情要更加的长远和长期，也期待更多的团队和协作方可以享受到季 OKR 的带来的长期。

但从另外一个方向来看，即使我们使用了季度 OKR，也需要关注执行的迭代。

OKR周期是我们达成目标的周期，而做事的手段则应该尽可能的敏捷和快速。快速判断、快速执行、快速复盘、快速修正。

目标大和周期长是我们要着眼于更重要、更长期的事情。而迭代的敏捷，则可以帮助我们更好更快的抵达目标。

今晚在写飞书 Bot ，遇到了一个无法解决的问题的时候，不得已，找到了飞书的 OnCall。但在聊天的一开始，OnCall 的同学便回复了「报错消息很明确了」的回复。

让我开始有点生气。

生气的点在于，作为一个专业的开发者，onCall 之前查文档我还是心里有数的，如果问题可以被解决，我就不会选择进入 onCall 的流程。这样的回复有点质疑我的专业的感觉。

但是，换个角度来思考，onCall 同学可能确实是在忙，有点不爽。可以理解。

那有没有一个更好的办法来规避这个问题？

1. 回复：「你好，这个报错文档中有对应提醒，是否已经按照文档描述调试过了？」这样的回复虽然含义差距不大，但缺少了「质疑」的感觉。
2. 直接回复错误码对应的问题（但这部分其实是需要工具支持的，比如帮助 onCall 同学提供一个快速回复的工具，降低成本）

希望各位 onCall 同学都可以规避这个问题，不要陷入 onCall 导致脾气暴躁的环节。

感谢信

尊敬的学校领导、老师们:

您好！

在这阳光明媚的日子里，我怀着一颗感恩的心，写下这封信，表达一个普通孩子的家长对XX学校由衷的热爱。

首先，我要感谢学校为我们提供了一个优美、和谐的学习环境。在这里，孩子们能够像小树苗一样，在健康的土壤中茁壮成长，沐浴着知识的雨露，汲取着智慧的阳光。

其次，孩子非常幸运分在了X年X班这个团结有爱的班集体。孩子尊重、喜欢教授X班课程的每一位老师，时常回来提及在学校学到的新鲜知识，自豪的与我们分享。

关于孩子学习情况与日常表现，与两位老师有过沟通交流，让我印象深刻。

我们的班主任XXX老师，年轻有为，对学生和蔼、耐心，可谓为人师表的典范。刚入学，孩子尚未养成良好的习惯容易丢三落四，X老师会帮忙保存学具，有时还帮送至门卫便于领取；冬季流感高发期，孩子生病请假，老师不仅关心孩子身体健康，还在复课后的课间帮孩子补习落下的课程；男孩子调皮犯错，她不会简单地责备，而是愿意站在孩子的角度予以理解并耐心地引导他们认识错误，教育他们如何以正确的行为去改正，鼓励孩子进步。X老师非常公允，她会尽量让每个孩子都有参与活动展示自己的机会，让每个孩子都能感受到被重视和认可。冬季暴雪，有幸通过线上平台听到了X老师讲授的堂数学课，课程内容生动有趣，她引导学生思考问题有方，让学生们在轻松愉快的氛围中掌握了知识点。

细节中见赤诚，春风化雨。有幸相遇。

语文XXX老师，人称“老“教师，其“老“不仅体现在她丰富的教学经验，更在于她对学生的深厚情感。孩子语文书和课堂练习本上，经常能看到她充满童趣、用心良苦的批改。每个生字的书写要领，她都能一笔一划、不厌其烦地为孩子示范。她总能洞察孩子的内心，用适当的方式激发孩子的学习热情和对知识的渴望。X老师对语文的热爱，对教学的执着，深深地景的着每一位学生，甚至每一位家长。她用自己的言传身教，让语文学习变得生动有趣，让课堂成为孩子们向往的地方。

感恩与X老师的相遇，让我们的孩子在成长的道路上，有了一位良师益友的陪伴。

感谢XX学校培养出这么多优秀的青年教师。

回想今年的“心运会”，我有幸作为家长志愿者参与其中。坐在看台，亲历校领导入场时，X书记一队领导路过主席台下方，表扬、鼓励主持活动的孩子，无形中激发了孩子参与的热情。我想，那个孩子那一刻一定备受鼓舞且受用良久。运动会过程中，X校长、X校长多次与孩子们互动，更是让我们感受到了学校领导对孩子的关怀和支持。他们用实际行动诠释了教育工作者的崇高使命，也在润物细无声中传承着教育的精髓和精神。

最后，说一下为什么想写这样一封信？因为孩子提到学校和老师的时候，险上是洋溢着发自内心的灿烂的笑容的。孩子入学一年，各方面也有明昆的进步。能够成为这个学校的一员，我感到非常幸运。

将孩子交给这样一群有爱心、有责任心的教育者，我无比放心。我相信，家校携手，我们的孩子一定能在这片沃土上茁壮成长。

再次感谢学校领导和老师们的辛勤付出，祝愿我们的学校明天更加美好!

此致
敬礼!

一年1班 XXX 家长
2024年6月

前言

前段时间，在我博客的评论区中，有几位大佬讨论到了博客要不要加 RSS 的问题，因为我自己平时是不使用 RSS 订阅的，所以就先入为主的认为 RSS 过时了，应该没什么人用了，但看他们的讨论发现似乎用的人还挺多的。

今天突然想起来这个事，因此就也试了一下，发现确实还挺方便、挺好用的，于是乎，今天就赶紧在主题中把这个功能给加上了，顺便也发了一个版本。

本来这是一个很小的功能，加就加了，但由于这里面有个小坑，所以感觉还是需要说明一下，不然估计很多人都不一定会用。

[...]

前言

前面我们已经通过两篇文章，简单的介绍了如何为开发一个自己的 Typecho 主题。我本来还想着再简单剖析一下源码，介绍一下 Typecho 有哪些扩展形式，以及预留了哪些扩展点的。但考虑到可能正如一些朋友所说的，会的人不需要看，不会的人又未必能看懂。我自己一想也对，真到了需要开发的时候，大部分情况还是会面向搜索引擎开发，遇到了问题再解决问题，反而会更容易一些。

考虑到前面的几篇文章已经基本把 Typecho 主题的开发思路说的差不多了，剩下的都是一些细节。因此，这篇文章我想干脆把我开发过程中遇到的最常见问题，进行一下梳理，方便大家需要时查询。毕竟，实话实说，Typecho 的官方文档做的确实太差了，很多东西需要翻源码才能了解。

[...]

前言

前面我们已经通过一个简单的 Hello World 主题简单了解了一下 Typecho 的主题开发过程。这次我们也不讲太多理论，而是直接还原一个相对真实的开发场景。

1. 寻找目标网站

既然是开发主题，那一定是看到了心仪的网站或者网站局部功能，希望自己也能实现一个类似的。最好不要完全凭想象实现，这样难度比较大不说，还不一定能达到预期的效果，除非你是懂设计的。技术好一点的可以直接通过浏览器开发者工具分析目标网站的源码，仿照实现。而更粗暴的方式是直接复制目标网站的源码，然后本地修改。

当然，你还可以到一些前端的模板网站下载源码，这样会比CV目标网站更简单一些，只不过这种操作往往要么收费，要么需要一些非常规手段，这里就不介绍了。

我这里就以仿百度为例，因为这个网站界面相对比较简单。

[...]

前言

Typecho 主题开发首先需要搭建PHP开发环境，可以参考 通过VS Code搭建轻量级PHP开发环境 一文，但实际上，如果你只是微调一下别人的主题，不打算自己开发，那么直接跳过这个也是可以的，因为PHP程序完全可以通过记事本编写，然后直接放到服务器上运行就可以了，不需打包、编译等一系列预处理的工作，但为了普适性，我还是得从开发者的角度来阐述这个问题。

[...]

前言

昨天写了一篇 纯 JS + CSS 手搓一个在线节拍器 的文章，主要阐述了一下实现思路，后面又想了一下，感觉好像说了很多，但又好像什么也没说，因为，高手不需要，而新手看了好像也很难因此而直接上手，毕竟 ，咱们自己也常说“Talk is cheep. Show me the code.”。

因此，这篇文章，我干脆直接把源代码从项目中抠出来，然后简化一下贴上来，这样有需要的人直接复制代码本地运行就可以了。简单、直接，不搞弯弯绕让大家自己去悟了！

[...]

在开发过程中，你可能会需要实现某些和工作日相关的特性（比如，工作日才发某些通知 /推送），这个时候，你可以借助于 chinese_calendar 这个包，来查看当前是否是工作日，你可以引入 chinese_calendar 这个包，来实现判断今天是否是工作日。

可以参考如下代码，is_workday_today 返回 True 时，就是工作日，就需要执行某些特定的逻辑。

from datetime import datetime
from chinese_calendar import  is_workday

# https://github.com/LKI/chinese-calendar
def is_workday_today():
    today = datetime.now();
    return is_workday(today)

在一开始使用 CapRover 时，我使用的是一个 10 GB 的数据盘，但在部署了诸多应用后，10GB 的数据盘已经无法满足我的需求，于是我就对其进行了扩容，扩容至 20GB。在完成扩容 & 重启后，仍需要执行 Linux 的扩容命令 resize2fs 来扩容硬盘。

但由于 CapRover 中运行的服务跑在这个数据盘上，并没有办法直接在这个数据盘上进行扩容（进程会持续读取文件），因此，需要先将 CapRover 上的服务暂停，暂停后进行扩容，并重新启动服务。

CapRover 底层是使用 Docker Swarm + Nginx 来进行的，因此，我们只需要使用 Docker Swarm 的命令，来停止服务运行即可。

1. 获取服务名称

首先，你需要先获取到当前所有在跑的服务，以便于稍后去暂停。执行 docker service ls 来获取到具体的服务名称。

2. 拼接所需的命令

在 Docker Swarm 当中，并没有直接的 Start or Stop 概念，而是通过将 Replica 设置为 0 来实现关闭的能力。这个命令可以通过 docker service scale 服务名=服务数 来实现。因此，你需要将对应的服务设置为 0 来解决这个问题。你可以先行把开启和停止的命令拼接好，从而实现快速的启动和关闭，尽可能的减少宕机时间。

如果是有多个服务，可以直接拼接在后面，从而实现一次关闭 / 开启多个服务。

# docker service scale service_name=1 service_name_2=0
# 停止命令
docker service scale srv-captain--blog-ixiqin-com=0 srv-captain--mysql-8-production-db=0 srv-captain--pgsql-16-production=0 srv-captain--redis-server-production=0
# 启动命令
docker service scale srv-captain--blog-ixiqin-com=1 srv-captain--mysql-8-production-db=1 srv-captain--pgsql-16-production=1 srv-captain--redis-server-production=1

3. 执行命令，扩容硬盘

你可以先执行停止命令，然后执行扩容命令。完成扩容后，重新启动，即可完成整体的扩容。

在开发应用的时候，我们会选择使用 PostgreSQL 作为数据库进行开发，但在 Github Actions 环境下，默认是没有 PostgreSQL 作为数据库后端的，这个时候如果你想要测试一些和数据库相关的逻辑，就不得不面临两个选择：

1. 使用一个和生产环境无关的数据库，比如 SQLite。
2. 在 Github Actions 当中添加一个 PostgreSQL。

前者是大多数常规的做法，大概率也不会出现什么问题（毕竟作为 CURD 仔，我们用的大部分时候都是一些 ORM，很少裸写 SQL），不过依然存在一些概率是你写了一些 PostgreSQL Only 的 Query 无法覆盖到测试。

另外就是本文的核心了：在你的 Github Actions 当中添加一个 PostgreSQL。

Github Actions Service

想要实现这个效果，我们依赖了 Github Actions Service Containers 这个能力。

服务容器是 Docker 容器，以简便、可携带的方式托管您可能需要在工作流程中测试或操作应用程序的服务。 例如，您的工作流程可能必须运行需要访问数据库和内存缓存的集成测试。

您可以为工作流程中的每个作业配置服务容器。 GitHub 为工作流中配置的每个服务创建一个新的 Docker 容器，并在作业完成后销毁该服务容器。 作业中的步骤可与属于同一作业的所有服务容器通信。 但是，你不能在组合操作中创建和使用服务容器。

GitHub

你可以选择你需要运行测试的环境中，找到对应的 Job，并在 Job 下新增一个 services ，即可为你的 job 设定一个依赖的服务容器，它可能是数据库 、 缓存之类的。比如我这里用的就是 PostgreSQL。

我的 Github Actions 完整参考：

• services 是我运行的服务容器。
• steps 是我的真正的测试流程。

name: Django CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

env:
  DEBUG: true
  SECRET_KEY: django-insecure-github-actions
  DB_NAME: postgres
  DB_USER: postgres
  DB_PASSWORD: postgres
  DB_HOST: localhost
  DB_PORT: 5432

jobs:
  build:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres
        env:
          POSTGRES_PASSWORD: postgres
        # Set health checks to wait until postgres has started
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
        ports:
          - 5432:5432

    strategy:
      max-parallel: 4
      matrix:
        python-version: [3.12]

    steps:
    - uses: actions/checkout@v3
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v3
      with:
        python-version: ${{ matrix.python-version }}
    - name: Install Dependencies
      run: |
        python -m pip install --upgrade pip
        pip install -r requirements.txt
    - name: Run Tests
      run: |
        python manage.py test

在开发前端应用的时候，我比较推荐在真正开始写代码之前试着画一画组件树 / 状态树。

在很多时候，可能你的设计师已经帮你做好了组件树，但在某些场景下，你的设计时并不会帮你拆解组件树，或者是你是直接和产品经理对接，他不会帮你拆解组件树。

这个时候，相比于写代码，我更推荐你先拆解组件树，在完成组件树之后，再开始你的 Coding。

Figma / Sketch 之类的软件提供的分组能力、图层的能力，可以帮助你将组件合理的拆解、分组、归类。当你完成树的建设之后，可以试试看将不同的模块拆解，每个模块是否可以独立正常的运转。如果不可以，则说明你的状态拆解的可能是有问题的。

当你完成拆解之后，只需要按照你拆解出来的树组织你的 Component 即可。

在前端留存一些状态，是在前端场景下提升性能的常规操作。最近我有一个场景需要在前端留存一个状态，借着这个机会，试了试 IndexedDB 来作为数据存储，拓展一下新的方向。

关于 Indexed DB

Chrome 在中提供了多种不同的存储，按下 F12 ，打开 DevTools ，找到应用 – 存储，你就会看到目前 Chrome 支持的多种存储方式。常用的主要就是本次存储空间（Local Storage）、会话存储空间（Session Storage）和 Indexed DB。这次我用的便是 Indexed DB。

开发使用建议

由于 Indexed DB 提供的 API 整体比较裸，在实际应用开发时，可能并不好用，你可以根据自己的需要，选择使用不同的第三方开发库来开发你的应用。在这篇文章中，我使用了 idb-keyval 来作为我的开发库。

用法

首先，使用 yarn add idb-keyval 来安装依赖，安装完成后，可以参考如下代码来在你的项目中引入 indexedDB.

import { set,get,keys } from 'idb-keyval';


// 下面演示了一个 get_books 函数，会将内容存储在 IndexedDB 的 your-keys 当中。
// 如果存在缓存，则直接使用缓存，不存在，则进行数据获取
function get_books(){
   // 使用 keys 获取当前 IndexedDB 当中的所有 Key，用于判断当前是否有缓存结果。
   const exists_keys = await keys();
   if(exists_keys.indexOf('your-keys') !== -1){
    console.log("use cached glossary")
    return await get('your-keys');
   }

   // fetch data
   let data = fetch_data();
   
   await set('your-keys',data)
   return data;
}

使用前后的效果

在性能上，使用 Indexed DB 之后，根据你的数据获取的难度，会有不同的性能提升。比如这里我不使用缓存，单次数据获取需要花费 800ms，借助于 Indexed DB，时间可以被控制在 10ms 以内，从而得到一个不错性能。

以前我从来没有觉得检查这东西有多么令人厌恶，那只会让我紧张。现在随着检查频率越来越高，范围越来越广，我开始厌恶这个东西了。在没有检查之前做好自己的事情也就完了，别人要你做什么你就做什么，但是当被检查的次数越来越多以后，发现情况远没有那么简单。因为对方要求给出的数据不按常规的套路出牌。平时我们各自完成ABCD四项任务，某些检查需要我们提供的数据是A和B联合，再加C的部分，然后是在D的条件之下。你还不能把ABCD全盘托出给他们，你必须按照他的条件把ABCD融合在一起，这个东西就很让人绝望。为什么要提出这样的要求呢？因为他们检查的角度和我们工作的角度不一样。他们从一个点发散开来，相关的东西全部都得要，而我们的工作实际上是至上而下一级一级深化，到最后就变成了ABCD四款由1234四个人完成，各自独立。所以这到底是他们的问题还是我们的问题？我感觉，如果有一套系统把这些都联合起来的话，什么问题都没有。我们做我们的，做好我们的事，自动关联就已经结成了。他们检查，想从什么方面钻取是他们的自由。现在的实际情况是，没有系统，没有预先的联合。1234这四个人之间从来没有什么交集。光是交出最后的那份数据，从谁开始然后到谁，由谁去加工，这些关系已经让人觉得足够迷糊，就更不用说有些部分可能是互相关联的，就一条桥而已，搭上了就解决了，但关键是谁也不愿意搭这条桥，谁都觉得那不应该由我去做，应该由别人去做。

工作是这样，检查是那样，退一步会观察这件事。实际上很多东西早就应该摸出对应关系，然后通过引用而不是通过重复工作的方式自己干自己的。基层的烦恼在于，上面总是要我们提供数据，但实际上那些数据翻来覆去，已经提供了无数遍，上面的这个部门要这样的，那个部门要那样的，实际上原始数据都是一个东西，上面也做了一些系统的玩意，也的确要求我们把一些数据之类的东西都通过人工的方式转化上去，但问题是他们中的有些人根本没想过我们上传的明细数据和他们所要的那些汇总数据的关系，所以每当上上面要求某些汇总数据的时候，还是要基层的人按照上上面的要求重新提供。我不知道为什么上面的人就不能从基层的角度考虑一下这件事情到底该怎么做。上上面有什么要求，上面的人就得让基层的人提供数据，其实这个工作也很累。如果基层的人反馈不及时，更加会让中间的人像热锅上的蚂蚁一样急得要死，一点办法都没有。如果一开始就想清楚关系，直接抓取数据，基层的人只管生产正确的数据，中间的人想好要用什么方式汇总来应对上面人的各种奇怪要求。要做到这样，中间的那些人对上面和下面都得非常熟悉。好像到此为止，从来没有一个人敢站出来，承担这个责任，所以现在的状况就是上面下达指令的时候层层逼迫，出现问题的时候层层推卸责任。

的确有方式让大家都舒服，但得先有人多做一些。

在当代美国最鼓励哪种育儿方式一文中，果果日记翻译介绍了美国当前流行的几种育儿方式，可以大致的分类为：1、权威型（恩威型）；2、专制型；3、放养型；4、忽略型。其中权威型是最受欢迎也使用最多的教育方式，它比较契合当下生态环境，今儿就来详细介绍权威型教育（也称民主型）父母的特点和可能的影响。

权威型父母的特点是要求合理、反应迅速。 权威型父母对孩子的期望可能很高，但他们也会给予孩子成功所需的资源和支持。这种风格的父母会倾听孩子的心声，除了限制和公平的管教外，还会给予孩子爱和温暖。 这种教..... [ 阅读全文 ]