作者归档:白宦成

关于白宦成

独立开发者, 自由职业者, 写作者

解决因为 SSL 导致的 WordPress 后台无限 Redirect 的问题

解决因为 SSL 导致的 WordPress 后台无限 Redirect 的问题

在使用 CapRover 并配置域名为 HTTPs 域名时,在你访问管理后台时,可能会导致触发Chrome 自己的无限 Redirect 的问题。

之所以出现这个问题,是因为 CapRover 的架构导致的:CapRover 在最外层是一个 Nginx,SSL 证书也是在这一层完成的。而 CapRover 的默认配置,在将请求向后转发时,透传的域名会是不含 HTTPs 的协议标识的,导致 WordPress 认为发来的请求是非加密的。

而 WordPress 识别到你的请求未加密,就会返回 302 让你进入 HTTPS的链接。但新的请求并不会带上 HTTPs 的标识,导致进入无限循环。

解决这个问题的一个简单处理的方式是 — 在你的 wp-config.php 中加入如下代码,来告诉 WordPress,这个请求已经是 HTTPs 保护的了,你直接处理就好。

/* for ssl in docker */

define('FORCE_SSL_LOGIN',true);

define('FORCE_SSL_ADMIN',true);

$_SERVER['HTTPS'] = 'on';

给孩子用的 AI 工具

给孩子用的 AI 工具

今天参加一个线下活动,和朋友聊起来对于 AI 的恐惧和焦虑,问我该不该引导孩子去接触这一轮的 AGI 工具、接触这些 AI 工具。

我给了一些建议:首先,我认为我们应该给孩子接触 AI 工具。AI 的大趋势是不可逆的,基于这个前提,我们不应该抗拒孩子去接触 AI,甚至应该尽早的让孩子去建立 AI 的认知,知道什么是 AI 能做的,什么是 AI 不能做的,已经应该明确 AI 和 人类的价值边界。

用法

在聊天过程中,我们聊到了如何用 AI,我自己的观点是:

我们需要让孩子知道如何提问,以及区分出它是工具还是目的。工具掌握用法,并要明确我们的目的是什么。

剩下的,让他自己去玩就好啦。

工具

基于上述的认知,我认为现在可以推荐的工具如下:

ChatGPT

如果可以,当然是给孩子用最好的。但这个有门槛,以及作为家长,你可能要考虑 ChatGPT 本身是有风险的,可能会输出一些你不希望的内容(比如色情、暴力之类的)。

推荐程度: 5 🌟。

Perplexity

AI 搜索,体验很不错。如果孩子有搜索和探索的欲望,那么这个可能会比 Google 会是一个更好的体验。

推荐程度:5🌟

MetaSO

秘塔搜索的研究模式,比较适合孩子做一些方向的研究。可以让孩子在日常学习和生活过程中,有问题,提问。

推荐程度:5🌟。

Other things

在和这个家长聊的时候,发现现在缺乏一个 For 家庭教育场景下的GPT产品。这个产品的客户是家长,用户则是孩子。

和标准的大模型 、 产品之类的区别,是提供一些家长控制能力,这样会让家长们减少焦虑。

但我内心的另外一个声音告诉我:真的做出来,可能孩子也不会用,更好的办法是在现有的产品上加入家长控制模式。

鱼跃 Anytime CT 15 血糖监测仪体验 & 个人心得分享

鱼跃 Anytime CT 15 血糖监测仪体验 & 个人心得分享

本文内容仅作为个人体验分享,不作为任何医疗建议提供。如已有相关疾病,建议尽快就医咨询医生。

CGM(Continuous glucose monitor)是指持续血糖检测仪,在下文中,指我自己购买的鱼跃 AnyTime CT15 血糖监测仪。

个人使用体验

在详细介绍我和 CGM 的故事之前,我想和你聊聊个人的使用体验。

这 14 天的持续监测,对我来说是很不一样的,我经历过一开始的恐慌期(一开始因为适应的原因,导致我把自己吓了一跳)到小心翼翼期(担心胖胖的自己把设备给压坏了、担心洗澡会让设备失灵)再到无所谓期(把 CGM 当成日常来使用,不再担心会影响到 CGM 设备)心态变化还是挺大的。

在使用整个 CGM 的过程中,我自己的认知也得到了更新,比如:过去我一直以为我的血糖是稳定在一个点位上(毕竟空腹血糖也只取一个点),但实际上,血糖是在不断波动的,只不过是在安全的范围内不断波动。经过佩戴 CGM 的这 14 天,我也变得能够更加坦然地和自己的血糖和谐相处的过程(当然,我的血糖其实没啥问题hhh,倒也没有到病的阶段)。

作为一个个体,在经历过 CGM 的体验后,我认为:

  • 如果持续使用 CGM,那么他只适用于糖尿病患者:这句看似是废话,但我想表达的是,绝大多数人的血糖波动范围,完全没必要关注血糖波动。现有的 CGM 的设计基本上也是服务于糖尿病患者的保命需求的。普通人用起来可能没啥太大的感觉。糖尿病患者使用 CGM 主要也是因为扎手指太疼、有感染风险、没办法比较高频采集数据,不然其实指尖采血也挺好的。从痛感的视角来看,CGM 的痛感更轻,且只需要痛一次,更适合持续使用。
  • 如果是体验 CGM 的话,那么我推荐你可以买一个试试:血糖的监控就如同血压、体温、心率等一系列监控,可以给你提供一个不同的指标。特别是肥胖率日渐增长的中国,监控一下自己的日常饮食会给自己的身体带来的变化,对于你更好的理解自己的饮食有很大的帮助。¥299 的价格,属于可以考虑尝试一次的范围。

对于我自己而言,我这一次使用了 CGM,短时间我可能不会继续购买 CGM 设备了(如我上面所述),但如果我再需要监测我自己的血糖的时候,我想来也不会对于 CGM 有太多的恐惧,可以坦然面对使用 CGM。


过程全记录

缘起

作为一个曾经撰写《自我量化指南》的人,对于自身数据、各项指标的探索从未止步。我长期佩戴 Apple Watch,便是为了追求自身的各项指标的收集。最近在听无人知晓的 EP34 ,孟岩对话顾中一这一期时,孟岩提到了,他自己在佩戴持续血糖检测仪(CGM),让我产生了好奇心和兴趣:我是不是也可以使用这样的工具来检测自己的血糖?

我并不是全无接触过血糖检测设备,实际上我过去曾购买过鱼跃的血糖检测仪,但我之前购买的是采用指尖采血的血糖仪,需要你有毅力给自己的指尖破一个小洞,采血并进行检验。从自我量化的视角来看,倒也并非不可接受 —— 我并不需要那么多的血糖数据埋点,对么?但毕竟要出血,且要带酒精棉片、采血针等一系列设备,属实麻烦。所以这个血糖仪如今也在我的医疗箱里吃灰。

CGM 作为一个可以持续佩戴的产品,让我想要试试,刚好这次听播客被勾起了兴趣。那就试试吧!

购买

既然已经决定了要购买,那说买就买。在经过一番搜索和研究之后,我最终选择了鱼跃(Yuwell)家的动态血糖仪 CT15 。虽然在这个领域,更加专业的可能是雅培,国内的也有三诺、微泰等企业,但对于我来说,最重要的是 鱼跃的 App 可以和 Apple Health 打通,将数据透传给 Apple Health。这样未来我就可以把我自己的各种数据都汇总起来进行分析和消费。

做出了选择,接下来就很简单,我在拼多多上下单了鱼跃 CT15 血糖仪,并在 4.24 日拿到了这个设备(然后在当天给自己装上了它)。

安装鱼跃 CT15

收到货后,拆开快递后,我拿到了两个设备,一个是有点像 Airpods 的 蓝牙发射器 & 充电底座;另外一个则是真正插入体内的传感器及其辅助发射器。

收到的设备

拆开后,大概是这样的:

蓝牙发射器 & 底座
传感器 & 辅助植入设备
传感器底部的标签

安装不复杂:

  1. 先在手机上下载安耐糖的 App;
  2. 确认你自己要安装的部位,你可以选择手臂后方或腰部。根据自己的习惯选择即可。我最终选择的是手臂后方(主要是我有趴着睡的习惯,放在腰腹部担心压坏)。
  3. 链接 App & 蓝牙发射设备。
  4. 对植入部位使用酒精消毒。
  5. 使用辅助植入器植入设备。
  6. 将蓝牙发射器和传感器组装起来。

更加详细的安装过程,我直接把官方的视频搞下来了,你可以看这个视频快速了解安装的链路。

安装完成后,大概是这样的:

数据监测 ing

设备安装好后,接下来就是持续性监测这个数据 & 指标了。

坦白来讲,设备装上的第一天我是把自己吓到了,因为监测到了我有史以来最高的血糖值 — 11.6(我差点就给自己确诊糖尿病了),在给自己上 CGM 的那个晚上,我看了不少的二型糖尿病防治指南(放在最后了hhh)。

第一天记录到的 11.6 的巨高数据

不过,经过一天的适应,在第二天,我的血糖进入了常规的阶段,慢慢的,我的心态也没有那么慌了(所以提醒大家,即使 CT15 这样不需要额外校准的设备,也有可能会存在初期数据不准的问题,如果看到了一个非常夸张的数字,不要慌让他再抓一些数据看看。

第一天的血糖
第二天的血糖

接下来的每天的日常就是让他自己跑数据,监测一下自己的血糖变化。安耐糖的 App 提供了血糖变化数据,方便你看到你的数据变化范围,是否在你预设的血糖范围内等一细节数据,方便你快速了解自己的血糖情况。

安耐糖的主界面

取出设备

当时间走到 5 月份时,我佩戴 CGM 也满 14 天了,就必须要取下设备(设备的设计监测周期是 14 天),取下的过程非常简单,先按下传感器的卡扣,取下蓝牙发射器,然后去除传感器周围的胶布拔下传感器即可。

在没有取下来之前,我对于 CGM 的体内植入深度没啥感觉(虽然说明书上已经说了 5~10 mm),但当你真的看到这个探针,并意识到这个探针已经在你体内 14 天时,还是有点惊悚的…

数据分析

数据采集只是手段,归根结底,我们是希望用数据指引我们做决策。血糖分析也是如此。一方面, 你可以直接查看安耐糖上的一些数据来观测自身的指标,另一方面,安耐糖也提供了官方的报告解读的服务。

当你的设备取下后,官方会拉个微信群给你做一下基本的报告解读,简单分析一下你的情况,会得到如下的报告内容。

一些你可能关注的问题

误差?

CGM 的原理是基于组织液的数据采集 + 算法的方式来计算出你的实时血糖。这个原理决定了它的数据注定不是真正意义上的精确值。刚好在最后几天,我参加了中关村的四高共管项目,基于指尖采血血糖仪的数据,和 CGM 的数据做了对比。在实际测试过程中发现,CGM 和指尖血糖仪的数据大概有 0.5 左右的误差。

但,作为一个可以持续监测的设备,0.5 的误差在我看来是可接受的范围。毕竟可以帮助我们监控自己的血糖,了解不同食物带来的影响,还是有其价值的。

洗澡?

从我自己的体验来看,洗澡(淋浴)是完全不影响 CGM 的,你可以放心的购买 & 使用。也合理,毕竟要在身上放 14 天,厂商也需要考虑这个问题。

按压?

安装上之后,基本上不会有什么问题,直接用即可。我自己体验下来看,只要不是硬破坏,其实没那么容易出问题。

感染?

坦白来讲,CGM 是存在感染的风险的。毕竟是有创的,我们能做的是尽可能降低感染的风险,比如在植入前用酒精棉擦拭植入区域;比如擦拭完就赶快植入,别等着。

创口?

CGM 的探针比较细,所以创口和痛感也都不强烈。从我自己的个人体感而言的话,比指尖采血的疼痛度还要小一点。

医用胶布使用指南

你可能会担心,传感器容易掉怎么办?从我自己的体验来看,不太会容易掉,此外,安耐糖会送一个加固胶布,你配合上加固胶布,基本上没有掉下来的可能性。

持续使用成本

在上面提到,CGM 智能连续使用 14 天,对于一个日常监测的人来说,必然是每两周要更换一次的,所以就需要持续购买耗材,传感器作为一次性用品,每个买下来大概是在 250 元,一年持续监测下来的话,成本还是比较高的,一年需要 250 * (52/2) = 6500 元左右,批量购买可能可以控制在 6000 以内,成本不低。但考虑到这玩意是用来保命的,倒也合理。

二型糖尿病防治指南

延展阅读

https://sspai.com/post/77324

https://sspai.com/post/77348

Chinese-Calendar: 一个帮助你判断今天是不是工作日的 Pypi 包

Chinese-Calendar: 一个帮助你判断今天是不是工作日的 Pypi 包

在开发过程中,你可能会需要实现某些和工作日相关的特性(比如,工作日才发某些通知 /推送),这个时候,你可以借助于 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)
介绍一下 Read it!

介绍一下 Read it!

每年我都会给自己开一些新的坑,用于探索新的技术方向、新的领域。2024 年,我的新项目是 —— Read it!

Read it! 是一个用于分享我自己觉得不错的文章、网站的地方, 你可以在这里看到我日常浏览网页过程中发现的不错的网站、文章。

我会在分享链接的过程中,加上一些我自己的看法、总结。

如何使用 Read it!

  • 网页浏览: Read it! 是一个网站,所以你只需要打开浏览器,访问 readit.ixiqin.com,就可以看到我分享的网站。
  • RSS 订阅:作为一个古早 RSS 爱好者, 你可以直接在你的 RSS 里订阅 Read it! ,将 https://readit.ixiqin.com/rss/bookmarks/ 贴在你的 RSS 阅读器里,就可以查看到它。

为什么会有 Read it!

我是湾区日报的读者,也很喜欢湾区日报的形式。包括过去也尝试过用 WordPress 之类的系统来搭建类似的形态。但,繁琐的操作会消磨我分享的耐心。

最近又在整理书签,加上也开始进行一些大模型应用的开发,所以决定借助大模型来帮助我自己完成一些工作,就重新搞起了 Read it! 这个项目。

Read it! 目前的工作模式挺简单的,我找到觉得不错的文章,直接在 IM 里发给他,他会自动解析我的意图,并将解析出来的结果录入到系统当中,给大家看。想来这样的交互可以让这个项目活得更久一些~

流程说明

Read it! 会分享什么?

Read it! 可以理解为是我自己再看的各种文章,所以并不会局限领域、方向,只要是我自己看的觉得有收获的,我都会分享。后续会考虑提供分标签的订阅方式,这样你可以选择只订阅自己喜欢的文章。

CapRover 如何停止服务,并进行硬盘扩容/维护

CapRover 如何停止服务,并进行硬盘扩容/维护

在一开始使用 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. 执行命令,扩容硬盘

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

使用 CapRover WebHook 获得类 Vercel 部署体验

使用 CapRover WebHook 获得类 Vercel 部署体验

我在开发前端应用的时候,基本上使用的都是 Vercel ,究其原因,主要是以下几个点:

  1. Vercel 可以方便的与 Github 整合,提供简单易用的部署方式:写完代码,测试完成后推送到 Github ,就会自动部署到线上。对于小型项目来说,可以简化部署的流程。
  2. Vercel 提供了自定义域名和自动配置的 SSL,提供了简单的配置方式:在现在 SSL 成为标配的模式下,在 Vercel 你只需要把域名解析到 Vercel ,并在你的 Project 当中绑定域名,就会自动完成域名绑定和 SSL 申请和续期。
  3. Vercel 提供了 FaaS 环境:写应用的时候,很多时候不只有前端的需求,这个时候, Vercel 自身的提供的 FaaS 环境可以帮助你完成基本逻辑的编写。

但 Vercel 毕竟是以前端为主,且函数运行时长也有限制,对于一些比较重的场景下,Vercel 还是不太够用。刚好最近我把服务部署从传统的 LAMP 换成了 Docker Based PaaS,我使用的 CapRover 提供了类似的体验。

使用 Cap Rover 你能获得的体验:

  • 上传代码后,自动部署到 Production
  • 绑定域名后,自动配置 SSL 证书,且可以配置其他域名转发到主域名

具体操作步骤见下:

安装 CapRover

CapRover 的安装我就不再赘述,跟随官方的说明安装即可。

绑定根域名

当你登录 CapRover 时,CapRover 会让你绑定一个泛域名解析,你可以根据自己的需要,绑定一个二级或者三级域名,然后在 DNS 解析一个 * 到这个服务器上。这样后续部署的服务就会自动解析一个 服务名.你的域名 ,用于服务的初步访问(类似于 xxx.vercel.app)。

上传代码至 GitHub

在 Github 上创建一个代码仓库,并把你自己的项目部署上去。如果你有已经写好的 Dockerfile,可以一并上传上去。如果没有的话,则可以选择参考 CapRover 提供的 Sample App ,里面提供了常见语言的部署参考。

创建容器并配置环境

完成代码上传后,你可以进入到 CapRover 后台,创建一个新的 App。这里可以输入你喜欢的名字,方便后续查找即可。

创建完成后,点击下方列表中的应用名称,进入应用的配置页面,并切换至 Deployment 页面。

在这个页面,可以找到 Method 3 : Deploy From GitHub/ Bitbucket/Gitlab,填写你的仓库信息、分支名、用户名。密码你可以选择直接使用你的密码,也可以选择创建一个 Personal Access Token ,或者是在仓库里配置一个 Deploy SSH key 均可。

配置完成后,会自动给你生成一个 Webhook 地址,复制这个 Webhook 地址。

配置 Github 上的 WebHook

复制上方的 Webhook 地址,并进入到 Github 你的仓库 – Settings – webhooks 页面,新增一个 Webhook。

粘贴你刚刚复制的 URL,Content Type 选择 application JSON,并在下方选择触发部署的时机。

点击报错。

等待自动部署

接下来你就可以通过提交代码,来让其自动完成部署,从而享受类似于 Vercel 的推送即部署的体验~。

在你的 Github Actions 中添加一个 PostgreSQL 用于测试

在你的 Github Actions 中添加一个 PostgreSQL 用于测试

在开发应用的时候,我们会选择使用 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
Thinking in Component Tree

Thinking in Component Tree

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

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

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

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

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

在 WordPress 的 Docker 镜像上加装 Redis 拓展,以支持 Redis 缓存

在 WordPress 的 Docker 镜像上加装 Redis 拓展,以支持 Redis 缓存

从 LAMP 到 Docker based PaaS 工具 当中,我提到我现在使用的是 Docker Based PaaS 产品来托管站点。本站目前其实就是跑在 Docker 上的。

使用默认的 WordPress 镜像时,我发现一个问题:没有支持 Redis 拓展!我使用 Redis 来缓存 Query,提升访问的性能。如果缺失了 Redis 拓展,就会减少一部分缓存的能力。于是开始研究如何在官方的 WordPress 镜像上加入 Redis 拓展。

根据 WordPress 镜像的官方说明,我们可以 docker-php-ext-* 命令来配置镜像,安装必要的拓展,来满足我们日常使用的需求,并给出了官方的参考。

不过,我在验证 Redis 拓展时,使用 docker-php-ext-* 命令没有配置成功,好在可以使用 pecl 来安装。于是,我便将 Dockerfile 修改成如下内容,来完成对于 Redis 拓展的安装。

FROM wordpress:latest
RUN pecl install -o -f redis && rm -rf /tmp/pear && docker-php-ext-enable redis

修改好 Dockerfile ,然后重新启动,一切都好了~

使用 idb-kayval 作为前端数据存储

使用 idb-kayval 作为前端数据存储

在前端留存一些状态,是在前端场景下提升性能的常规操作。最近我有一个场景需要在前端留存一个状态,借着这个机会,试了试 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 以内,从而得到一个不错性能。