之前通过 DHCP,把全家的所有设备的网关指向软路由(openclash),从而实现翻墙。不过最近发现 homekit 的稳定性不太好,家居中枢经常掉线。想了一下大概是 openclash 连接代理服务器本身稳定性不够。
于是在路由器上通过 dnsmasq,调整了 DHCP 配置,只将部分设备的网关指向软路由。考虑 homekit 本身可能也有翻墙需要,故两个家居中枢,一个(homepod)留在了墙内,一个(apple tv)开启了翻墙。
这样一来,整体稳定多了。
于是在路由器上通过 dnsmasq,调整了 DHCP 配置,只将部分设备的网关指向软路由。考虑 homekit 本身可能也有翻墙需要,故两个家居中枢,一个(homepod)留在了墙内,一个(apple tv)开启了翻墙。
这样一来,整体稳定多了。
👍2
发现自己各种后端服务部署有点混乱,在 Vercel、Railway、Digital Ocean 等 PaaS 上都有部署,对应了不一样的羊毛使用场景。但是发现服务间互相调用会非常麻烦,代码里面需要关心目标服务的具体位置,维护成本和心智负担都不小。
于是写了个“服务发现”机制。使用一个服务发现服务 Discovery Service,通过 Vercel、Railway、Digital Ocean 的 API,不断拉取部署相应平台上部署信息,并存储下来。然后每一个服务会定时从 Discovery 上获取全量的服务列表,然后根据服务的唯一标识映射获取对应的公网地址。这样以来只要保证在 PaaS 上部署服务并暴露公网,客户端就能通过服务名称直接访问。
于是写了个“服务发现”机制。使用一个服务发现服务 Discovery Service,通过 Vercel、Railway、Digital Ocean 的 API,不断拉取部署相应平台上部署信息,并存储下来。然后每一个服务会定时从 Discovery 上获取全量的服务列表,然后根据服务的唯一标识映射获取对应的公网地址。这样以来只要保证在 PaaS 上部署服务并暴露公网,客户端就能通过服务名称直接访问。
👍2
最近要在 Redis 上做一个超大 QPS 的指标统计功能。考虑到重试幂等,没法直接用 INCR 来累加。于是想用 Set 结构存储,用 SCARD 查总量。这就涉及到占用过大的存储空间的问题。然后就各种折腾,写了一堆代码逻辑来尽可能降低存储占用,还把 Redis 换成了磁盘大容量存储的类 Redis 存储。
刚才和 ChatGPT 讨论的时候,被指出可以使用 HyperLogLog。雀食 🙈。技术还是得常用常新,不用不复习太容易忘。
刚才和 ChatGPT 讨论的时候,被指出可以使用 HyperLogLog。雀食 🙈。技术还是得常用常新,不用不复习太容易忘。
👍3
https://www.bitestring.com/posts/2023-03-19-web-fingerprinting-is-worse-than-I-thought.html
TIL,原来清除网站数据或者开匿名模式,并不能避免浏览器指纹标记。
TIL,原来清除网站数据或者开匿名模式,并不能避免浏览器指纹标记。
日常技术碎碎念
最新 Next.js13 appdir文档 中, Vercel 引入 Comments 组件,只需要登录 Vercel,就能在页面的任意位置评论。非常像 Figma 的评论系统,只不过把画布换成了网页。 Vercel 也将这个能力开发给了 Vercel 用户,所有 Preview Deployment(非主分支)可以直接开启。默认情况下,只有当前 Deployment 所属组织的成员才能评论,也可以开放权限到任意用户。 一旦发生评论,Vercel 会将评论同步到对应分支的 PR 下面,可以很自然地融入开发流程。…
https://cord.com/ 果然有了,画布评论SaaS
cord.com
A more human job search - cord
cord is the job search platform that gives you direct access to hiring teams inside technology companies in the UK, USA and remote across Europe.
日常技术碎碎念
https://buf.build/blog/connect-a-better-grpc Protobuf 管理工具 Buf 团队发布名为 Connect 的 RPC 套件. 他们罗列了一些 gRPC 的问题: ⁃ 过于复杂, 难以调试, 而且庞大的代码库容易出现漏洞 ⁃ 不使用 net/http 标准库 ⁃ 不支持浏览器 而 Connect 是在 gRPC 的基础上, 对其进行优化, 一些特性: ⁃ 精简代码, 包括生成的代码也更加可读 ⁃ 使用 net/http 标准库, 兼容性更好 ⁃ 支持…
connect server 支持 HTTP GET 了,只需要设置幂等级别为无副作用,就会自动为对应 method 配置 GET router。
在 RPC 场景中,只要是幂等就代表 Client 端可以安全地重试 RPC 调用,至于是否有副作用指导意义不强。
但是放到 http restful 接口上,GET 往往就等价于无副作用,以此判断是否支持 HTTP GET 还是比较合理且巧妙的。
https://github.com/bufbuild/connect-go/releases/tag/v1.7.0
service ElizaService {
rpc Say(stream SayRequest) returns (SayResponse) {
option idempotency_level = NO_SIDE_EFFECTS;
}
}idempotency_level 是 protobuf 内置的 method 属性,分为 unknown/idempotent/no_side_effects,后两者都是幂等的意思。在 RPC 场景中,只要是幂等就代表 Client 端可以安全地重试 RPC 调用,至于是否有副作用指导意义不强。
但是放到 http restful 接口上,GET 往往就等价于无副作用,以此判断是否支持 HTTP GET 还是比较合理且巧妙的。
https://github.com/bufbuild/connect-go/releases/tag/v1.7.0
GitHub
Release Prepare for v1.7.0 (#496) · bufbuild/connect-go
Prepares for the Connect v1.7.0 release, featuring Connect Get support.
Changes the IsAtLeastVersion1_6_0 constant to IsAtLeastVersion1_7_0
too, since it actually is from changes that only landed a...
Changes the IsAtLeastVersion1_6_0 constant to IsAtLeastVersion1_7_0
too, since it actually is from changes that only landed a...
之前使用 mackup 把 mac 上的各种配置文件备份到 icloud 了,今天发现 icloud 中的 mackup 目录被错误删除了,在 icloud 上使用文件恢复也找不到……然后 icloud 默默同步文件把本地版本也给删除了,各类配置都是软链接到 icloud 目录的,导致本地所有配置都没了
现在看着唯一一个还开着的加载了之前 .zshrc 的 zsh,再犹豫要不要放弃恢复重新配置一份 .zshrc,积累了几年的配置全都没了😩
现在看着唯一一个还开着的加载了之前 .zshrc 的 zsh,再犹豫要不要放弃恢复重新配置一份 .zshrc,积累了几年的配置全都没了😩
GitHub
GitHub - lra/mackup: Backup and keep your application settings in sync.
Backup and keep your application settings in sync. - lra/mackup
😱2
周末倒腾了一下 Surge5 新加入的 Ponte 组网能力。相比一直在使用的 Tailscale 有一个明显的优势,就是不需要自己搭建 DERP 中转服务器了,可以直接使用机场作为中转服务器。
我是用的香港节点作为中转,在公司访问家中mac延迟稳定低于 100ms。因为机场往往是不限速的,使用 VNC 开远程桌面也不需要压缩画质。
通过一些简单的规则就可以实现在外访问家中内网服务:
反过来,也可以在家直接通过公司的 mac 作为跳板访问公司内网,非常方便。
我是用的香港节点作为中转,在公司访问家中mac延迟稳定低于 100ms。因为机场往往是不限速的,使用 VNC 开远程桌面也不需要压缩画质。
通过一些简单的规则就可以实现在外访问家中内网服务:
HOME = select, DIRECT, DEVICE:mymac
IP-CIDR,192.168.50.0/24,HOME反过来,也可以在家直接通过公司的 mac 作为跳板访问公司内网,非常方便。
Nssurge
Surge Ponte 指引 | 中文 | Surge Knowledge Base
昨晚折腾了一晚上的 jetbrains gateway,想着用 goland 远程开发。
整体体验下来就是烂,各种功能和插件需要区分 Host 和 Client,有些插件需要两侧同时安装才能使用,心智负担很高;很多插件本身就是面向客户端模式设计的,在这种前后端分离模式下根本没法使用。
性能的话倒是可以接受,开个 golang 的 monorepo,8c16g 的开发机,索引的时候会打满 CPU,平峰期差不多占用 2c8g。
总的来说,我宁愿使用 neovim 来远程开发,各种体验至少是原生的。
整体体验下来就是烂,各种功能和插件需要区分 Host 和 Client,有些插件需要两侧同时安装才能使用,心智负担很高;很多插件本身就是面向客户端模式设计的,在这种前后端分离模式下根本没法使用。
性能的话倒是可以接受,开个 golang 的 monorepo,8c16g 的开发机,索引的时候会打满 CPU,平峰期差不多占用 2c8g。
总的来说,我宁愿使用 neovim 来远程开发,各种体验至少是原生的。
The JetBrains Blog
A Deep Dive Into JetBrains Gateway | The JetBrains Blog
Let’s take a deeper look at the remote development workflow managed by the new JetBrains Gateway app.
👍1
日常技术碎碎念
之前使用 mackup 把 mac 上的各种配置文件备份到 icloud 了,今天发现 icloud 中的 mackup 目录被错误删除了,在 icloud 上使用文件恢复也找不到……然后 icloud 默默同步文件把本地版本也给删除了,各类配置都是软链接到 icloud 目录的,导致本地所有配置都没了 现在看着唯一一个还开着的加载了之前 .zshrc 的 zsh,再犹豫要不要放弃恢复重新配置一份 .zshrc,积累了几年的配置全都没了😩
最终返璞归真,在 Github 上开了个仓库存了各种配置文件,clone 到本地手动 ln -s 创建软链接。
这类不是天天都要变动的配置文件,确实没有必要用 icloud 之类云盘实时同步。
分享下重写的 .zshrc,用在我的多个 macos/linux 环境下,使用 Github Action 从我的配置仓库当中自动同步到 Gist,https://gist.github.com/sorcererxw/238f7068c18ba148337f32f9a08d0dbd
这类不是天天都要变动的配置文件,确实没有必要用 icloud 之类云盘实时同步。
分享下重写的 .zshrc,用在我的多个 macos/linux 环境下,使用 Github Action 从我的配置仓库当中自动同步到 Gist,https://gist.github.com/sorcererxw/238f7068c18ba148337f32f9a08d0dbd
Gist
My .zshrc file
My .zshrc file. GitHub Gist: instantly share code, notes, and snippets.
👍1
mac(尤其是 intel 的),在唤醒之后常常会碰到 kernal_task 跑满 CPU 的情况,猜测是得把缓存到磁盘的数据读回到内存中,期间会非常卡。 https://discussions.apple.com/thread/5497235
各种办法都试了,效果都不明显。现在找到一个不错的办法,就是开个终端,执行
各种办法都试了,效果都不明显。现在找到一个不错的办法,就是开个终端,执行
caffeinate -s,只要我不中止这个进程,系统完全不会休眠,这样就避免了唤醒的问题。
日常技术碎碎念
周末倒腾了一下 Surge5 新加入的 Ponte 组网能力。相比一直在使用的 Tailscale 有一个明显的优势,就是不需要自己搭建 DERP 中转服务器了,可以直接使用机场作为中转服务器。 我是用的香港节点作为中转,在公司访问家中mac延迟稳定低于 100ms。因为机场往往是不限速的,使用 VNC 开远程桌面也不需要压缩画质。 通过一些简单的规则就可以实现在外访问家中内网服务: HOME = select, DIRECT, DEVICE:mymac IP-CIDR,192.168.50.0/24…
早上尝试在家通过 Surge 作为跳板访问公司内网,发现规则模式下怎么都访问不通。
发现所有请求都直接使用了 Final 的兜底规则,通过机场去访问了公司内网,那肯定是不通的呀,光 DNS 就没法成功(需要使用内网 DNS)。
研究了半天,发现原来是因为自己在内网规则前加了一个 IP-CIDR 规则,整体规则如下的:
根据 Surge 文档所说:在进行规则判定时,Surge 自上往下依次尝试匹配每条规则,如果遇到了一条 IP 类型的规则,那么 Surge 将进行 DNS 解析后再进行匹配。
1. 当处理内网请求的时候,先碰到了 IP-CIDR 规则,当场开始 DNS 查询域名的地址,但是内网 DNS 本地显然访问不通,最后解析失败。
2. 根据 dns-failed 规则使用了 FINAL 的 PROXY 策略,选择了使用机场兜底。
最后把 IP-CIDR 规则移到下方之后,就解决了问题。老实说这个设定确实蛮坑的......
发现所有请求都直接使用了 Final 的兜底规则,通过机场去访问了公司内网,那肯定是不通的呀,光 DNS 就没法成功(需要使用内网 DNS)。
研究了半天,发现原来是因为自己在内网规则前加了一个 IP-CIDR 规则,整体规则如下的:
IP-CIDR,10.0.0.0/8,PROXY
DOMAIN-SUFFIX,company.org,COMPANY
FINAL,PROXY,dns-failed根据 Surge 文档所说:在进行规则判定时,Surge 自上往下依次尝试匹配每条规则,如果遇到了一条 IP 类型的规则,那么 Surge 将进行 DNS 解析后再进行匹配。
1. 当处理内网请求的时候,先碰到了 IP-CIDR 规则,当场开始 DNS 查询域名的地址,但是内网 DNS 本地显然访问不通,最后解析失败。
2. 根据 dns-failed 规则使用了 FINAL 的 PROXY 策略,选择了使用机场兜底。
最后把 IP-CIDR 规则移到下方之后,就解决了问题。老实说这个设定确实蛮坑的......
最近工作上有一个需求,处理一批数据,需要各种展开分析统计数值,原始数据量非常庞大,笛卡尔积一下大概是每小时要处理 10^15 条数据。因为数据规模实在太大了,完全没法在线实时统计,只能离线慢慢算。
开个 Spark 定时调度任务,每小时跑一次上个小时的数据,单次计算上千核+几TB内存还要跑几十分钟。
作为后端开发,一直只实现各种实时计算,对于各种计算成本精打细算,很少接触离线数据分析。
哪里见过这种场景,一段 SQL 丢进去,就是无脑暴力跑,太震撼了。
开个 Spark 定时调度任务,每小时跑一次上个小时的数据,单次计算上千核+几TB内存还要跑几十分钟。
作为后端开发,一直只实现各种实时计算,对于各种计算成本精打细算,很少接触离线数据分析。
哪里见过这种场景,一段 SQL 丢进去,就是无脑暴力跑,太震撼了。
👍1
日常技术碎碎念
最近把自建的 umami 从 1.x 升级到 2.x。根据文档,顺利地升级了 postgres 当中的表结构和数据,但是 2.x 的实例起来之后,一直都无法读取数据库中的数据,看了眼日志,大概是 prisma 处理数据报错了。 无奈,尝试把旧数据清空,原来的报错倒是没了,但是网页上报的数据一直没有正确消费写入。 累了,也懒得回退到 1.x,不太想继续用 umami。
还是看看各种 analytics SaaS 吧。除了 Google Analytics,几乎所有类似的服务,价格都不算便宜,Vercel/Cloudflare 之类的都是 20刀一个月,单纯只是网站数据统计的话,感觉意义不是很大,毕竟流量不大,自建 umami 之类的一个月成本也就2刀以内。
对于我来说,更大的痛点其实是服务端的可观测性,自建一套 prometheus/Influxdb + grafana 维护起来蛮麻烦的。所以打算找个原生支持 OpenTelemetry 的 Analytics SaaS,我直接将前端后端数据都通过 OpenTelemetry 打通接入。
最最理想的状态,是能够把 log/metrics/trace/alert 全部依赖一个平台接入。
找了一圈,要不是价格很贵,要不功能不完善,要就不兼容 OpenTelemetry。
想想也是,这类数据统计一旦统计的数据维度多一点,很容易出现统计数据的流量是业务流量好几倍的放大现象。工作中也在维护一个统计服务,也是整个系统的成本怪兽。也能理解为什么各类数据统计 SaaS 这么贵。
对于我来说,更大的痛点其实是服务端的可观测性,自建一套 prometheus/Influxdb + grafana 维护起来蛮麻烦的。所以打算找个原生支持 OpenTelemetry 的 Analytics SaaS,我直接将前端后端数据都通过 OpenTelemetry 打通接入。
最最理想的状态,是能够把 log/metrics/trace/alert 全部依赖一个平台接入。
找了一圈,要不是价格很贵,要不功能不完善,要就不兼容 OpenTelemetry。
想想也是,这类数据统计一旦统计的数据维度多一点,很容易出现统计数据的流量是业务流量好几倍的放大现象。工作中也在维护一个统计服务,也是整个系统的成本怪兽。也能理解为什么各类数据统计 SaaS 这么贵。
👍1
Forwarded from TO-D 观察室 – 2d2d.io
【新产品介绍】OpenObserve 是 Rust 开发的一站式 Logs, Metrics, Traces 可观测产品,去年该团队开发了 ElasticSearch 轻量级替代品 zincsearch 迅速获得 15000+ star,并获得 460 万美金种子轮融资,后来转型专注于新的可观测产品 ZincObserve,最近改名为 OpenObserve。
https://openobserve.ai/
https://openobserve.ai/
openobserve.ai
OpenObserve: Open Source Observability Platform | Logs, Metrics & Traces
Fast, scalable and cost-effective open source observability platform. Monitor logs, metrics & traces with 140x lower storage costs than Elasticsearch. Start in 2 minutes.
❤1👍1
日常技术碎碎念
https://buf.build/blog/connect-a-better-grpc Protobuf 管理工具 Buf 团队发布名为 Connect 的 RPC 套件. 他们罗列了一些 gRPC 的问题: ⁃ 过于复杂, 难以调试, 而且庞大的代码库容易出现漏洞 ⁃ 不使用 net/http 标准库 ⁃ 不支持浏览器 而 Connect 是在 gRPC 的基础上, 对其进行优化, 一些特性: ⁃ 精简代码, 包括生成的代码也更加可读 ⁃ 使用 net/http 标准库, 兼容性更好 ⁃ 支持…
忽然想到,使用类似 Protocol Buffers(protobuf)或者 Thrift 这样的 IDL 声明接口,往往允许修改字段名称,只要保证不修改字段类型和序号,保证数据结构内存结构一致,就不会出现客户端和服务器不一致而冲突的情况。
但如果通过 grpc-gateway 或者 Connect 这样的框架,基于 protobuf,来与前端通过 JSON 而非二进制数据做数据交互,就是另一种情况。在这种情况下,可以随便修改序号,但是绝不能修改字段名称。
如果同时兼容 JSON 和二进制(原生 grpc)两种数据传输,那么就意味着这个 IDL 上的一个字段也不能更改。本质上,这是由于两种模式使用不同的字段索引方式造成的。
但如果通过 grpc-gateway 或者 Connect 这样的框架,基于 protobuf,来与前端通过 JSON 而非二进制数据做数据交互,就是另一种情况。在这种情况下,可以随便修改序号,但是绝不能修改字段名称。
如果同时兼容 JSON 和二进制(原生 grpc)两种数据传输,那么就意味着这个 IDL 上的一个字段也不能更改。本质上,这是由于两种模式使用不同的字段索引方式造成的。
👍2