月度归档:2022年08月

summary

2022 年 8 月月度总结

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 当中隐藏掉外部链接前的 Icon

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 中配置安全规则,来保护配置和数据文件

由于 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 配置 Rewrite 优化路径显示

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。

Dokuwiki 忘记密码了怎么办?

我的个人 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 从 MOBI 到 EPub

我给 Kindle 发电子书的时候,收到了来自亚马逊 Kindle 客服的邮件,告知我不再支持发送 MOBI 和 AZW 格式的电子书了。

我还发了推来说这件事

不过,很快我发现,EPUB 也支持修改字体了,我可以在 Kindle 上用自定义字体来查看电子书了。

真香!

man in black jacket sitting on white chair

多做无用之事

人生当松紧结合,既要求“紧”,做有用之事,也要求“松”,做「无用」之事,给自己放松。

在我年轻的时候,是一个「奋斗逼」一样的存在,当别人在玩游戏的时候,我在 Coding;当别人在睡觉的时候,我在 Coding;当别人在上课的时候,我还在 Coding

我花费了大量的时间来做这些和 Coding 有关的事情,可以称之为我那个时代的「紧」。这样的付出也得到了回报,我做到了同龄人无法做到的事情。但相应的,我

我在年轻的时候,对于「有用之事」十分的在意。

毕竟,年轻人想要快速超越同龄人,甚至超越比自己年长的人,是需要付出比常人十倍、甚至百倍的努力的。我不够聪明,所以只能依靠蛮力去学习、去练习。好在我开始的早、学习的早、练习的早,所以总算是在自己的年龄,达到了一个还算可以的结果(但说实话我不是特别满意,还希望自己可以更好)。

而这些练习、学习,大量的消耗了我的「无用之事」的时间,让我没有太多的时间去做那些无用之事。

但大量的「有用之事」,让我的生活变得十分枯燥,死板,没有生机。我变成了一个不太有趣的人。即使到今日,我依然不能够变得很有趣。

从某种视角来看,我们可以认为「无用之事」代表着人类深处那些代表人性的部分,而有用之事则代表着人类对于效率的追求,更偏向机器。

当你做无用之事时,你会更像人;当你做有用之事时,你会更像机器。我还是觉得人像「人」比较好。

running white horse

歌曲推荐:福禄寿的《马》

我在刷抖音的时候,不少关于《隐入尘烟》的片段都采用了福禄寿的这一首《马》,觉得甚是喜欢,特地留下一篇文章来记录。

我喜欢这首歌曲的原因是这首歌曲富含了情绪,它表现出了主人和马之间的关系。后来去查了一下歌曲的背景,和我所想象的并不相同。但不影响我能感受到这首歌曲背后的情绪。

我很喜欢这首歌。(不过后来注意到福禄寿当中的一个人吸毒了,可惜,这首歌大概是成为绝唱)。

为什么我不愿意去体制内?

我其实算是和体制内比较熟悉的人了。我父亲是公务员,我从小耳濡目染,或多或少是见过公务员体制内的生活了。

不过,从我自己的体验和志向而言,我并不愿前往体制内。

在大学时,我曾畅想,我可以考编制,在体制内工作,挑选一个每天喝茶看报的岗位。然后在喝茶看报之时,可以自己研究技术,成为一个上班摸鱼,下班写代码的人。

但当我走入社会之后,重新思考这个问题:到底我想要的是什么?

在体制内我所获的不过是一个虚伪的“安全感”,但那个安全感真的是我需要的么?几千块工资,倒是有时间,但每天需要花费 8 个小时在一个自己并不感兴趣的工作当中,去浪费我自己的生命,换来的可能是我一篇、两篇文章的收入。

这真的重要么?我找到了自己的答案。

text

将小程序从云开发迁移到自建服务器

云开发最近开始出现大幅度调价,并配置了一个默认的最低消费:19.9 元;说起来,这个钱不多,奈何我的很多个小程序都属于用量极小,但也不能停止运转的。过去的按量付费的模式对于我这样佛系运营的小程序会比较友好。但现在这种付费模式对于我这种每个小程序量级都不大,但又多个小程序的人来说不太友好。既然我能给开发一套标准的后端,且确实觉得没必要,就花点时间从云开发迁移到自建的服务器。

评估修改工作量

在开始动手迁移的时候,先要评估一下迁移所需要的成本,我选择使用 grep 查询一下我的变更的工作量。执行如下命令,来判断我具体在哪些文件当中调用了云开发的方法,判断出具体的工作量

grep -w -c -E 'callFunction|db.collection|wx.cloud' ./**/**.wpy

执行命令后,你会看到类似这样的输出,这个输出表现出了我的具体没个文件所需要的修改的量。

这样对于具体要做的工作量就心里有数了。接下来要做的,无非是具体的迁移工作了。

评估云函数工作量

云开发用久了,很容易出现一些其实不再运转的函数。在这种情况下,可以不再迁移这些函数,降低自己的迁移成本。

云函数在迁移的时候,可以通过云开发提供的函数监控面来判断每个函数的调用情况,对于调用情况为 0 的函数,就可以选择性的不再提供服务了。

导出数据库

从云开发迁移走的时候,我们需要迁移小程序侧的代码、云函数代码和云数据库的资源,因此,也需要将对应的数据提供导出和导入。

不过,你需要注意的是,云开发导出的 JSON 不是标准的 JSON 格式,而是 JSON Lines 的格式,在你对应的数据导入时,需要使用 package 来 parse ,而不是使用标准的方式来进行 Parse。

修改代码

当上面的事情做完了,接下来要做的,就是具体的写代码来进行迁移了,记得迁移服务端 & 客户端两侧的代码~。