正则获得国际电话前缀
2013年的时候喷过ITU这个国际电话号码，前缀是变长的问题
今天遇到问题，需要按国际区号初步分析归属地和供应商，stackoverflow和AI给的都很渣，写了个正则：
via est の 输入 输出和出入
2013年的时候喷过ITU这个国际电话号码，前缀是变长的问题
今天遇到问题，需要按国际区号初步分析归属地和供应商，stackoverflow和AI给的都很渣，写了个正则：
re.compile(r"""\+
(1 # north america
|(?: # 3 digits
21|22|23|24|25|26|29|35|37|38|42|
50|59|67|68|69|80|85|87|88|96|97|99)\d
|[2-9]\d) # two digits
+1 开头的是北美，然后依次寻找3位的，再匹配2位的。+7 本来是苏联的，现在给 哈萨克斯坦 和 俄罗斯 了，就当成两位的判定吧。via est の 输入 输出和出入
正则获得国际电话前缀
2013年的时候喷过ITU这个国际电话号码，前缀是变长的问题
今天遇到问题，需要按国际区号初步分析归属地和供应商，stackoverflow和AI给的都很渣，写了个正则：
via est の 输入 输出和出入
2013年的时候喷过ITU这个国际电话号码，前缀是变长的问题
今天遇到问题，需要按国际区号初步分析归属地和供应商，stackoverflow和AI给的都很渣，写了个正则：
re.compile(r"""\+
(1 # north america
|(?: # 3 digits
21|22|23|24|25|26|29|35|37|38|42|
50|59|67|68|69|80|85|87|88|96|97|99)\d
|[2-9]\d) # two digits
+1 开头的是北美，然后依次寻找3位的，再匹配2位的。+7 本来是苏联的，现在给 哈萨克斯坦 和 俄罗斯 了，就当成两位的判定吧。via est の 输入 输出和出入
Pushover 的五种消息优先级别
在消息推送服务 Pushover 的文档中，介绍了消息共有 5 种不同的优先级别（-2、-1、0、1 与 2）。这些级别对应了不同的消息推送模式，本篇文章对这些消息级别进行讨论。
最低优先级（-2）
根据文档描述，这种优先级别不会发送任何推送通知。在 iOS 系统中，只会使主屏幕中的图标角标的通知数量增加，相当于是一种 “静默通知”。结合单独的 Pushover “应用程序/API 令牌”（Application/API Token）来使用时，这种优先级别特别适合发送一些提示性的信息，比如在任务执行过程中产生的日志，或者重要程度低到主动想起来才有必要看的一些信息。
低优先级（-1）
这种优先级别会产生一条手机通知推送，但推送不会有任何的震动或者铃声。在 Pushover 的免打扰模式启用时，普通优先级（0）的消息会降低为该优先级的推送模式。通常，一些需要引起关注，但如果长时间不关注也不会造成太大负面影响的事件的消息推送可以考虑使用该级别。比如天气更新、日常新闻，或监控的日常股票价格走势等。
普通优先级（0）
这是默认的消息推送优先级别。以该优先级别发送的消息会正常产生推送通知，响铃以及震动。这种优先级别通常适合推送 “希望使用推送服务本意” 的事件类型，如需要引起注意的运维事件、需要响应的消息，以及到某个时间点需要进行何种动作等。
高优先级（1）
以高优先级别推送的消息会绕过 Pushover 用户设置的免打扰时间，并且消息在 Pushover 中以红色底色显示，以引起用户注意。除此之外，消息的推送模式与普通优先级别的消息相同。用户通常会在休假或完成重要任务期间开启免打扰时间。而需要通过这种优先级发送的消息的重要程度足以打断用户正在聚焦的某些工作。通常是需要立即采取行动的事件、重要天气提示以及重要任务执行异常等通知。
注意，高优先级的震动以及铃声通知无法绕过系统的静音设置，除非在 Pushover 客户端中手动设置。
紧急优先级（2）
紧急优先级具有与高优先级一致的推送策略，但会重复推送直到用户响应为止。同时，在 iOS 客户端中，用户可以为高优先级和/或紧急优先级的消息设置“重要警告”。在“重要警告”模式下，即使你已将 iPhone 静音或设置了专注模式，也会收到通知。这种模式通常适用于 Oncall 或紧急消息。
via DGideas' Blog
在消息推送服务 Pushover 的文档中，介绍了消息共有 5 种不同的优先级别（-2、-1、0、1 与 2）。这些级别对应了不同的消息推送模式，本篇文章对这些消息级别进行讨论。
最低优先级（-2）
根据文档描述，这种优先级别不会发送任何推送通知。在 iOS 系统中，只会使主屏幕中的图标角标的通知数量增加，相当于是一种 “静默通知”。结合单独的 Pushover “应用程序/API 令牌”（Application/API Token）来使用时，这种优先级别特别适合发送一些提示性的信息，比如在任务执行过程中产生的日志，或者重要程度低到主动想起来才有必要看的一些信息。
低优先级（-1）
这种优先级别会产生一条手机通知推送，但推送不会有任何的震动或者铃声。在 Pushover 的免打扰模式启用时，普通优先级（0）的消息会降低为该优先级的推送模式。通常，一些需要引起关注，但如果长时间不关注也不会造成太大负面影响的事件的消息推送可以考虑使用该级别。比如天气更新、日常新闻，或监控的日常股票价格走势等。
普通优先级（0）
这是默认的消息推送优先级别。以该优先级别发送的消息会正常产生推送通知，响铃以及震动。这种优先级别通常适合推送 “希望使用推送服务本意” 的事件类型，如需要引起注意的运维事件、需要响应的消息，以及到某个时间点需要进行何种动作等。
高优先级（1）
以高优先级别推送的消息会绕过 Pushover 用户设置的免打扰时间，并且消息在 Pushover 中以红色底色显示，以引起用户注意。除此之外，消息的推送模式与普通优先级别的消息相同。用户通常会在休假或完成重要任务期间开启免打扰时间。而需要通过这种优先级发送的消息的重要程度足以打断用户正在聚焦的某些工作。通常是需要立即采取行动的事件、重要天气提示以及重要任务执行异常等通知。
注意，高优先级的震动以及铃声通知无法绕过系统的静音设置，除非在 Pushover 客户端中手动设置。
紧急优先级（2）
紧急优先级具有与高优先级一致的推送策略，但会重复推送直到用户响应为止。同时，在 iOS 客户端中，用户可以为高优先级和/或紧急优先级的消息设置“重要警告”。在“重要警告”模式下，即使你已将 iPhone 静音或设置了专注模式，也会收到通知。这种模式通常适用于 Oncall 或紧急消息。
via DGideas' Blog
感觉大家慢慢正在达成一个共识，那就是大部分人自己直接写的 prompt 都是不合格的，DeepSeek R1 的最佳使用场景不是直接用来输出，而是一个 prompt 优化器。通过推理过程把初始 prompt 优化之后再喂给 instruct 模型。
十分同意 Jarod 的观点，实际上写 Prompt 对于普通用户来说，要求也太高了。以及，由于大模型的不稳定性，如果为一次性任务写 Prompt，代价过高。但是，对于日常情景来说，大部分 AI 接到的可能是一次性任务——如果自己很快就能做完，可能也就不必想着问 AI。
在这种情况下，使用一个表现较好的模型，对用户的需求进行预处理，那么就可以令产品本身的表现变得稳定。
via Home - Space Looming
十分同意 Jarod 的观点，实际上写 Prompt 对于普通用户来说，要求也太高了。以及，由于大模型的不稳定性，如果为一次性任务写 Prompt，代价过高。但是，对于日常情景来说，大部分 AI 接到的可能是一次性任务——如果自己很快就能做完，可能也就不必想着问 AI。
在这种情况下，使用一个表现较好的模型，对用户的需求进行预处理，那么就可以令产品本身的表现变得稳定。
via Home - Space Looming
能动性 > 智力
在人工智能领域，广受关注的 Andrej Karpathy 又发了一篇好文，原文：
via Home - Space Looming
在人工智能领域，广受关注的 Andrej Karpathy 又发了一篇好文，原文：
能动性 > 智力
这几十年，我直觉上一直搞错了，我认为这是由于一种普遍的文化对智力的推崇，各种娱乐/媒体，对智商的痴迷等等。能动性要强大得多，也稀缺得多。你招聘时看重能动性吗？我们教育是为了培养能动性吗？你的行为是否像拥有10倍的能动性一样？
Grok的解释比较接近：
“能动性，作为一种人格特质，指的是个人采取主动、做出决策并控制其行为和环境的能力。它关乎积极主动而非被动反应——具有高度能动性的人不会只是让生活发生在他们身上；他们塑造生活。可以把它看作是自我效能、决心和对自身道路的掌控感的结合。
具有强大能动性的人倾向于设定目标并充满信心地追求它们，即使面对障碍。他们是那种会说“我会解决它”然后真的去做的人。另一方面，能动性低的人可能更像自己生活中的乘客，等待外部力量——比如运气、其他人或环境——来决定接下来会发生什么。
它与自信或雄心壮志并不完全相同，尽管它们可能重叠。能动性更安静，更内在——它是一种你*可以*行动的信念，以及贯彻执行的意愿。心理学家经常将其与控制点等概念联系起来：高能动性的人倾向于内在控制点，感觉他们掌控自己的命运，而低能动性的人可能倾向于外在控制点，认为生活是*发生在*他们身上的事情。”
via Home - Space Looming
容器（一）
容器技术发扬光大
都知道 Docker 开启了容器时代，但是 Docker 的使用的 namespace、cgroups 并不是啥新鲜技术，这两项东西在 Linux 内核里面早已准备好了。话虽如此，容器技术在当时并不流行，和人们想象中的 PAAS 还有差距。
那 Docker 的创新点在哪？UnionFS，这是 Docker 相较于当时其他容器化技术创新的一点，搞定了容器运行时的环境问题，rootfs 可以为程序提供一个类似于宿主机的文件环境，UnionFS 方便了容器的构建、分发，使用。要知道在当时早已有基于 namespace 和 cgroups 的 LXC 容器化技术，但和其他容器化技术一样，早已不温不火了。
容器编排花落谁家
Docker 虽然把容器化技术发扬光大，让 PAAS 平台都接纳了 Docker 这个容器运行时，但当时 Docker 是没有官方的编排系统的，而且 当时 Docker 很多东西都是闭源的，没有提供 API 可用于编排系统开发，导致社区也无法去提供相关方案，在当时， PAAS 厂商只能自行实现自己的方案，Docker Compose 都是后来自救的产物。
恰逢此时，Google 发现了 Docker 在容器编排领域的劣势，基于 Google 自己的编排系统 Borg，吸收其精华开发了现在大名鼎鼎的 Kubernetes（k8s）。相较于 Docker 的闭源，k8s 在一开始就取得了开发者的青睐，在良好的社区领导下，开源社区的力量让 k8s 的发展速度非常之快，也是 CNCF 第一个毕业项目。当然 Docker 此时也没坐以待毙，开发了适用于单机编排的 Compose，集群编排的 Swarm，当然，从结果就知道了，Swarm 并未掀起什么浪花。同期还有其他容器编排系统，比如 Mesos。Docker 为了自救还把自己的容器引擎独立了出来，也就是后来的 Containerd ，捐赠给了 CNCF。至此（Docker 赔了夫人又折兵，被榨干了），以后也就 Dockerhub 这个容器仓库、Compose这个单机编排工具耳熟能详了，至于 Swarm，基本没有市占率。群雄逐鹿，k8s 成为了最后的王者，企业容器编排的首选方案。
个人学习之路
小故事讲完了，我个人的集群学习之路反而不是从 k8s 开始的，而是 Docker Swarm。它开启了我对集群的认识，让我感受到原来跨主机编排（集群编排）的魅力，虽然引入了一堆新的问题，但是集群网络的互联互通是真的很舒服。一个节点的容器可以访问另一个节点的容器，而不是通过 gateway(apisix/nginx)等中间件来暴露两者来进行互联。Docker Swarm 操作也简单，Docker 软件套件自带，非常适合入门学习集群相关的理念，作为跳板上手 k8s。
现在的 k8s 调用链，kubelet -> containerd -> containerd-runc-shim -> runc
曾经的 k8s 调用链，kubelet -> docker-shim -> docker -> containerd -> containerd-runc-shim -> runc
runc 也是最底层的容器运行时，负责最基础的运行时功能，可以看到在这里面有两个 shim（垫片），其实就是个中间件，用来翻译 API 调用，也保证了底层组件对上层是透明的。
可以看到在 Containerd 成熟之后，k8s 果断抛弃了 Docker。一部分是竞争，一部分是维护起来太费力了，Docker 发版的话，kubelet 为了兼容，必须跟着强制发版，而且 Docker 自己也是调用 containerd，那为啥不直接用 Containerd 呢？还减少一层调用。
看完了？说点什么呢
via TimochanのBlog
该渲染由 marked 生成，可能存在排版问题，最佳体验请前往：https://www.timochan.cn/posts/any_pen/conatiner_one
容器技术发扬光大
都知道 Docker 开启了容器时代，但是 Docker 的使用的 namespace、cgroups 并不是啥新鲜技术，这两项东西在 Linux 内核里面早已准备好了。话虽如此，容器技术在当时并不流行，和人们想象中的 PAAS 还有差距。
那 Docker 的创新点在哪？UnionFS，这是 Docker 相较于当时其他容器化技术创新的一点，搞定了容器运行时的环境问题，rootfs 可以为程序提供一个类似于宿主机的文件环境，UnionFS 方便了容器的构建、分发，使用。要知道在当时早已有基于 namespace 和 cgroups 的 LXC 容器化技术，但和其他容器化技术一样，早已不温不火了。
容器编排花落谁家
Docker 虽然把容器化技术发扬光大，让 PAAS 平台都接纳了 Docker 这个容器运行时，但当时 Docker 是没有官方的编排系统的，而且 当时 Docker 很多东西都是闭源的，没有提供 API 可用于编排系统开发，导致社区也无法去提供相关方案，在当时， PAAS 厂商只能自行实现自己的方案，Docker Compose 都是后来自救的产物。
恰逢此时，Google 发现了 Docker 在容器编排领域的劣势，基于 Google 自己的编排系统 Borg，吸收其精华开发了现在大名鼎鼎的 Kubernetes（k8s）。相较于 Docker 的闭源，k8s 在一开始就取得了开发者的青睐，在良好的社区领导下，开源社区的力量让 k8s 的发展速度非常之快，也是 CNCF 第一个毕业项目。当然 Docker 此时也没坐以待毙，开发了适用于单机编排的 Compose，集群编排的 Swarm，当然，从结果就知道了，Swarm 并未掀起什么浪花。同期还有其他容器编排系统，比如 Mesos。Docker 为了自救还把自己的容器引擎独立了出来，也就是后来的 Containerd ，捐赠给了 CNCF。至此（Docker 赔了夫人又折兵，被榨干了），以后也就 Dockerhub 这个容器仓库、Compose这个单机编排工具耳熟能详了，至于 Swarm，基本没有市占率。群雄逐鹿，k8s 成为了最后的王者，企业容器编排的首选方案。
个人学习之路
小故事讲完了，我个人的集群学习之路反而不是从 k8s 开始的，而是 Docker Swarm。它开启了我对集群的认识，让我感受到原来跨主机编排（集群编排）的魅力，虽然引入了一堆新的问题，但是集群网络的互联互通是真的很舒服。一个节点的容器可以访问另一个节点的容器，而不是通过 gateway(apisix/nginx)等中间件来暴露两者来进行互联。Docker Swarm 操作也简单，Docker 软件套件自带，非常适合入门学习集群相关的理念，作为跳板上手 k8s。
现在的 k8s 调用链，kubelet -> containerd -> containerd-runc-shim -> runc
曾经的 k8s 调用链，kubelet -> docker-shim -> docker -> containerd -> containerd-runc-shim -> runc
runc 也是最底层的容器运行时，负责最基础的运行时功能，可以看到在这里面有两个 shim（垫片），其实就是个中间件，用来翻译 API 调用，也保证了底层组件对上层是透明的。
可以看到在 Containerd 成熟之后，k8s 果断抛弃了 Docker。一部分是竞争，一部分是维护起来太费力了，Docker 发版的话，kubelet 为了兼容，必须跟着强制发版，而且 Docker 自己也是调用 containerd，那为啥不直接用 Containerd 呢？还减少一层调用。
看完了？说点什么呢
via TimochanのBlog
StoryTribe 不用 AI 用故事圖畫板製作工具，幫簡報案例說個好圖解
AI 時代有便利的自動圖解工具像是：「 Napkin 」， AI 分析文本後會生成各種流程圖、心智圖到特殊手繪圖解。 這時候，我們會需要一個「自己手動組合」的圖解工具嗎？
via 电脑玩物
AI 時代有便利的自動圖解工具像是：「 Napkin 」， AI 分析文本後會生成各種流程圖、心智圖到特殊手繪圖解。 這時候，我們會需要一個「自己手動組合」的圖解工具嗎？
via 电脑玩物
难道我发现了大模型的基本逻辑？
今天在思考，集合论、范畴论视角下的标签体系。毫不意外，涉及到了文本相似度计算这一基础算法。但这套算法还是比较机械的，不具备语义性。
然后，当我要求从语义出发，去寻找文本的相似性时，一切都有趣起来了——最终和 AI 聊天得到的结果是，只要从这个逻辑出发， AI 就会告诉我一大堆大模型的基础实现方法。
集合论、范畴论视角下的标签体系（系统），是大模型设计的基本角度吗？看上去是。
via Home - Space Looming
今天在思考，集合论、范畴论视角下的标签体系。毫不意外，涉及到了文本相似度计算这一基础算法。但这套算法还是比较机械的，不具备语义性。
然后，当我要求从语义出发，去寻找文本的相似性时，一切都有趣起来了——最终和 AI 聊天得到的结果是，只要从这个逻辑出发， AI 就会告诉我一大堆大模型的基础实现方法。
集合论、范畴论视角下的标签体系（系统），是大模型设计的基本角度吗？看上去是。
via Home - Space Looming
关我辟事 Vol.34：应接不暇
最近工作有点忙，虽然也不至于一直加班，但可支配时间是比之前不上班时候少太多了（废话），工作可能也从 onboarding 变成个稍微能干点活儿的牛马，有了按时 deliver 的 expectation 之后就匆忙了很多，感觉这两周注重生活质量的比例大幅下降，外加一些乱七八糟的 adulting，就有种疲于奔命的感觉。从现在到月底又是要 travel + 出差的半个月，土拨鼠尖叫，又想放长假了。
本文就本来应该是 2 月中发的，但是那个周末去 SF 了，没想到行程满到连日记都断更了几篇，这篇更是拖了 10 天才找到时间写完 orz 本来思考一下要不要直接跟下半月的合并了毕竟发的时候都 25 号了，转念一想都是 arbitrary number，读者并不 care 具体是啥时候发生的，当时分成半月刊不就是为了字数不要那么长稍微读起来轻松一点嘛，索性还是截止到上半月了～
本期亮点：
● 没错，就是拖到月底了也不会和下半月合并的！偏要勉强.txt
● 西雅图 “2024”的初雪，来得比以往时候都晚一些
● 海量超可爱毛绒玩具和乐高！
● 一些可支配收入和消费/抠门心态的重新思考。钱确实买不来快乐但能买来自由。
● 可能是创刊以来最大量的书和游的一期了，附送干货读书笔记
● 好多年没玩写实风的 3A 了，不虚此行又沉迷游戏了，爱好没丢！
●
via 椒盐豆豉
最近工作有点忙，虽然也不至于一直加班，但可支配时间是比之前不上班时候少太多了（废话），工作可能也从 onboarding 变成个稍微能干点活儿的牛马，有了按时 deliver 的 expectation 之后就匆忙了很多，感觉这两周注重生活质量的比例大幅下降，外加一些乱七八糟的 adulting，就有种疲于奔命的感觉。从现在到月底又是要 travel + 出差的半个月，土拨鼠尖叫，又想放长假了。
本文就本来应该是 2 月中发的，但是那个周末去 SF 了，没想到行程满到连日记都断更了几篇，这篇更是拖了 10 天才找到时间写完 orz 本来思考一下要不要直接跟下半月的合并了毕竟发的时候都 25 号了，转念一想都是 arbitrary number，读者并不 care 具体是啥时候发生的，当时分成半月刊不就是为了字数不要那么长稍微读起来轻松一点嘛，索性还是截止到上半月了～
本期亮点：
● 没错，就是拖到月底了也不会和下半月合并的！偏要勉强.txt
● 西雅图 “2024”的初雪，来得比以往时候都晚一些
● 海量超可爱毛绒玩具和乐高！
● 一些可支配收入和消费/抠门心态的重新思考。钱确实买不来快乐但能买来自由。
● 可能是创刊以来最大量的书和游的一期了，附送干货读书笔记
● 好多年没玩写实风的 3A 了，不虚此行又沉迷游戏了，爱好没丢！
●
哪吒2当真跟黑神话是一个中国特色的人海战术思路呀……作为前作的粉我觉得虽过誉但超出预期。via 椒盐豆豉