无论是被裹挟进也好，还是主动跳入也好，总之已经身处 AI 浪潮中。

依旧记得年初天天刷推时面对时新日异 AI 相关最新动态时的焦虑心情，然后是各种玩得不亦乐乎：

自己搭好 Stable Diffusion 研究各种底模、Lora 只为画出更赏心悦目的美女；用自己照片训练模型画一个六十岁的自己；扒 Stable Diffusion 源码创建自己的 AI 绘画服务……

六月开了 ChatGPT Plus，开始能稳定地用上 GPT-4。然后启动了一部关于 AI 的科幻小说写作，目前已完成十三万字。

下半年陆续完成了 macOS、Windows、iOS/iPadOS 版的 Effie AI，终于将 AI 技术落地到了我们手中相对已经比较成熟的基础设施——Effie——中。目前的文本生成类 AI，最直接最擅长的应用场景，毫无疑问正是在文字处理方面。将 AI 技术通过我们的效率工具融入用户的生产力流程中，无疑是 Effie“把思想变成价值”这一初衷的更完美体现。

人生进入下半段，时间的流速快到时常让人怀疑其是否真的存在过。只有每年此时回顾一年来的成果，盘点增加的代码行数，才能让自己确信，这一年确实曾经经历过。

2023年最后一周，在感冒与失去味觉中度过。

上周六下午，刷 https://nicrosoft.net/blog/ 时，突然刷出了 404。SSH 登录上服务器，才发现久未关注的服务器上，WordPress 网站目录下已经遍布了 wpconfig.bak.php 这样的黑客留下的恶意文件。

因为这台服务器上的网站一直运行良好，就很久没有关注过它了。所以，在备份了日志后，当即还是决定彻底重装整个系统。这台机器上主要都是我个人相关的网站，没有什么重要的在线服务，因此也就断断续续花了好几天，才把所有环境都恢复起来了。小说也断更了好几天了。

之后，还在 MySQL 数据库里，发现了黑客添加的几个 WordPress 管理员帐号。

所以，最后决定好好增强一下 WordPress 的安全性。WordPress 自身，以及因为支持各种良莠不齐的插件，安全性一直是被诟病的。之前觉得自己的网站没什么人关注，应该不值得成为黑客目标，当然也是对自身运维方面有一定的信心，尤其是一直稳定运行了超过十年，所以就真的大意了。

亡羊补牢，经过对被黑网站的日志的分析，黑客的行为大致还是有迹可循的。对于 WordPress 架设的网站，我建议：

1. 尽量不安装，或者少安装第三方插件。并不是说，用的人越多，越流行的插件就没问题。流行度越高的插件，被黑客研究利用的可能性也越大。插件开发者水平参差，不见得每个插件都能在安全性上下足功夫。
2. 自己配置 web 服务器，比如 nginx，要禁止在敏感目录（比如 /wp-content/uploads/）执行 php 文件。可以在 nginx 的网站配置中增加类似下面这段：

location /wp-content/uploads/ {
    location ~ .*\.(php|php5)?$ {
        deny all;
    }
}

3. 配置禁掉 /xmlrpc.php：

location = /xmlrpc.php {
    return 403;
}

4. 监控网站目录中文件的异常变动，比如增加了什么奇怪的文件。
5. 监控网站的数据库中用户数量的异常变动，比如增加了奇怪的管理员权限的账号。

关于上面第4、第5两点，我准备写一个监控工具定时自动执行来完成。昨天已经在 github 开了新项目：https://github.com/shenmin/wpsec_mon

目前完成了监控数据库中用户数量的异常变动，发现增加了可疑账号时，发送邮件通知。定时执行则借助系统的 cron 服务即可。后续还会继续做下去，把文件监控完成。

2022年过得着实乏善可陈：春天被封城整两个月；夏天被40+摄氏度连续烘烤了近两个月；秋天被带状疱疹折磨了近一个月；冬天全家阳了一个星期。

如果非要找一些积极的：春天在封城中完成了 Effie 对图片的支持；夏天儿子考上了他理想的高中，我把家里的11年前配置的PC更新换代了；秋天完成了 Effie 的 Android 版本；冬天全家阳过了，始终令人惶惶不安的封控式防疫终于结束了。

时间已经踏入2023年，但又似乎并没有什么让人期待、令人兴奋的。

2012年10月长假后全家从珠海回到上海，至今已有十年。

十年前，可乐还是个幼儿园大班的小朋友，现在已然是人高马大的高一学生。这十年间，有过紧绷的创业，有过放松的生活，有过面临老人病倒的无措，也有安稳的苟且，以及面对疫情的无奈……

而不变的，是键耕不辍的敲代码。十年前，和李自然合作开启，以及合伙创业做 Mera，项目遗憾地失败了。最近的两年多，再次和李自然合作，全情投入了 Effie 这个项目。两年多写了四大平台（macOS、iOS、Windows、Android）的编辑器和思维导图，近30万行代码，如果要我再写一个平台的编辑器，真的会吐了吧。全部原生实现，就是会面对这样的境地，需要无比的耐心——面对时间、金钱以及精力的全方面考验。幸运的是，李自然给了足够的耐心，我也算不辱使命，Effie 全平台的里程碑基本达成了。

成功的合作，基础无非是互相成全。感谢。

疫情已经三年，今年实实在在地捶打到了上海。全城2500万人封控61天，以及全国大小城市、乡镇陆续的封控和所谓静默，已经彻底颠覆了人生前四十多年的认知——活久见。

无论是人到中年的自己，还是社会，似乎都已经告别了那个蒸蒸日上的年岁。叹息。

除夕（在家陪老婆孩子）、初一（早上送老婆孩子去机场回她老家）休息了两天。昨天初二，正好也是我为 Effie 工作两周年，我自己的虎年开工。

公司里只有我一个人，其实这样的环境对我来说还是挺舒服的，毫无干扰。正好这段开发工作也不太需要别人协作，可以一个人静静地码代码。只是已经连续一个多星期的阴雨天，让人阳光不起来。

2021年1月6日 Effie 1.0 发布，5月2日完美适配 iPad，8月26日发布完全重写的原生 Windows 版，冬至日 Effie 海外版上线。这一整年，除了支持平台的增加，Effie 本身的功能也在不停完善。马不停蹄的这一年，同时也带来了用户数量、满意度的不断增长。Effie 的发展仍处于起步阶段，产品、平台层面仍然存在缺口，所以2022年的计划已经排满。

专心于开发能为自己带来成就感和收益的软件产品，无疑是快乐的。

2020年减重12+kg之后，2021年成功保持了减重成果，体重没有增加，维持在了 73kg 左右，达成了年初立下的 flag。

一定的自律加上喜欢的饮食、运动方式带来的比较理想的体重和能察觉的充沛精力，以及不油腻的中年，无疑也是快乐的。

2021，大学毕业整整20年的这一年，过得充实而简单。2022年的第一天，晴转多云，最高气温11摄氏度，希望新的一年能一样简单而充实。

周末把 fpjson 的 bug 提交给了 Free Pascal 的开发组，很快就得到响应并修复了。

fpjson 单元是 Free Pascal 支持 JSON 的实现，今天使用它来解析服务器传回的结果时踩了它的一个解码 bug 的坑。

我写了一个演示程序，分别用 fpjson 以及另外两个第三方的开源 JSON 单元（LkJson 和 JsonTools）解析同一段非常简单的 JSON 字符串的结果。

uses fpjson, LkJSON, jsontools;

procedure TForm1.Button1Click(Sender : TObject);
var
    str : String;
    js1 : TJsonObject;
    js2 : TlkJSONobject;
    js3 : TJsonNode;
begin
    str := '{"name":"\u95e8\u88ab\u8111\u5b50\u6324\u574f\u4e86"}';
    js1 := GetJson(str) as TJsonObject;
    js2 := TlkJSON.ParseText(str) as TlkJSONobject;
    js3 := TJsonNode.Create;
    js3.Parse(str);
    ShowMessage(
        js1.Get('name', '') + #13#10#13#10 +
        js2.getString('name') + #13#10#13#10 +
        js3.Find('name').AsString
    );
    js3.Free;
    js2.Free;
    js1.Free;
end;

运行结果如下图所示，第一行是 fpjson 解析的有问题的字符串，后两行是另外两个解析的结果——显然都正确处理了：

演示工程放在 Github 了，也附带了另外的那两个开源 JSON 单元，其中的 LkJson 单元我修改了一些 bug，与原始版本（超过 10年没有修改过了）有些微差异。

减重卓有成效，目前为止瘦了 26 斤。

上半年开始开发公司新产品 iOS 版的时候，遇到一个奇怪的问题，每次 NSURLSession 发起请求后都要延迟 7 秒左右才能连接上服务器，在客户端甚至抓包跟踪都找不出原因。但这种现象又会在一段时间后自动消失，然后又会在另一个设备上再次出现。之后就把怀疑对象转向了服务端的配置，但做了各种尝试后也依然没有头绪。

直到昨天因为试图解决另一个问题时，首科发了一小段 nginx 的配置给我，其中有一个 ssl_trusted_certificate 配置引起我好奇，去 google 搜了一下相关内容，从而了解到 OCSP。今天顺藤摸瓜继续研究，在一篇文章中查到 LetsEncrypt 提供的（旧的） OCSP 接口被 GFW 封了，所以身在国内的服务器无法连接而导致 ssl_stapling 无法开启，进而使得客户端会试图去连接 OCSP 以验证证书有效性——当然，也会无法连接而失败，可能在 iOS 设备上就是 6-7 秒左右的超时。

这样解释，一切就都说得通了。现有的解决办法，除了 hosts 中将被墙了的“ocsp.int-x3.letsencrypt.org” 域名作正确的 IP 解析——感觉不是很靠谱，如果官方 IP 地址变化了就又会问题重现。更好的办法就是重新申请 LetsEncrypt 新的证书（不是 renew）替代老证书。

近年做客户端开发比较多，这类问题如果不是有什么契机，真的是很难摸到头绪。幸好困扰了大半年后，在产品即将发布前夕，找到了原因，并且彻底解决了。