Objective 1：持续获取现金流，并构建未来收益的现金牛
KR1：投资收益达到 20000 元
最近市场稍稍回暖，投资收益依旧很差。感觉定了一个奇怪的目标。受市场波动很大。应该定的目标是什么？应该思考
KR2 ：单篇稿费突破 6000 元
无变化
KR3 ：达成年度预算，支出不超预算
8 月份的开支相比于上个月少了一些，但由于基本生活开支锁死，依然处于高位。需要继续研究降低支出的方式。
KR4 ：构建软件类现金牛业务，预期产生收益 10000 元人民币
无进展。
Objective 2：提升生活基础设施，构建未来生活好基础
KR1：前往 6 个城市旅行
天津疫情汹涌，哪也去不了。
KR2：进行 20 次文娱活动
没怎么进行文娱活动，倒是开始在看书。
KR3：借助智能化设备，缩减在家务相关事务上耗费的时间
买了一罐精油，配合之前买的米家的香氛机，自己添加香氛来使用。虽然没花太多钱，也没有特别折腾，但体验很好。
Objective 3 :开拓视野，打造多元行业人才
KR1：写 15 篇书评
没写出书评，但把书摘发出来了。。。水一下。。。
KR2：输出关于加密货币的 Newsletter 12 封
继续 0 进展。
KR3 ：完成计划中的三本图书的写作
暂无进展。
Dokuwiki 在链接外部网站时，默认会在链接前展示一个地球的小图标。但如果你和我一样，觉得这个小图标有点碍眼，则可以尝试通过添加 CSS 来隐藏前面的小地球。
你只需要在 /conf 文件夹下创建一个 userstyle.css 的文件，并在其中添加对应的 CSS
.page a.urlextern,
.page a.interwiki,
.page a.windows,
.page a.mail,
.page a.media {
padding-left: 0 !important;
background: none !important;
}
添加完后，执行 Shift + Control + R 来强制刷新 CSS，刷新完成后，就可以看到没有小地球的连接了。
由于 dokuwiki 的文件路径默认会放在 data/conf/bin 等几个目录当中，如果你不对相应的文件进行保护，如果某个人是了解 dokuwiki 的情况下，它可以越过你的 dokuwiki ，直接读取 wiki 的内容。
而你没有进行保护的时候，Dokuwiki也会在配置当中展示你的配置不安全。
想要开启 Nginx 的保护，你需要在 Nginx 的配置文件当中，添加如下代码。
location ~ /(data|conf|bin|inc|vendor)/ {
deny all;
}
添加完成后，执行如下命令来重启 Nginx，使命令生效。
nginx -t
nginx -s reload
生效成功后，再次刷新，就可以看到提示已经消失了。同时如果你直接访问 data 目录下的数据文件，也会直接报错。
Dokuwiki 在生成 URL 的时候，支持生成三种不同的 URL：
- Rewrite 版:
/wiki:welcome?do=admin&page=config - dokuwiki 控制版:
/doku.php/start?do=admin&page=config - 默认版：
/doku.php?id=start&do=admin&page=config
配置 Rewrite 可以让你的 wiki 的路径更加简单的和明确，屏蔽语言信息，因此，一般而言，都建议大家配置上对应的 rewrite 规则。
在 Nginx 你的 Host 配置下加入如下规则，来实现 Rewrite 的转发
location / { try_files $uri $uri/ @dokuwiki; }
location @dokuwiki {
rewrite ^/_media/(.*) /lib/exe/fetch.php?media=$1 last;
rewrite ^/_detail/(.*) /lib/exe/detail.php?media=$1 last;
rewrite ^/_export/([^/]+)/(.*) /doku.php?do=export_$1&id=$2 last;
rewrite ^/(.*) /doku.php?id=$1&$args last;
}
添加完成后可以执行如下命令来重启 Nginx
nginx -t
nginx -s reload
再回到 Dokuwiki 后台的配置管理器，找到 userewrite 这一项配置，将其配置为使用.htaccess，并保存，即可将 dokuwiki 默认生成的 URL 变成一个更加干净的 URL。
我的个人 Wiki 系统是 Dokuwiki 。相比于别的 Wiki ，Dokuwiki 轻量的同时，功能齐全，帮助我在 TiddlyWiki 和 MediaWiki 之间找到了一个平衡。
我在使用 Tiddly Wiki 的时候，会遇到忘记密码的情况，这种情况下，就需要对 Dokuwiki 进行密码重置的操作。
如果你和我一样，关闭了 Dokuwiki 的任意人可上传，则需要通过修改具体的 auth 文件来完成。
Dokuwiki 的用户授权信息放置在 conf/users.auth.php 文件当中，你需要在服务器上打开这个文件，并在其中添加如下信息
deleteme:$1$4fd0ad31$.cId7p1uxI4a.RcrH81On0:-:-:admin,user
添加完成后，你将会获得一个名为 deleteme，密码为admin 的用户，接下来你只需要使用这个用户登录到你的 Dokuwiki 当中，并在管理当中的「用户管理器」中修改之前的用户的账号密码。
在用户管理器当中可以修改对应的用户的密码。
修改完成后，使用之前的用户登录，并删除之前的用户即可。
我给 Kindle 发电子书的时候，收到了来自亚马逊 Kindle 客服的邮件，告知我不再支持发送 MOBI 和 AZW 格式的电子书了。
我还发了推来说这件事
不过，很快我发现，EPUB 也支持修改字体了，我可以在 Kindle 上用自定义字体来查看电子书了。
真香！
人生当松紧结合，既要求“紧”，做有用之事，也要求“松”，做「无用」之事，给自己放松。
在我年轻的时候，是一个「奋斗逼」一样的存在，当别人在玩游戏的时候，我在 Coding；当别人在睡觉的时候，我在 Coding；当别人在上课的时候，我还在 Coding。
我花费了大量的时间来做这些和 Coding 有关的事情，可以称之为我那个时代的「紧」。这样的付出也得到了回报，我做到了同龄人无法做到的事情。但相应的，我
我在年轻的时候，对于「有用之事」十分的在意。
毕竟，年轻人想要快速超越同龄人，甚至超越比自己年长的人，是需要付出比常人十倍、甚至百倍的努力的。我不够聪明，所以只能依靠蛮力去学习、去练习。好在我开始的早、学习的早、练习的早，所以总算是在自己的年龄，达到了一个还算可以的结果（但说实话我不是特别满意，还希望自己可以更好）。
而这些练习、学习，大量的消耗了我的「无用之事」的时间，让我没有太多的时间去做那些无用之事。
但大量的「有用之事」，让我的生活变得十分枯燥，死板，没有生机。我变成了一个不太有趣的人。即使到今日，我依然不能够变得很有趣。
从某种视角来看，我们可以认为「无用之事」代表着人类深处那些代表人性的部分，而有用之事则代表着人类对于效率的追求，更偏向机器。
当你做无用之事时，你会更像人；当你做有用之事时，你会更像机器。我还是觉得人像「人」比较好。
我在刷抖音的时候，不少关于《隐入尘烟》的片段都采用了福禄寿的这一首《马》，觉得甚是喜欢，特地留下一篇文章来记录。
我喜欢这首歌曲的原因是这首歌曲富含了情绪，它表现出了主人和马之间的关系。后来去查了一下歌曲的背景，和我所想象的并不相同。但不影响我能感受到这首歌曲背后的情绪。
我很喜欢这首歌。(不过后来注意到福禄寿当中的一个人吸毒了，可惜，这首歌大概是成为绝唱）。
我其实算是和体制内比较熟悉的人了。我父亲是公务员，我从小耳濡目染，或多或少是见过公务员体制内的生活了。
不过，从我自己的体验和志向而言，我并不愿前往体制内。
在大学时，我曾畅想，我可以考编制，在体制内工作，挑选一个每天喝茶看报的岗位。然后在喝茶看报之时，可以自己研究技术，成为一个上班摸鱼，下班写代码的人。
但当我走入社会之后，重新思考这个问题：到底我想要的是什么？
在体制内我所获的不过是一个虚伪的“安全感”，但那个安全感真的是我需要的么？几千块工资，倒是有时间，但每天需要花费 8 个小时在一个自己并不感兴趣的工作当中，去浪费我自己的生命，换来的可能是我一篇、两篇文章的收入。
这真的重要么？我找到了自己的答案。
云开发最近开始出现大幅度调价，并配置了一个默认的最低消费：19.9 元；说起来，这个钱不多，奈何我的很多个小程序都属于用量极小，但也不能停止运转的。过去的按量付费的模式对于我这样佛系运营的小程序会比较友好。但现在这种付费模式对于我这种每个小程序量级都不大，但又多个小程序的人来说不太友好。既然我能给开发一套标准的后端，且确实觉得没必要，就花点时间从云开发迁移到自建的服务器。
评估修改工作量
在开始动手迁移的时候，先要评估一下迁移所需要的成本，我选择使用 grep 查询一下我的变更的工作量。执行如下命令，来判断我具体在哪些文件当中调用了云开发的方法，判断出具体的工作量
grep -w -c -E 'callFunction|db.collection|wx.cloud' ./**/**.wpy
执行命令后，你会看到类似这样的输出，这个输出表现出了我的具体没个文件所需要的修改的量。
这样对于具体要做的工作量就心里有数了。接下来要做的，无非是具体的迁移工作了。
评估云函数工作量
云开发用久了，很容易出现一些其实不再运转的函数。在这种情况下，可以不再迁移这些函数，降低自己的迁移成本。
云函数在迁移的时候，可以通过云开发提供的函数监控面来判断每个函数的调用情况，对于调用情况为 0 的函数，就可以选择性的不再提供服务了。
导出数据库
从云开发迁移走的时候，我们需要迁移小程序侧的代码、云函数代码和云数据库的资源，因此，也需要将对应的数据提供导出和导入。
不过，你需要注意的是，云开发导出的 JSON 不是标准的 JSON 格式，而是 JSON Lines 的格式，在你对应的数据导入时，需要使用 package 来 parse ，而不是使用标准的方式来进行 Parse。
修改代码
当上面的事情做完了，接下来要做的，就是具体的写代码来进行迁移了，记得迁移服务端 & 客户端两侧的代码~。
