连波的闲谈杂鱼

2025 年终总结

Mon, 16 Mar 2026 21:00:00 GMT

许老三今年过得很累，身心疲惫。

这累不是来自于别人，也不是来自生活，而是来自他自己 —— 他变得不会说话了。

但这并不怪他，他本来就是个嘴笨的人；远程工作几年下来，他变得更笨了；就像他老婆说的，他就像个孩子。

比如有一次开会，同事问他某个问题时，他滔滔不绝地讲了五分钟，最后同事不得不打断他：“我问的不是这个”。许老三老抓不住重点，从这里就能看出来。并且他也不会讲重点，他最喜欢的就是打比方。比如什么什么的，举个例子之类的，许老三就经常用到；他以为这样能让观点更实际，而他不知道的是他往往把一个简单的事情搞得复杂。

年初的时候，许老三就因为这方面的问题被同事认为是初级工程师。虽然他嘴上说对这些称谓无所谓，但面子上还是挂不住。看不起谁呢？他堂堂工作了十年的资深工程师，竟然被人当作初级工程师看待。他急需要证明自己，证明自己是优秀的。于是那段时间他努力的写 PR，拼命的接任务，想让同事们看到他的工作和质量。而时间久了，当没人说他的不是了，许老三就觉得自己变得优秀了，又开始放纵了；直到下一次因为同样的问题再次犯错，他才知道自己的优秀是假的，是自已为的。而这种感觉许老三不会让它待太久，过了不出十天，他就忘了，又觉得别人是不如他的了。

他就是这样，戳一下，跳一下。

还有一次，许老三跟了一个任务一个月都没做完，然后又被说了，说他做得慢。这许老三又不服了，他觉得自己做了这么多工作，提了 8、9 个 PR，写了一堆文档，这一揽子下来，还被人嫌做得慢，这肯定不是他的问题，他自己依然是优秀的。而他不知道的是，他那个高级工程师的同事，就没他这些破事。

后来有一天，许老三的领导找他谈话，委婉地说：“你可能需要在沟通上多注意一下。” 许老三听了，也记下了。后面再跟同事沟通的时候，许老三就会特别注意，甚至每次都要用 AI 润色一下。时间久了，没人说他的不是了，他就觉得自己在沟通上已经做得很好了，就又开始放纵了。他就是这样，戳一下，跳一下。

要说许老三今年有什么值得写的事情，大概就是他已经把所有的工作流都迁移到 AI 了。用 AI 写代码，用 AI 回复 Slack，用 AI 创建 PR，用 AI 写文档；他变成了给 AI 打工的人。半年下来，他已经没有手写过代码了，现在连改个错别字，他都要指挥 AI。噢，他还写了一个 macOS mebubar App - myfriendtime，虽然至今只有他一个人在用。他还因为喜欢 Zed Editor，做了个 zed.tips 网站，虽然也就那样；但许老三挺享受 vibe 的过程的，尽管做得很粗糙，一步一步把它们搭起来的感觉却是挺好的。

这年来 AI 的发展让许老三有一些不安。从去年下半年开始，许老三就感觉风向变了。之前读的那些书，学的那些不为人知的技术，好像都不重要了。他不止一次地问过 AI：这次兴起的 AI 革命，是不是和之前的互联网、iPhone4 一样，都是跨时代的产品？他，许老三，是不是得趁机站在风口上，不然这波窗口期过后，他又能靠什么还房贷呢？

而许老三最擅长的就是想。他想了很多，却从来不实践。

比如许老三想做一个有记忆的翻译 App，想了很久，到现在都没下文。比如他还想过做一个自己的 Agent，至今这个项目还没启动。而所有这些，还没等许老三去想好，市面上就已经有现成的产品了。

他就像个旁观者，看着别人把他的想法都做出来，然后他继续想下一个。

往年总结

许老三的腿断了

Wed, 21 Jan 2026 17:36:00 GMT

许老三的腿断了，是在梦里。

梦里一架直升机朝他飞来，螺旋桨的声音震得耳疼。几个人从机舱里下来，穿着白色制服，拿着斧头，一言不发地朝他走过来。

他们什么也不说，什么也不问；两个人按住他，另一个举起斧头就开始砍腿，动作熟练得仿佛这腿本就是他自己的一样。许老三想哭，想喊，却发不出任何声音。虽然害怕但他却感觉不到疼。斧头落下来的时候，他突然觉得踏实了，好像这件事本来就会发生。

路上不断有行人经过，许老三想叫住他们，喉咙却像被什么堵住了一样。他们把许老三砍下来的那条腿包好，放进保温箱，坐着直升机飞走了。

许老三的腿飞走了，但他心里还挺庆幸的，他还有一条腿。路上的行人回过头来看了看许老三，又看了看自己的腿，转头继续往前走了。

许老三听说他的腿会被接到另一个人身上。那是许老三的腿，但又不是他的腿了。那个人住更好的房子，穿更舒适的裤子和鞋子。许老三想，那条腿在那里应该会过得更好。

他又看了看自己的手、耳朵、眼睛，这些好像都不是他的了。

许老三醒了，还好是一个梦，梦里的世界真可怕。他又摸了摸自己的腿，还在，但为什么觉得那么陌生，好像随时都会有人来把它取走。

吐口水

Tue, 18 Nov 2025 15:56:00 GMT

中国人人人具有吐口水的本领，而要说把这本领发挥得淋漓尽致的，要数许老三。

许老三吐口水，向来随心所欲。不管是在商场中，或是餐馆的地板上，甚至是电梯里。只需要微微低头，嘴唇轻启，酝酿片刻。那神情专注得仿佛在做什么了不起的大事；接着先是呼噜一声，将鼻涕全数吸入鼻腔；再深呵几下，调动喉咙深处的痰液；最后噗地吐出，一道浑浊的白练破空而来。整套动作行云流水，毫无半点滞涩。

我对此道向来不甚了解，说起来有些丢人。偶尔在街头巷尾，看见有人呸地一声，总是侧目而视，心中颇为不自在。但自从见识了许老三的本事，才知道这吐口水原来也是一门学问。

许老三也不是在什么地方都随心所欲，什么时候应该克制，什么时候应该放纵，他有着自己的一套哲学。比如在与人聊天时，他就绝不轻易出手，显得颇有分寸。即使实在憋不住了，也一定是先瞄准脚边，再噗地吐在地上，然后慌忙用鞋踩上去，来回摩擦，企图将那摊污物与地面融为一体，生怕被别人看穿了他口水里的秘密。

更令人称奇的是，许老三吐出的口水，竟有不同的品类。有时细长如丝，稍不注意就会落到自己衣服裤子上；有时圆润如珠，力道十足；更为奇妙的是当许老三感冒时吐的口水，竟然会变成如绿玉般的温润莹泽。据他自己说，这全凭当时的心境和目标而定，绝非随心所欲。

我曾亲眼见他与人打赌，说能隔着三丈远吐中一个烟头。大家都以为他在吹牛。谁知许老三不慌不忙，深吸一口气，鼓起腮帮，呸地一声，那口水划出一道完美的弧线，哒的一声正中烟头。众人无不拍手叫绝。

许老三得意的笑了气，又呸地吐了一口，这次却是随意得很，落在自己脚上。他说：刚才那口是技术，这口才是享受。

我本来见吐口水感到不适，写到这里，更觉得恶心起来。

刷抖音

葡萄架

Mon, 03 Mar 2025 11:09:00 GMT

老丈人的院塘旁边有一颗葡萄树，几十年了，却没人吃到过葡萄。

葡萄是长在院塘岸边的，长得不高，全靠一棵刺玫瑰和一笼杂草把它撑起来。正因为如此，虽然有这么多年了，却很少结果。但我是看到过葡萄的，就吊在那根刺玫瑰上，绿色的一串，也只有一串。

几年前，老丈人的院坝前还有一个丝瓜架；丝瓜我不太喜欢，就挖了一根葡萄种在旁边，想着让它顺上丝瓜的架子。葡萄是种活了的，还发了芽；但是被老丈人砍了；老丈人看起来更喜欢丝瓜。

前几年，老丈人的丝瓜架因为修房子拆了，我就再不能在旁边种葡萄了。但我看到院塘边上的葡萄又发了芽，想着在院塘边也搭一个葡萄架吧。

这是那种本地葡萄，酸得很，老丈人说到。

我知道老丈人说的这种葡萄，我小时候见过，就在三公家院坝，缠在一棵李子树上的，每年都结得很多。三公却很小气，总是在李子树分叉的树干绑上很多刺，不准我们爬上去；偶尔我们会吃到一串，我记得那个味道，一点也不酸。

但这些场景只在我心里，我体验过，现在却只能通过机器帮我画出来；而机器画出来的，孩子体验不到，所以我想着再搭个葡萄架。

又过了一年，院塘边的葡萄又长起来了，我看着很难受，对阿宝说，搭个架子吧。

现在还不是时候，要等来年叶子全掉了，才好搭架子

对，叶子掉了才好搭

于是又过了一年，叶子掉了，但没人还记得要搭架子，我也忘记了。

直到上周，我们送老丈人回去，又看到这棵葡萄树了，叶子全掉完了，趴在那里，有气无力的；这次我再也不能把它忘了，我得把架子搭起来。

"这葡萄不好吃的"
"后面有时间慢慢搭嘛"
"你搭这个来干啥子嘛"
"你一个人搭不起的"
"得在水里立一根木柱"
"应该把架子搭在这里，搭在水塘上不好摘"

搭葡萄架是一件很小的事情，行动起来却有如此多的阻碍。我不管了，中午下班后，找了把锯子，一把砍刀。就去砍竹子去了。

那竹子太高了你砍倒了也拖不上来

你去砍点树，等他干了明年再来搭吧

不，我就要去砍竹子。我花了两个小时才砍了一根竹子上来，如老人所说，确实不太容易；再在众人七嘴八舌的指导下，完成了这个葡萄架的搭建。搭一个葡萄架最好的时间原来不是去年冬天，就是现在。

虽然很简陋，但我期望它今年能结果。

老丈人系列

2024 年终总结

Fri, 03 Jan 2025 21:00:00 GMT

许老三今年是不打算写年终总结的，这总结本该是成功人士的事儿；他今年没有成功；那本不用写；但为什么又动笔了呢？想来是看别人都写了，他也得写点；大家都干的事儿，他又为什么不能干呢？就像跨年夜后的广场，一片狼藉，大家都在丢垃圾，就他把垃圾放到口袋里，那他就吃了一个哑巴亏；又比如所有人都在裁员名单里，就他不在，他就恨不得把自己的名字也加上去，不然又吃了个亏；许老三不愿意吃亏，特别不愿意吃年终总结这种小事的亏。

然而别人写年终总结时手到拈来，许老三这儿可费劲了；他不得不一篇一篇的翻着别人写的总结，看别人怎么写，用了什么结构，记录了那些亮点，又或是规划了什么样的未来。然后许老三拿出自己的看家本领，将它们都一一抄过来。把那些发生在别人身上的新鲜事，改为自己的；许老三今年没什么大事，但他有自己的想法，比如把会见诺贝尔奖得主改为出去和朋友喝了点啤酒、把日本泡温泉改为省外一日游，把跑了几千公里的步改为回了几趟农村。

就这样许老三的总结很快就写完了，但他对这并不满意，这没有突出他对生活的热爱，对技术的追求。比如年初的时候，他看到大家都去日本看樱花，去金阁寺烧香；金阁寺让不让烧香他不知道，但名字有个寺，终归是能烧香的吧。他倒不是说要去烧香，他不喜欢烧香，也不是说要去这金阁旅游，而是大家都在讨论金阁，他也得参与近来，不然他就吃了个亏；而他又对金阁一无所知，只好买了本书来看，名字就叫金阁寺。

书是买回来了，才看到一半，大家又在讨论独立开发了。许老三就把书放回了书架，心想此一时彼一时，之前大家都在讨论金阁，自己不看点什么就是吃亏了；但现在大家讨论的是独立开发了，那之前这亏，他必是吃不到了。于是就动手写了几个浏览器扩展。为什么写浏览器扩展而不是 APP，一是他不会写 APP，二是因为大家都在写浏览器扩展，他去写 APP 他就吃了不会写浏览器扩展的亏，他不想吃亏。刚开始时许老三很自信，自己的产品将是全世界最完美的最独特最人性化的，所以每一行代码都经过精心打磨，设计模式最佳实践什么的，许老三最爱了。许老三还交了 5 刀的 Google Chrome Store 入门费，但他的扩展却至今没有提交到谷歌应用商店，因为 AI 又来了。

时代变了，之前大家讨论的是独立开发，但现在大家讨论的更多的是 AI，此一时又彼一时，那这独立开发的亏，被 AI 替代后，他必是又吃不到了。不过许老三觉得有点累了，他甚至开始不满这些追逐潮流的人，或者说是搅屎棍。这些搅屎棍让许老三吃的亏越来越多了，什么 Cursor，Windsurf，Gemini，V0，许老三还来不及学第一个，大家就已经在讨论下一个了。就拿前几天他刚付了 1000 块钱找人开通了 Azure OpenAI，但大家突然又说 OpenAI 不行了，还是换 Gemini 吧。许老三心里十分不满，对这些搅屎棍的恶意又多了几分。许老三心想，明明一个 GPT4 就能搞定的东西，瞎折腾什么呢。但许老三又不愿意吃亏，就不得不跟在这些时代的搅屎棍后面，吃别人剩下的。

要说许老三今年又什么值得骄傲的，那想必是孩子长到两岁了，写了个博客，写了几篇文章，吃了几顿媳媳妇做的好吃的。孩子长到两岁本不是许老三的功劳，是他媳妇的；吃饭做饭洗澡穿衣，都是他媳妇做的；但夹边人只知道他和他媳妇一起将孩子养到了两岁，那这功劳，便有他一份了。写了个博客倒是获得了很多人的喜欢，但这喜欢并不是对他的，而是他抄的那个博客的；大家喜欢的不是他许老三的博客，而是他抄的那个博客，但大部分人不知道许老三从那里抄的，那这份喜欢，许老三便接下了。许老三抄东西在行，但写没人写过的东西就犯难；但许老三自己不知道这一点，他以为自己是牛逼的；就算抄别人的东西，抄完变成自己的，就觉得别人是不如自己的；

许老三的老婆知道他这一点，还告诉过他要务实，要脚踏实地，要专一，但许老三说：我不想吃亏。

许老三不知道，他吃的亏，不是别人给的，而是自己找的。

Some Pictures of 2024

Next Year Predictions By AI

A Cat In My Home

Work Hard, Play Hard

如何快速搭建自己的博客网站

Fri, 16 Aug 2024 16:40:00 GMT

前段时间将我的博客开源后，陆陆续续的收到很多朋友的喜欢，也有朋友在部署或自定义时遇到了各种各样的问题，更收到了快 50 岁的非专业程序员的邮件咨询，很是开心。所以我打算写一篇文章来帮助大家更快的基于 gblog 搭建自己的博客。

准备

在开始之前需要有一些准备知识；原本我是想写一篇从 0 开始的，那我发现那涉及到的知识太多了；所以我假设大家都有如下的背景：

会一些简单的前端技术(如知道什么是 HTML/JS/TS)
有 GitHub 账号
本机安装了 GIT/NodeJS (可选)
会使用终端执行命令行程序(如 npm run dev 等，可选)
有 Cloudflare 账号(可选)

如果你没有任何技术背景可能会问为什么需要掌握这些知识，因为这是一个静态博客，没有管理后台、没有数据库；这意味着所有的博客数据都是存储在一个个 HTML 中的，你想做的任何修改，都只能直接修改源代码。

不过不用过于担心，我将在下面的教程中一步步的引导你如何设置。

如何部署

本着 Success First 的原则，我们先来将它部署到 Cloudflare 平台上。如果你想要部署到其他平台如 Zeabur 和 Vercel，只需要点击文档里的 Deploy 按钮就能一键部署到对应的平台上。

Deploy to Cloudflare 1 - Create a new Fork

登录你的 GitHub 账号并 Fork 一下 gblog 项目
注意在 fork 时需要取消勾选「Copy the astro branch only」

GitHub 的 fork 允许你快速的在自己的账号下创建一个和原项目一模一样的项目；而为什么要取消勾选是因为我们要使用另外的分支(gblog-template)来部署；默认的 astro 分支包含了我所有的博客文章和图片，它会导致在首次部署时因为需要优化图片而花费很长的时间；当然你也可以使用最新的 astro 分支然后删除 src/content/posts 下的数据也加快编译。

Deploy to Cloudflare 2 - Build

项目 fork 完成后，登录你的 Cloudflare 账号。在左侧菜单栏找到 Workers & Pages，然后新建一个 Page。具体步骤可以参考这个文档，也可以参考下面的视频片段。注意在选择 Production branch 时为了节省 build 时间可以选择 gblog-template 分支。

部署成功后，你可通过 Cloudflare 提供的默认域名访问我们刚刚创建的博客，如果一切正常，你能看到一个很好的博客页面如 https://gblog-test-1.pages.dev。

如何发布文章

静态类型的博客网站并没有一个管理后台来管理博客数据，我们也没有计划为 gblog 添加 CRM 支持。所以如果你想要发布自己的文章，你需要在对应的目录添加一个新文件，一个文件就是一篇博客。

最简单的方式是通过 GitHub 在 src/content/posts 文件夹下添加文件，如下所示：

文件后缀一般为 .md 或许 .mdx；博客文章的固定格式如下所示，更多的配置项你可以查看这里的定义：

---
title: "标题"
description: "描述"
pubDate: "发布时间如 2021-11-12 03:10:04"
category: "tool"
banner: "封面图“
tags: ["标签1", "标签2"]
---
 
正文

MD/MDX 都是 Markdown 格式的文本内容，如果你对这种格式不太熟悉，我推荐你看看这里的 Markdown 教程。

博客文章的固定格式这里有几个需要注意的点：

英文冒号 (:) 前面的为属性名，后面的为属性值；属性值通常会使用英文双引号包裹起来
一篇文章的分类 (category) 只能有一个，并且只能是 src/content/categories 下面已有文件的文件名(如 astro/tool 等)
如果你想添加&删除更多的分类，请直接修改 src/content/categories 下面的文件
文章的封面图(banner)可以是在线图片地址如 https://example.com/a.png
文章的封面图(banner)如果是本地图片，需要放到 src/images/ 目录下
1. 如你在 src/images 目录下新创建了一个文件夹 hello 并且把一张图片如 banner1.png 放了进去，那你这篇文章的 banner 字段可配置为：@images/hello/banner1.png，注意前面有个 @ 符号

下面请看一个例子。我们新建了一个 hello.md 的文件，当所有内容都准备好了并点击第四步 Commit changes 后；由于我们在第一步时已经成功部署到了 Cloudflare 平台，所以如果这里不出意外的话当你提交代码后，你的修改会自动部署到 Cloudflare。待其部署成功后，就可以通过如 https://example.com/posts/hello 访问刚刚新增的博客内容。

如何在线修改项目(可选)

如果你不方便在本地修改&运行项目，你可以通过 github.dev 在线修改博客内容；具体做法是：

将你的项目地址如 https://github.com/godruoyi/gblog 中的域名后缀从 com 换为 dev
或者直接在 GitHun 的项目页面按 . 键(英文输入法的句号)

这都将打开一个基于 VSCode 的在线编辑器，你可以在里面修改任何你想修改的内容，更多 github.dev 的用法请参考 github.dev 基于 web 的编辑器。

如何在本地启动项目(可选)

在本地启动项目前先确认你安装了 Git；你可以打开你的电脑终端(Windows & MacOS)并在上面输入如 git --version 确认，这通常会输出已安装软件的版本信息，如下面我本地的版本。如果你还没有安装他们，可以点击文末的链接安装它。

安装成功后在你的终端里执行下面的命令：

git clone git@github.com:yourname/your-blog.git myblog

Git Clone 命令会将你的项目代码下载到当前运行命令所在目录下的 myblog 文件夹下，请注意修改这里的项目地址为你项目的地址，如下：

这里可以选择 HTTPS 类型的项目地址或者 SSH 类型的，前者在你每次提交代码的时候都需要你输入 GitHub 的账号密码，后者可以免密提交。你可以参考这里的文章配置 SSH。

接下来通过 CD 命令进入到博客所在目录，并执行 npm install 安装依赖。如果这一步安装失败或者用时太久，你可以试试将 npm 的镜像替换为国内源，参见淘宝镜像设置教程。

# 进入 myblog 文件夹
cd myblog
 
# 安装博客所需依赖
npm install
 
# 在本地启动一个开发预览版本
npm run dev

最后一条命令运行成功后，你应该能看到一个如下的提示，这意味着我们的博客已经成功在本地运行。你可以访问 http://localhost:4321/ 查看本地预览版本，也可以用自己感兴趣的编辑器如 Sublime Text、VSCode、IDEA 打开并编辑它们。

本地修改完成后，你可以通过下面的方式将这些新的改变提交到 GitHub：

git add .
git commit -m "简短的描述下本次修改的内容"
git push

不论你是将你的博客部署到 Zeabur、Vercel 还是 Cloudflare，它们在你提交代码后都会自动部署，这通常是由于平台服务商在我们首次集成时已经为我们自动设置好了相应的触发器，所以才能提交代码后就自动部署。

如何自定义

默认的博客模版包含了很多预设的配置如 Logo/评论/SEO，默认的文案等，请使用你任何喜欢的编辑器打开源代码并编辑它们。

自定义配置

博客大多数的配置都定义在 src/config.ts 文件中，你可以修改它们为任何你期望的样子：

export const SITE: Site = {
    author: 'Godruoyi',
    url: 'https://godruoyi.com',
    title: '连波的闲谈杂鱼',
    description: 'Godruoyi\'s personal blog, I enjoy the process of building something using any technology stack',
}

自定义图片

目前博客使用下面几张图片作为系统图片，请用你自己的图片替换它们；如果需要修改文件名，请全局搜索所有相关的文件名并一起替换。

src/images/brand_logo.jpeg        Logo 
src/images/default_home_og.png    分享博客首页到社交平台如 Twitter 展示的分享图片 
src/images/favicon_icon.png       ICON
src/images/favicon_icon.svg       ICON SVG 格式 
src/images/footer.png             页面底部右侧显示的展位图
src/images/home.png               首页头部图片

自定义描述

有一些文案描述如「生活不能让人处处满意，但我们还要热情的生活下去」并没有放到配置文件中，你需要全局搜索然后找到对应的文件并修改它们。

自定义评论

我们目前使用 https://giscus.app/ 作为评论系统，你可以参考 Giscus 官网查看如何配置它们，也可以参考 liruifengv 的这篇博客 https://liruifengv.com/posts/add-comments-to-astro/.

注意博客评论默认是关闭状态，你可将 COMMENT_ENABLE 环境变量的值设置为 true 或者直接在 src/config.ts 文件中修改它们。

export const Settings = {
    Comment: {
        // enable: !!(import.meta.env.COMMENT_ENABLE),
        enable: true,
        giscus: {
            repo: 'godruoyi/gblog',
            repoId: 'MDEwOlJlcG9zaXRvcnkxMjcyODI0NzA',
            category: 'Announcements',
            categoryId: 'DIC_kwDOB5YtJs4CfZnX',
            darkThem: 'noborder_gray',
            lightThem: 'light',
        },
    },
}

将资源上传到 S3 加速访问

我们可以将编译后的所有资源文件如图片/CSS/JS 全部上传到 S3/R2 平台以加速访问；这个特性基于 Yufan 老师的 astro-uploader 工具，请访问该项目查看如何配置它们。

// src/config.ts
export const Settings = {
    Assets: {
        uploadAssetsToS3: !!(import.meta.env.S3_ENABLE),
        config: {
            paths: ['assets'],
            endpoint: import.meta.env.S3_ENDPOINT as string,
            bucket: import.meta.env.S3_BUCKET as string,
            accessKey: import.meta.env.S3_ACCESS_KEY as string,
            secretAccessKey: import.meta.env.S3_SECRET_ACCESS_KEY as string,
            root: 'gblog',
        },
    },
}

上述配置的含义是将编译后的 assets 文件夹下的所有文件上传到 S3 服务器的 gblog 文件夹下，这通常需要配合修改 astro.config.mjs 文件如下：

// astro.config.mjs
export default defineConfig({
    build: {
        assets: 'assets',
        assetsPrefix: 'https://images.godruoyi.com/gblog',
    },
})

即通过 build 配置告诉 astro 在编译时将资源文件全部打包到 assets 文件夹下，编译完成后会程序自动调用 astro-uploader 将这些文件上传到 S3；所以我们还需要告诉 Astro 使用 S3 的路径如 https://images.godruoyi.com/gblog 作为前缀。

注意你可能还需要到对应的部署平台设置相应的环境变量。

如何添加新功能

博客的 UI 使用的是 Preline UI，你可以从它们的 Example 或者 Template 中 copy 你想要的样式文件并直接粘贴到 gblog 中，这通常不需要做过多的修改就能 clone 你看到的效果。

参考

没人抬

Fri, 09 Aug 2024 13:54:00 GMT

乡里人怕的，是自己死了后，找不到人抬，我不明白。

在电话里跟人吵了起来，说我不懂人情事故，自己家亲叔叔泡学酒都不来。而所谓学酒，无非就是自家的孩子考上了大学，请上两桌聊表庆祝，再收回这两年送出去的人亲钱，这在乡里十分常见。

一大早，他们懂人情世故的人，就驱车两三个小时前往市里去吃酒了，我没去，我要上班。

乡里人有个规矩，无论周围哪家办酒，亲戚还是邻居，还是上个寨子的人。在外面的人都要回来；即使家里人父母健在，远在他乡的人都要赶回来；有从上海回来的，有从贵阳回来的，开十几个小时的车，再请上三五天假，以表示对这家人的尊重，特别是如果他们家有个儿子的话。

而那些选择不回来的人，乡里人对他们是不满的，这些不满往往会在他们办酒时体现出来，如找不到人来帮忙；乡里人是没有丧事喜事一条龙服务的，靠的只是邻里邻居相互帮忙。若恰巧他们办的是丧事，那出殡时怕是找不到人抬的，乡里人就站在边上，也不接散的烟，睥睨着一切。

你现在傲气，到时候有你求人的那天。

我不知道如何回复电话那头这样的质问，我也不明白所谓的人情世故到底是什么，我只是更愿意过好自己的生活。

关于乡里人的风土人情，你可以看看我之前的老家的变化，而乡里人对办酒的热爱，从办酒可见一般。

什么是发件箱模式

Sun, 04 Aug 2024 15:43:00 GMT

早上在群里看到有同事在问关于 Outbox Pattern 的问题，而在此之前我对此一无所知，我甚至还错误的发了一些毫不相干的回复，那就姑且把 Outbox Pattern 当作今天 TIL 的对象吧，下面是本次学习的记录。

什么情况下引入的 Outbox Pattern?

当需要同时插入数据到数据库并且还要发送消息到消息队列时，传统操作无法保证这两个操作都完成；举个例子：

db.Transact(func(tx *sqlx.Tx) {
    mq.PublishOrderCreatedEventToKafka(data)
    db.InsertOrderToDB(data)
})

发布到 Kafka 成功但是数据保存失败，整个事务回滚；但已经发布到 Kafka 的消息无法简单的回滚，导致消费者收到了本不该存在的数据。
保存数据成功但发布消息失败，整个事务提交，数据已保存到 DB 中；但由于没有发布到 Kafka，消费者丢失了本次更新。

即对外部服务的调用没法随着本地事务一起提交一起回滚，导致数据的完整性出了问题；那有没有什么办法可以将这两个操作放到同一个本地事务中，并利用事务的 ACID 来保证数据的完整性呢？

这就引入了 Outbox Pattern。

什么是 Outbox Pattern？

我们知道大多数数据库都能保证两条 SQL 操作要么全都成功，要么全都失败，参见为什么我们需要数据库事务；如果我们能将「发送消息到队列」这一操作转化为 —— 插入一条数据到数据库；我们就能利用数据库的特性来保证数据的完整性，然后再利用额外的程序来异步读取数据并发送到 Kafka。

db.Transact(func(tx *sqlx.Tx) {
    db.InsertOutboxTable(data)
    db.InsertOrderToDB(data)
})

图片来自于 Outbox Pattern Example

这样做有什么好处？

通过同一个本地事务来保证数据的完整性，即这两个操作要么全都成功，要么全都失败
不需要依赖 MQ 组件
业务方只需要关注如何操作数据
更可靠；一旦事务提交，异步程序会通过多种方式(如重试)保证数据正确的投递到 MQ，不会因为短时间的 Kafka 断开连接而投递失败

这样做有什么弊端？

引入了额外的程序；需要单独的程序&进程异步读取数据并发送到 MQ
更高的延迟；之前是直接将数据投递到 MQ，现在需要先插入数据到 DB，再由异步程序读取 DB 的数据，最后再投递到 MQ

我们可以设计一个通用的表结构来保存消息实体，它应该是和业务无关的，如：

CREATE TABLE reference_outbox.outbox (
    id integer NOT NULL,
    event_name character varying(256) NOT NULL,
    event_type character varying(256),
    event_key character varying(1024) NOT NULL,
    event_payload bytea NOT NULL,
    event_timestamp bigint DEFAULT (date_part('epoch'::text, now()) * (1000)::double precision) NOT NULL,
    headers text,
    target_kafka_topic character varying(256) NOT NULL
);

为什么不将数据都发送到 Kafka?

那为什么我们要将两条数据都插入到数据库而不是将他们都投递到 Kafka 呢？即应用程序只需要将消息投递到 Kafka 然后再由单独的消费者来处理它们，这样也能保证「发送消息到队列」和「插入到数据库」这两个操作的完整性。

mq.PublishOrderCreatedEventToKafka(data) // 生产者
 
mq.pull(kafka-topic, func (e *Event) { // 消费者
    db.Transact(func(tx *sqlx.Tx) {
        db.InsertOrderToDB(e)
    })
})

因为这样违背了一个原则：Read-Your-Wrirte。假设消费者在处理这个消息时延迟了 5 秒钟，那意味着你通过 APP 下的订单需要 5 秒后才能查看它们，这对于用户来说是不可接受的。

如何实现 Outbox Pattern

Outbox Pattern 的难点在于如何设计一个程序，可以异步的读取数据并发送到 MQ。它应该支持：

不会意外停止服务，即使停止服务重启后也能继续投递数据到 MQ，不会造成丢失数据
支持失败重试
侵入性小
低延时

目前关于 Outbox Pattern 的实现中采用最多的可能是开源的 Debezium 方案，它支持捕获数据库的任何变更并将它们发送到 MQ 平台；支持监控数据库中行级别(row-level)的更改，并且只关注已提交的事务；也支持本地持久化，即就算 Debezium 异常停止服务，重启后也能保证所有的事件都能被正确的处理。

PostgreSQL Connector

Debezium 为不同的数据库都提供了不同的 Connector，以 PostgreSQL Connector 为例，它基于 WAL 日志变更的方式来捕获 Outbox 表中的新记录并将它们投递到 Apache Kafka 中。与任何基于轮询的方法相比，基于日志的事件捕获几乎是实时的，并且开销也很低。

不过由于 PostgreSQL 的 WAL 可能隔一段时间就被清理，这导致 Debezium 没法获取数据库的所有变更历史，所以 PostgreSQL Connector 在第一次启动的时候会尝试对数据库做一次快照，后续将基于这个快照来同步数据到 Kafka，参见 Debezium connector for PostgreSQL。

如何配置 Connector 以捕获数据变更？

我们可以参考这里的例子通过 Docker 启动一个 Connector，启动成功后 Connector 会对外暴露一个 REST API，可以通过向这个 API POST 一些配置告诉 Connector 应该如何处理数据库变更。

$ docker run -it --rm --name connect -p 8083:8083 
-e GROUP_ID=1 
-e CONFIG_STORAGE_TOPIC=my_connect_configs 
-e OFFSET_STORAGE_TOPIC=my_connect_offsets 
-e STATUS_STORAGE_TOPIC=my_connect_statuses 
--link kafka:kafka 
--link mysql:mysql 
quay.io/debezium/connect:2.7

下面的这个示例来自官网教程的一个 PostgreSQL 样例配置，其中指定了数据库的账号密码以及捕获哪个表的数据变更等，你可以从这个表格查看每个字段对应的具体含义。

{
  "name": "fulfillment-connector",  
  "config": {
    "connector.class": "io.debezium.connector.postgresql.PostgresConnector", 
    "database.hostname": "192.168.99.100", 
    "database.port": "5432", 
    "database.user": "postgres", 
    "database.password": "postgres", 
    "database.dbname" : "postgres", 
    "topic.prefix": "fulfillment", 
    "table.include.list": "public.inventory" // 监控的数据表
  }
}

我们甚至可以为 Connector 配置删除策略以忽略 Outbox 的删除操作，如下：

{
  "name": "fulfillment-connector",  
  "config": {
    "table.include.list": "public.outbox_table", // 监控的数据表
    "tombstones.on.delete": false
  }
}

将 tombstones.on.delete 设置为 false 后 Connector 会忽略对 public.outbox_table 表的删除操作，我们可以将应用程序的业务代码修改为如下形式：

db.Transact(func(tx *sqlx.Tx) {
    id := db.InsertOutboxTable(data)
    db.DeleteOutboxTable(id)
 
    db.InsertOrderToDB(data)
})

这样做有一个好处就是可以保证 outbox 数据表的大小不会太大，并且即使我们在新增后马上就删除了 outbox 的记录，也不会影响 Connector 将新增的消息数据投递到 Kafka。

总结

Outbox Pattern 将对外部服务的调用转为对两个本地事务内的操作，然后通过本地事务特性来保证数据数据的完整性
Outbox Pattern 的难点在于设计一个程序异步低延迟的读取数据的变化并将它们投递到 MQ，好在我们有现成的解决方案
Debezium 的配置很复杂
今天就学到这儿了

参考

老爸的日记

Fri, 26 Jul 2024 16:00:00 GMT

2021 年老爸老妈第二次前往上海打工，一去就被关在赵屯两个多月，期间只能吃救济，菜只能依赖周边农户。每到晚上，人们拿着肥料口袋去田里偷蚕豆。

上一年老爸老妈挣了 6 万块钱，这一年老爸几个月倒用 5 千。下面是老爸的记录，无奈中带着几分风趣。

2 月 30 号从老家到上海，3 月 1 号到赵屯。

5 月 21 号从赵屯到务川，22 号到达务川；务川隔离 7 天，回家隔离 7 天；每天生活费 60 元。有两个月 20 天没上班。

今年就是这个情况，完了阿。

美国

Fri, 05 Jul 2024 16:16:00 GMT

昨天晚上开了一个小时的会，受益良多；以下只是我的感悟，请不要信以为真。

这周娃一直咳嗽，我几乎什么更新都没有，所以在前十分钟聊完项目后，我们仨开始了闲谈。

J 是我们的老板，当我在闲聊中问到美区公司有没有招中国人然后全职 Remote 时，他默默的摇了头。他给我们说美国现在的程序员只要从大厂离职，也很难找到工作；各个大厂也都在裁员，加上 AI 的崛起，之前 5 个人能干的事，现在只要 3 个人就够了。

我觉得 AI 的崛起和找工作难甚至公司的裁员计划应该没有太大的关系；工具会让强能力者更好的适应这个社会，而不会使用工具的人，注定会被淘汰。

然后他给我们讲了半个小时左右的 AI，给我们讲了自然语言识别，讲了 Google 的 TensorFlow 框架，讲了模型是如何运转的，还有很多算法。说实话这部分我基本没听懂，我对 AI 的理解还停留在如何调用 API 上。在看他来，未来是 AI 的。想要自己有更好的竞争力，现在就应该动手学点 AI 相关的技术，比如吴恩达的斯坦福课程就是一个不错的入门课程。

然后他语重心长的建议我们，一旦有机会一定要出去，不要待在中国。国内的环境在他看来比较严峻。当房地产不能拉动经济，地方政府又有很大的债务危机时，很有可能未来几年政府会开始印钱，而印钱就可能会导致通货膨胀，加上就业压力大，以后老百姓的日子可能不会好过。

在他看来，生活在国内的人都挺不容易的。买一个 200 万的房子，前前后后一共要花费近 300 万，还要还款 30 年；买个奥迪要 200 万。按照普通程序员一年年薪 20 万算，我们得不吃不喝 10 年才买得起一款奥迪；然而在国内卖 200 万的奥迪在美国甚至别的任何国家，都只需要 5 万刀左右，这折合人民币只有 40 万左右。

关于这点我下来自己搜了下，参考中国汽车流通协会的这篇文章；如果进口汽车排量大于 4.0L，那取除了收取常规 25% 的关税，17% 的增值税，还要承担 40% 的消费税。按照这个方式计算的话，一辆 5 万美元的进口汽车在国内的报价大约是 63 万人名币。

还有一个点我觉得他说的非常有理，那就是发达国家对知识产权的保护。在那里，即使是一位非常普通的员工做出的比较新颖的东西，公司也会花费几百万美元来帮助他申请知识产权；并且公司自老板开始，都会将资源倾斜给这位员工。我猜这也是为什么这么多年来硅谷依然能成为全世界顶尖科技的源头的原因。因为在这里能培养出大量的人才。他们没有任何后顾之忧，公司帮他们解决了几乎一切的生活问题，他们要做的就是全身心的投入自己想做的事业，并开创一个新未来。

这里我又想起了几年前写下的一段话：1981 年的乔布斯，开着保时捷，Macintosh 团队年薪较低的工程师 22000 美元。

而想想你在国内公司上班搞个开源还被辞退、拿着月薪 5000 的工资却还想做为人类的伟大胜利而奋斗终身、好不容易实现的 idea 却被别人无情的抄袭。在这样的土地上，又怎么能长出参天大树呢。

Lambda Connect RDS

Tue, 21 May 2024 17:47:00 GMT

这份文章解释了如何通过 Lambda 连接 AWS RDS 数据库以及 SecretManager 和 DynamoDB。

Background

我们计划为项目引入关系型数据库支持，进过调研后我们选择了 AWS 的 PostgreSQL。而 PostgreSQL 数据库实例是运行在一个私有网络(VPC)内的，只有在同一个私有网络中的服务才能相互连接。

而在默认情况下，部署到 AWS 的 Lambda 运行在自己的另一套私有网络内，Lambda 的这个私有网络我们没法控制也不能自定义，就没法实现 Lambda 和 RDS 的互通。

现在我们的目的是把它们都放在同一个VPC 下，并且要支持：

Lambda 访问 RDS
Lambda 可以访问 SecretManager
Lambda 可以访问 DynamoDB

VPC

所有云厂商都提供了 VPC 的配置，这属于网络的基石部分。默认情况下，AWS 会自动为我们创建一条的 VPC，不同的 VPC 默认情况下不能互通网络；请不要使用默认的 VPC 来部署你的应用，这可能因为一些缺失的配置导致你后面不得不花费更多的时间来 debug。

Create VPC

可以按照 AWS 控制台的引导快速的创建一条 VPC，不过有几个点还是需要注意的：

我们的 VPC 需要访问外网(SecretManager & DynamoDB)
我们的 VPC 网络下会包含各种云资源(RDS)及 Lambda

所以我们应该至少在这个 VPC 下创建两个子网：

所有的云资源如数据库、EC2 等放到子网 1
Lambda 运行在子网 2 下
子网2 需要能访问外网，因为 SecretManager 和 DynamoDB 的服务是通过 Internet 公开访问的

这里涉及到了几个新的概念：VPC、子网、路由表。

子网

一个 VPC 可以包含多个子网，可以理解为 VPC 管理了某一个网络下的所有服务资源，而子网管理了某一个网段下的所有资源。

举个例子，我们在创建 VPC 时会指定 IPV4 CIDR Block 如 192.168.0.0/16 这代表这个 VPC 下的所有服务资源它们的 IP 最后都会是 192.168.x.x。

而子网则是更加具体的管理了某一个网段下的资源，如子网 1 的 IPv4 CIDR 为 192.168.0.0/20 它代表部署在这个子网下的所有服务，他们的 IP 范围应该为 192.168.0.0 → 192.168.15.255 。

因为这个特性所以子网能更加具体的控制某一个网段下的流量访问规则。

路由表

在创建子网时默认会创建这个子网相应的路由表，路由表定义了在这个子网中流量的流出流入规则。举个例子，下面的路由表里包含了两条默认的规则：

0.0.0.0/0               igw-123456789
192.168.0.0/16          local

它代表部署在这个子网中的服务，访问目标地址时的流量流出规则。假设我们将一个 EC2 实例部署到了这个子网：

当在 EC2 中 Ping 192.168.x.x 时，EC2 会将请求转发到所在子网的路由表，路由表会匹配上面的第二条规则，将流量转发到 Local，Local 会在整个 VPC 范围下广播，最终实现局域网内的通信。
当在 EC2 中访问如 GitHub 等公网服务时，由于 GitHub 的 IP 地址只满足上述的第一条规则，所以在 EC2 中访问 GitHub 会将流量转发到 igw 网关。

这里的 igw-123456789 是一个网关，它的全名叫 Internet Gateway 。

如果你的服务只需要在局域网中通信，即不需要访问外网，也不需要外网访问它们；你可以删除上面的 0.0.0.0 这条规则。

Internet Gateway

VPC 下的服务默认情况是不能直接访问公共网络的，如果要访问公共网络，我们需要创建一个 Internet Gateway。Internet Gateway 允许与 Internet 之间的双向通信。换句话说，它将来自 VPC 的数据包通过 IGW 转发到 Internet，并将来自 Internet 的请求路由回 VPC，如 WEB 服务器。

假设我们的网络拓扑图如下，因为有了 IGW 的加持，理想情况下 Lambda 就可以访问外网 + 连接 RDS 数据库了：

VPC
  - sunnet1(lambda) -> route table1  -> 0.0.0.0/0       -> igw
                           ^         -> 192.168.0.0/16  -> local
                           |
  - subnet2(rds)    -------/

Lambda 被部署到了 subnet1，它访问 RDS 时，流量会经过 Route Table 1 然后通过 Local 最后转发到部署在 subnet2 中的 RDS 上，这确实是可行的 ✅。

Lambda Connect RDS -> Route Table1 -> 192.168.0.0/16 ---> Local
                                                            |
                                                            |
                                    RDS <- subnet2(rds) <---/

Lambda 访问外网时流量会经过 Route Table1 然后转发到 IGW 网关最后由 IGW 转发到外部服务中去。

Lambda Connect GitHub -> Route Table1 -> 0.0.0.0/0 ---> IGW -> Internet

然而这实际上是行不通的，要想通过 IGW 访问外网，部署到该子网的服务必须有一个公网 IP。如 EC2 实例要想通过 IGW 访问外网，那该 EC2 实例必须得有一个公网 IP。

默认我们部署在 VPC 环境下的 Lambda 并没有一个公网 IP，所以按照上述方式，Lambda 并不能直接访问外部网络。我们还需要引入一个单独的配置—— NAT。

NAT

NAT，全称为 Network Address Translation，即网络地址转换。它的主要作用是帮助局域网（LAN）上的私有地址与 Internet 或其他网络上的公有地址进行转换，使得私有地址可以通过 NAT 直接访问外部网络。

NAT 与 IGW 的区别：

NAT 是单向的，流量只能从 NAT → 外部网络，外部网络无法访问 NAT 里面的资源。所以如果一些服务只需要访问外网但不允许外网访问内部网络，就可以使用 NAT。
IGW 是双工的，可以从 IGW → 外部网络，也可以从外部网络到 → NAT。比如 WEB 服务器，即需要服务器能返回 Response 给用户，也需要用户能直接请求服务器上的资源。

有了 NAT 后，我们的网络拓扑图如下。

VPC
  - sunnet1(lambda) -> route table1  -> 0.0.0.0/0       -> nat
                                     -> 192.168.0.0/16  -> local
                           
  - subnet2(rds)    -> route table2  -> 0.0.0.0/0       -> igw
                                     -> 192.168.0.0/16  -> local

Lambda 被部署在 subnet1 子网，当它在 Connect RDS 时，会通过上面的 route table1 -> 192.168.0.0/16 -> local -> subnet2 -> RDS 访问到 RDS 服务。
Lambda 访问外网时，会通过 route table1 -> 0.0.0.0/0 -> nat 然后经过 NAT 转发出去。

为了使每个子网的职责更加分明，我们重新设计了它们的网络结构：

VPC
  - subnet1(lambda) -> route table1  -> 0.0.0.0/0       -> nat
                           ^         -> 192.168.0.0/16  -> local
                           |
  - subnet2(rds)    -------/
    
                                     
  - subnet3(igw)    -> route table2  -> 0.0.0.0/0       -> igw
                                     -> 192.168.0.0/16  -> local

这里单独创建了一个 IGW 子网(subnet3(igw))，它将所有的外部流量转发到 IGW；而其他所有的子网都进过 route table 1 将外部流量转发到 NAT。

举个例子，在上面的网络结构中，如果 Lambda 想要连接 GitHub，那他的流量流向为：

Lambda Connect GitHub -> Route Table1 -> 0.0.0.0/0    --->    NAT
                                                               |
                                                               |
GitHub <- igw <- 0.0.0.0/0 <- Route Table2 <- subnet3(igw) <---/

有了上述的背景知识，我们再来看如何在 AWS 中创建一个 VPC。

Create VPC On AWS

前往 AWS VPC 控制台点击 Create VPC
选择 VPC and More
指定 IPv4 CIDR，可以用默认的 10.0.0.0/16
设置 Number of Availability Zones，为了高可用&简单这里我们设置两个可用区
设置 Number of public subnets，这里设置为 2 个
1. 这里你可能有疑问什么是 Public Subnet，其实就是子网路由表中 0.0.0.0/0 是不是指向的 IGW，如果是，就是 Public Subnet，如下面的 subnet3(igw)
```
VPC
  - subnet3(igw)    -> route table2  -> 0.0.0.0/0       -> igw
                                     -> 192.168.0.0/16  -> local
```
Number of private subnets 这里设置为 2 个
NAT gateways ($) 设置为 In 1 AX
1. NAT 是需要单独收费的，如果选择 1 per AZ 那每个可用区都会设置一个 NAT，对于我们的项目来说一个就够了。
VPC endpoints 选择 None

最后生成的网络结构如下：

这里有两个 Public Subnet 经过路由表 project-rbt-public 将流量流向了 project-igw，剩下两个 Private Subnet 各自有一个路由表，最后都将流量流向 project-nat。

我们重命名并删除不必要的路由表后：

每个可用区都包含一个 Public Subnet 和两个 Private Subnet
两个可用区的所有 Public Subnet 会将外部流量通过 kmind-igw-routetable 转发到 IGW 网关
两个可用区的所有 Private Subnet 会将外部流量通过 kmind-NAT-routetable 转发到 NAT 网关。

以上是我们的基础网络配置，在配置 AWS 服务时，我们只需要把有外网访问需求的服务部署在 private 子网即可。

注意 NAT 的配置，NAT 必须要 Attach 一个 Public 类型的子网才能使得可以从 NAT 访问外部网络，注意看下面的时序图。NAT 访问外部网络的流量最终是从 IWG 网关发出去的。

Lambda Connect GitHub -> Route Table1 -> 0.0.0.0/0    --->    NAT
                                                               |
                                                               |
GitHub <- igw <- 0.0.0.0/0 <- Route Table2 <- subnet3(igw) <---/

RDS

RDS 的创建没有太多的注意事项，只需要按照提示一步一步创建就好了。唯一需要注意的是在创建时要选择刚刚创建好的 VPC。

创建好的 RDS 数据库默认情况下是不能直接通过账号密码访问的，因为 PostgreSQL 16 开启了严格模式，在连接数据库时必须要通过 SSL 形式。即除了指定正确的账号密码外，还需要设置正确的证书。

在测试阶段如果不想这么麻烦，可以通过在 Parameter groups 里创建一个自定义的参数组来覆盖它，具体流程为：

前往 Parameter groups 创建一个新的参数组
在创建好的参数组中将 rds_force_ssl 改为 0
修改数据库，将 DB Parameter Group 改为刚刚创建的参数组。
重启数据库

Lambda

Lambda 默认情况下并不会部署到 VPC 中，我们需要修改 Lambda 的定义，使它能正常部署到上面创建的 VPC 中。

以 CreateNoteCommandLambda 为例，其配置为：

  CreateNoteCommandLambda:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: CreateNoteCommandLambda
      CodeUri: course_deploy.jar
      Handler: com.x.CourseServiceHandler::handleRequest
      Policies:
        # 指定 VPC 策略
        - VPCAccessPolicy: {}
      # VPC 配置
      VpcConfig:
        SecurityGroupIds:
          - sg-12345
        SubnetIds:
          - subnet-12345 # kmind-private1-nat-east-1a
          - subnet-23456 # kmind-private1-nat-east-1b
      Events:
        ApiEvents:
          Type: Api
          Properties:
            RestApiId: !Ref ApiGatewayApi
            Path: /notes
            Method: POST
            Auth:
              Authorizer: NONE

新增的配置为：

指定 VPCAccessPolicy 因为 Lambda 需要能访问 VPC
配置 Lambda SubnetVPC
1. 配置 Lambda 函数的 SecurityGroup，这我在后面说明
2. 配置 Lambda 函数部署的子网，为了满足跨分区可用，这里指定了不同区域的两个子网。
3. 注意这里配置的子网应该是上面 VPC 网络设置中的 Private 子网(kmind-private*)。

Security Group

Security Group 是 AWS 的一种安全机制，用于控制进出的网络流量。你可以将 Security Group 想象成由规则组成的虚拟防火墙。我们的目的是想 Lambda 访问 RDS，所以我们需要配置 Lambda Security Group 的 Outbound rules，如：

Security group ID     Protocol  Ports  Destination 
sg-0467b06b178edb777  All       All    0.0.0.0/0

这代表从 Lambda 访问任意目标地址都是允许的。我们还需要配置 RDS Security Group 的 Inbound rules 使得他能允许来自 Lambda 的请求，如：

Security group ID      Protocol      Ports   Source
sg-0467b06b178edb777   Custom TCP    5432    0.0.0.0/0 
sg-0467b06b178edb777   AlL           All     sg-0467b06b178edb777

到此我们的所有配置就已经结束了，当 Lambda 部署成功后，它应该能同时访问 RDS + 外部网络。

Blog 的延续

Thu, 16 May 2024 13:06:49 GMT

最近花了一些时间将我的博客迁移到了 Astro 平台，我感觉整个过程挺美妙的，很喜欢 Astro。

博客迁移的初衷是因为我的主机被腾讯云封禁了。因为域名到期后未续费导致被解析到一个有辱国家斯文的网站，我的主机被永久封禁不得申诉。于是我将自己的博客迁移到了 Fly 平台上，而 Fly 每个月 6/7 刀的费用又让我不堪重负。

我在 2015-12-25 注册了自己的第一个域名，并一直用到了现在，我已经忘记当时部署的是什么网站，隐约记得写了个 LOVE 阿宝 FOREVER。以前觉得互联网上的东西都能保存十年百年，而现在 9 年不到我之前写的任何内容已经了无踪迹。互联网是没有记忆的。大学期间写的几十篇日记还在我的贵人鸟鞋盒里静静地躺着。

想象前两次博客的改版，我从 Symfony 博客迁移到 Laravel 再到 Golang Gin；每一次迁移都会造成数据丢失，每一次迁移都要折腾很久的云环境。从如何安装 PHP、安装 Nginx、安装 Redis、安装 MySQL、安装 Docker、安装 Clash、配置 Acme.sh。我的网站能正常运行完全是因为恰巧这些服务都正常工作。

你能想象两年内它完全是运行在下面这样的脚本中吗？我甚至都没有为他配置 Restart Policies 或者 Supervisor，相当于只要程序一 Panic，网站就挂了。

docker run --name gblog -p 9900:9900 -d ${imageName}

博客应该被静态化，我心里这样想着。静态化的博客可以部署到任何 Serverless 平台中，一个个 HTML 页面就包含了你博客的所有数据，它们不会因为你忘记续费就停止服务，也不会因为你的定时脚本出错了就不能 HTTPS 访问，更不会因为你忘记配置 Clash 就无法使用 GitHub 登录。你所有需要做的，就是提交你的博客内容；Git 记录了你所有的操作历史，只要 GitHub 不倒，你的网站久依旧能地老天荒。

我写博客的初衷是为了多年后能自省当年的自己，看看当时的心态。我比较厌烦流水账的记录，所以更多的时候我愿意写下此刻的感悟；我不明白为什么很多人的年终总结要写一月份干了什么二月份干了什么，十年后的你在回首时真的在乎你某年某月干了什么吗？

截图

按照约定，放几张新版本博客的截图。

2023 年终总结

Fri, 09 Feb 2024 15:10:51 GMT

我在楼上写今年的总结，窗外在下雪。

Life

今年很累，因为有娃了。还记得去年冬天刚抱着娃儿回来时我和阿宝的不知所措，到现在能熟练的掌握娃的一日三餐衣食住行，我俩也算是勉强及格的父母了。可能在老家人看来两个人合伙照顾一个孩子还喊累难免有点儿娇滴滴，他们也总会拿自己当初是如何一个人带大四五个孩子的总总让你自行惭愧，但我还是想说，养娃很累。

在最开始的那一个月里，我们花了 13800 请了个月嫂；这是我觉得今年最有价值的投资。有月嫂在的那 26 天里，我们不用考虑每天吃什么，不在担心娃的吃喝拉撒，还能每晚睡个整觉；即使月嫂烧的饭菜和我有得一拼，即使她照顾娃儿的方式有时我们不太认同，但那段日子我俩真的过得很舒心；阿宝有轻微的抑郁症、焦虑症，我很难想象如果没有那段时间的缓冲，我们的日子会过成怎样。

月嫂走后，生活就变得复杂起来了。为了防止阿宝变得更抑郁，白天我边上班边辅助带娃，阿宝则负责照顾大人孩子的一日三餐。晚上娃和我睡在次卧，我睡眠很好，就算娃再怎么折腾，我也能抽空睡两觉；而阿宝的睡眠就很差了，稍微一点点声响就整宿睡不着；所以算算到现在，我已经和娃单独睡了八九个月了。比起白天工作时总被无限次数的打断，我更愿意晚上带娃，也换来白天的一丝宁静。而当娃开始吃辅食后，这一丝宁静也没有了，我很难有连续超过两个小时的专注时间。我和阿宝的的很大一部分时间都在厨房度过，早饭/午饭/孩子的午饭/晚饭/孩子的晚饭，我们每天都在为吃什么而烦扰，每天都刚收拾完一切准备躺在沙发上喘口气时，孩子又醒了。阿宝现在最讨厌的一句话就是：孩子睡你就睡嘛。仿佛说这句话的人根本不用收拾那摊烂摊子似的。

好在是养娃带来的幸福感和付出的辛苦是成比的。看到她指着你的鼻子呀呀呀的叫着，踉踉跄跄的朝你走来，分享她的食物给你吃时，这一切都是值得的。

Someting

我记得某位推友说过，如果你只是一味的吸取别人的知识，那就算你是在逛 Hacker News，读专业论文，看世界名著，甚至是在读 Linux 源码；那你本质上和那些只知道刷抖音的人来说并没有什么不同。你依然是在向这个社会吸取而不是制造点什么。我觉得人不应该像寄生虫一样活着；我身边有一些很厉害的大佬，他们的技术能力和思维能力一直让我望尘莫及，但很遗憾他们却没有输出一点点能帮助后人达到他们一样高度的东西。我们都会老去，但如果我们留下的东西能帮助到后人成长，那应该很有趣。

所以从今年开始，我开始做一些自己觉得很有趣的小项目；如果这些小项目又恰巧能满足一部分人的需求的话，那我就更开心了。得益于强大的 GPT，我们能非常快速的从零经验上手任意一门语言。在学完 Rustlings 后，我开始给 Xuanwo 的 reqsign 贡献 PR；当初的想法是先混个脸熟然后再打入内部最后被顺利招安，因为我对 Remote/OpenSource 十分感兴趣；现在想起来也是十分滑稽，路肯定是行得通的，只是怪自己没能坚持下来。

接下来我用 Rust 写了我的第一个小项目 Laravel Tips，可以在终端展示各种有趣和生涩的提示；后来在推友的建议下我又写了一个 Laravel Tips Raycast 扩展；Bing Dalle-2/3 出来后，我又基于 yihong 大哥的 tg_bing_dalle写了一个起床机器人 Wakeup；而最近我正在写一个浏览器扩展 Readog，它可以将你的链接保存到任何平台。我很享受整个过程，很多时候都是当孩子睡着后我就迫不及待的冲到电脑旁敲下在脑子里过了很多遍的最佳实践。我觉得对于工程师来说，将自己的想法一步步实现出来，不限语言，不限技术，这本身就是一件十分美妙的事情。

Action

如果你吃到一颗好吃的鸡蛋，你会去寻找下单的母鸡吗？

我把钱钟书说的这句话又搬出来了，放到现在依然适用，找不找得到母鸡我不知道，但只要行动起来，收获肯定还是有的。我经常会在推上看到一些有趣的信息，如远程工作的招聘、开发工具、开源项目等；大部分推友都只会点个赞，亦或加个收藏，而真正开始行动起来的人少之又少。比如你一直想找一个远程工作的机会，现在机会都摆在面前了你却不愿意试着去改变，只是加了个收藏想着以后离职了再去尝试；比如你看到一个很不错的开源项目，你只是点个 star，少有的会去深度了解下它的背景和具体解决的什么问题，而读它的源码了解它优秀的设计的人就更少之又少了。

我一直觉得机会是留给行动起来的人的，站在岸上学不会游泳。我并不是一个行动派，就拿每次推着孩子出去因为路口被私家车挡着的事儿来说，我每次都是嘴上骂两句，即使心里想过很多遍市长信箱投诉，交通执法大队举报，却每次都没有实际行动起来。我希望来年我能行动起来，如果某一个市政的改善有你的功劳，那未尝不是一件有趣的事儿呢。

就写到这吧，春晚太吵了。

往年总结

办酒

Wed, 31 Jan 2024 08:15:49 GMT

许老三今天吃了五家人户的酒，送出去了八百块钱。

许老三早上九点就出门了，出门前他翻了翻两年前办酒的礼簿，在第二页找到了刘大姐家送的 100 元记录，他打算两还送她 100 块。毕竟只是满个 50 岁，又不是啥大酒，而这一百块可是要一天工钱呢。

许老三远远的看见刘大姐家门前稀稀捞捞的站着几个人，他不知道往哪里送钱。现在政府查的严，只有红白喜事和年满八十才能办酒，所以收钱的地方往往比较偏僻，也避免被政府抓到后没收，那样就违背了办酒的初衷赚不到钱了。许老三送完了钱，看到自己的名字记到礼薄上后，接过一支烟就走了，他还不打算吃饭，后面还有几家没送呢。

许老三走到了李家，这里要热闹些，马路上停满了车。李家老头儿满 60，他家的儿子特意回来给他办酒庆祝。许老三决定在这家吃饭，这里多半是要好吃一点的。许老三年纪较大，坐在「上席」的位置，菜已经上了两个；有煎的干洋芋片，还有凉拌海带丝；许老三看到凉拌海带里面还有豆豉和折耳根，很是欢喜。于是他转过头喊了一声：添饭；一个小伙端着一盆热气腾腾的饭走了过来，舀了一瓢到许老三的碗里。许老三吃了两碗饭后，菜终于上齐了；压轴的是一碗扣肉，然后是海椒酱炒肉，还有酸海椒炒肥肠丝，还有油炸豆腐，一共十二个菜，摆成一个正方形在桌子上。许老三敛了一件全肥的扣肉，一口就吃了，用手抹了抹嘴，下席了。他还要往周家坪走去；他走的时候回头看了一眼这家人两层楼高的小洋房，在周围的木房子中显得格外洋气，只是办的酒菜却和大家一摸一样。

周家坪这家是房子酒，她们家的儿子在市里买了房子，老两口决定在老家也办个酒，收回点儿这两年来送出去的人亲钱。周老太是个精明人，他花了不到 2000 块钱酒把酒席办下来了；猪是自家现杀的、菜是自家种的，只需要买点烟酒饮料，弄个十来桌的菜，三四万块钱就送来了。许老三刚把钱送完，就看到十几个人成群结队的来了，其中还有穿警服的。许老三心想，糟了，政府的人来了。政府的人走到了门口，带头儿的一脚踢开了大门，剩下的人像抓逃犯一样快速涌入不同的房间；还在吃饭的人被统统追了出来，几口锑锅被端到了大门口，里面装着这次办酒的菜。带头儿的一边对自己人喊「端完了没，还有没得，取证了吗？」一边大声的对着周老太等人说：「政府明确规定了不准办酒，我们也一而再再而三的通知你们，你们就是不听，再有这样，我们就不是端两个菜这么简单了」。

政府一行人就这样端着四五口锅离开了，突然人群中传来一个声音：菜你们可以端走，锅必须给我留下。喊话的钟大姐和几个中年妇女跑着追了出去，势必要要回自己的锅。许老三没有追出去看，他还要去送钱呢。

许老三送完了所有的钱，突然想到孙女的小仓鼠，它们有时候会被放进跑轮里，只要在轮子前面放一点食物，老鼠就会开始跑起来；不想动的老鼠只能跟着一起跑，不然就会被摔得鼻青脸肿，而跑步的老鼠越多，轮子转得越快，越不容易停。最后所有的老鼠都被摔得稀耙烂才停下来，谁都没有吃到食物。许老三心想，办酒就是那挂在轮子前的食物，而我们都是老鼠。

许老三的儿子在城里上班，每次到了下班时间他们都你望我我望你的不敢走，常常熬到晚上 10 点才回来。许老三觉得他的儿子也是只老鼠。

为什么 Laravel 这么优秀

Wed, 24 Jan 2024 04:45:05 GMT

Laravel 一直是我心中最优雅的后端框架，为了向更多的人解释为什么 Laravel 这么优雅？框架本身都做了什么操作？比起其他框架的优势在哪里等？我准备从一个后端最常用的 CURD 例子说起，一步一步阐述这过程中 Laravel 都是怎么完成的；以及大家(我)为什么喜欢用 Laravel。

Introduction Laravel

Laravel 的定位是一个全栈 WEB 框架，它提供了 WEB 开发的全套组件；如路由、中间件、MVC、ORM、Testing 等。这篇文章中我使用的 Demo 是最新版的 Laravel 10.x 以及 PHP 8.2。虽说从 Laravel 5.x 后 Laravel 的版本变化比较快，基本一年一个大版本，但它的核心几乎从 4.X 以来没有发生过特别大的变化。Laravel 的目录结构可能对第一次接触的人来说会很繁琐，它有十来个文件夹，但其实大部分文件夹的位置都是精心设计的，都待在应该待的位置上。

Laravel Artisan

Laravel 第一个优雅的设计就是给开发者暴露了一个 ALLINONE 的入口 ———Artisan。Artisan 是一个 SHELL 脚本，是通过命令行操作 Laravel 的唯一入口。所有和 Laravel 的交互包括操作队列，数据库迁移，生成模版文件等；你都可以通过这个脚本来完成，这也是官方推荐的最佳实践之一。如你可以通过：

php artisan serv 启动本地开发环境
php artisan tinker Local Playground
php artisan migrate 执行数据库迁移等

和其他框架类似，Ruby on Rails 为我们提供了 rails、Django 为我们提供了 manage.py。我觉得优秀的框架都会提供一系列的 Dev Tools 帮助开发者更好的驾驭它，更优秀的框架如 Spring 除外。

接下来我们将尝试构建一个简易的课程系统，在这个系统中有教师(Teacher)，学生(Student)和课程(Course)，它们之间覆盖了简单的一对一、一对多、多对多等的关系，这在日常开发中也很常见。

我会按照我理解的最佳实践的做法，一步步实现一个完整的 CURD；但不会一来就把 Laravel 的各个优秀组件抛出来，而是遇到什么组件后再尝试理解它为什么要这样设计、比起其他框架的优势在哪里。这篇文章不会包含所有的代码，但你仍然可以通过这个仓库 godruoyi/laravel-best-practice 的提交记录看到我是如何一一步构建起来的。

Make Model

我们的第一步是根据 Laravel 提供的 Artisan 命令生成对应的 Model；在实际的开发中我们通常会提供额外的参数以便生成模型的时候一起生成额外的模版文件，如数据库迁移文件、测试文件、Controller 等等；我们还将用 make:model 为 Course 生成一个 CURD Controller，相关的几个 commit 我列在下面了，每个 Commit 我都尽量做到了最小：

当模型及模型之间的关系定义完成后，在我看来整个开发任务就已经完成 50% 了。因为我们已经完成了数据表中字段的定义、表与表的关系、以及最重要的一步：如何将数据及数据之间的关系写入数据库中，下面简单的来介绍下在 Laravel 是如何完成的。

Database Migration

Laravel 的 Migration 提供了一套便捷的 API 方便我们完成绝大多数数据库及表字段的定义。Migration 的定义完整的保留了整个应用的所有迁移历史。通过这些文件我们可以在任何一个新的地方快速的重建我们的数据库设计。所有数据库的变更都通过 migration 的方式来完成也是 Laravel 推荐的最佳实践之一。

Laravel Migration 还提供了 Rollback 机制，既可以 rollback 最近的一次数据库变更。不过我不建议大家在生产环境这样做；生产环境的数据库迁移应该始终保持向前滚动，而不应该含有向后 Rollback 的操作。比如你在上一次变更操作中错误的设置了某个表的索引，那我理解的正确的做法不是回滚，而是创建一个新的迁移文件，并在新的迁移文件中 ALTER 之前的修改。

一个现代化的框架，应该有 Migration，下面是 Course 及中间表的定义：

Schema::create('courses', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->string('description')->nullable();
    $table->unsignedBigInteger('teacher_id')->index();
    $table->text('content')->nullable();
    $table->timestamps();
});
 
// create pivot table
Schema::create('course_student', function (Blueprint $table) {
    $table->unsignedBigInteger('course_id')->index();
    $table->unsignedBigInteger('student_id')->index();
    $table->timestamps();
    $table->primary(['course_id', 'student_id']);
});

Model Relationship

Laravel 另一个强大之处在于可以通过 Eloquent 抽象「模型与模型」之间的关系；举个例子，在下面的定义中我们描述了一个 Course 可以有多个 Student、一个 Teacher；以及一个 Student 可能有多个 Course。

// Models/Course.php
public function students(): BelongsToMany
{
    return $this->belongsToMany(Student::class);
}
 
public function teacher(): hasOne
{
    return $this->hasOne(Teacher::class);
}

一旦模型间的关系定义完成，我们就可以非常方便的通过 Laravel Eloquent 查询它们之间的数据关系。Laravel 会自动帮我们处理复杂的 Join 操作，还能在一定条件下帮我们处理如 N+1 问题。来看一个例子：

$course = Course::with('teacher', 'students')->find(1)
 
// assert
expect($course)
    ->id->toBe(1)
    ->students->each->toBeInstanceOf(Student::class) 
    ->teacher->toBeInstanceOf(Teacher::class);

这个例子中我们查询了 ID 为 1 的课程及它所关联的教师及学生；这将产生 3 条 SQL操作，其中还包含了一条跨中间表(course_student)的查询，而这过程中我们不需要做任何操作，Laravel 会自动根据你 model 的定义生成对应的 Join 操作。

select * from "courses" where "id" = 1
 
select * from "teachers" where "teachers"."id" in (5)
 
select 
    "students".*, 
    "course_student"."course_id" as "pivot_course_id", 
    "course_student"."student_id" as "pivot_student_id" 
from "students" 
inner join "course_student" 
on "students"."id" = "course_student"."student_id" 
where "course_student"."course_id" in (1)

How to save data to database

Laravel Factory 提供了一种很好的方式来 Mock 测试数据，一旦我们定义好 Model 的 Factory 规则，我们就能轻松的在开发阶段模拟出一个关系完整的数据。这比起我们手动为前端制造测试数据要方便和可靠得多，如下面的例子将为每一个课程分配一个教师和不确定数量的学生：

// database/seeders/CourseSeeder.php
$students = Student::all();
$teachers = Teacher::all();
 
Course::factory()->count(10)->make()->each(function ($course) use ($students, $teachers) {
    $course->teacher()->associate($teachers->random());
    $course->save();
    $course->students()->attach($students->random(rand(0, 9)));
});

最后我们通过运行 php artisan migrate --seed，Laravel 会自动同步所有的数据库迁移文件并按照 Laravel Factory 定义的规则生成一个关系完备的测试数据。

Laravel Route

在 Laravel 中我们还可以非常方便的管理应用的路由；Laravel 的路由是集中式路由，所有的路由全部写在一两个文件中；Laravel 的 Route 给开发者暴露了一套简单的 API，而通过这些 API 我们就能轻松的注册一个符合行业标准的 RSETful 风格的路由，如我们为我们课程注册的路由：

Route::apiResource('courses', CourseController::class);

Laravel 会自动帮我们注册 5 条路由如下所示，包括用于新增操作的 POST 请求，用于删除的 DELETE 请求等：

Laravel 路由虽然是非常优秀的设计，但它却不是最高效的设计。Laravel 用一个数组保存你注册过的所有路由；在进行路由匹配时，Laravel 会用你当前请求的 pathinfo 来匹配已经注册的所有路由；当你的路由数量超级多时，最坏情况下你需要 O(n) 次才能找出匹配的路由。不过这点复杂度比起注册路由&启动服务的开销几乎可以忽略不计，并且一个应用也不会有数量过多的路由，加之 Laravel 还单独提供了 artisnan route:cache 命令来缓存路由的注册和匹配。我猜这也是为什么 Laravel 不需要实现其他优秀的路由算法如 Radix Tree 的原因吧。

Create Course

接下来我们来看在 Laravel 中是如何优雅的保存数据，这部分的记录你可以参考下面这几个 commit：

我们知道在进行数据操作前，都需要先对数据进行校验。而 Laravel 提供的 FormRequest 就可以非常方便的做到这一点；你可以在 FormRequest 中定义前端传入的每一个字段的验证规则。如是否必须，ID 是否应该在数据库中存在等：

class StoreCourseRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'name' => 'required|string|max:255',
            'description' => 'nullable|string',
            'content' => 'nullable|string',
            'teacher_id' => 'required|exists:teachers,id',
            'students' => 'nullable|array',
            'students.*' => 'sometimes|int|exists:students,id',
        ];
    }
}

如果你尝试传入一些无效的数据，Laravel 会直接帮我们验证并返回错误信息，如下面的 teacher_id 在数据库中并不存在。

$ echo -n '{"name": "hello", "teacher_id": 9999}' | http post http://127.0.0.1:8000/api/courses -b
{
    "errors": {
        "teacher_id": [
            "The selected teacher id is invalid."
        ]
    },
    "message": "The selected teacher id is invalid."
}

得益于 Laravel 强大的的辅助函数和丰富的 API，在下面的代码中我们甚至可以做到一行代码就完成课程的创建及依赖关系的更新。不过这些都属于「茴」字的几种写法，在真实开发中我们应该选择适合团队并且简单易懂的。但我觉得正是这种最求极值的体验让每个用了 Laravel 的人都爱上了它。

// app/Http/Controllers/CourseController.php
public function store(StoreCourseRequest $request)
{
    $course = tap(
        Course::create($request->validated()), 
        fn ($course) => $course->students()->sync($request->students)
    );
 
    return response()->json(compact('course'), 201);
}

Storage Helper

除了上面用到的 tap 辅助函数，Laravel 另一个优秀的地方是为我们提供了超级多的辅助函数；有操作数组的 Arr，操作字符串的 Str，操作集合的 Collection，操作时间的 Carbon 等。

collect(['alice@gmail.com', 'bob@yahoo.com', 'carlos@gmail.com'])
    ->countBy(fn ($email) => Str::of($email)->after('@')->toString())
    ->all(); // ['gmail.com' => 2, 'yahoo.com' => 1]

这里还有一个有趣的现象：在 Laravel 中，辅助函数通常会放在一个名叫 Support 的文件下面的；而这在其他框架中通常会被叫做 utils。在我看来如果单比命名，support 在这里要优雅得多；并且 Laravel 的源代码中到处都充满这这种匠人式的设计；不管是函数的命名、注释、甚至是什么时候该空行，都有着自己的设计思考在里面。在 PSR2 代码规范中，还有专门的 Laravel 格式化风格。

写了这么久的代码，我不知道我写的代码到底够不够好，但好在是能嗅到一点点坏代码的味道了，而这一切都全部得益于 Laravel。

举个例子，你可以随便点开一个框架的源代码文件(如Kernel.php)，看看它的命名，看看它方法的设计。我觉得这些技能在所有语言中都是通用的。

protected function sendRequestThroughRouter($request)
{
    $this->app->instance('request', $request);
 
    Facade::clearResolvedInstance('request');
 
    $this->bootstrap();
 
    return (new Pipeline($this->app))
                ->send($request)
                ->through($this->app->shouldSkipMiddleware() ? [] : $this->middleware)
                ->then($this->dispatchToRouter());
}

Testing

Laravel 为我们提供了另一个优秀的设计就是测试。它为我们提供了种类众多的测试，包括 HTTP 测试、浏览器测试(行为测试)、单元测试、数据库测试等。作为后端开发，测试应该是所有环节中最重要的一部分；我们可以不用为每个函数都编写单元测试，但对于暴露出去的每一个 API，都应该有足够的 Feature 测试来覆盖大部分可能的情况。

在 Laravel 中我们可以非常方便的为每一个 API 编写功能测试，如下面我们为创建课程编写的 HTTP 测试：

uses(RefreshDatabase::class);
 
it('create course fails if the teacher is not exist', function () {
    $course = [
        'name' => 'Laravel',
        'description' => 'The Best Laravel Course',
        'teacher_id' => 1, // teacher not exist
    ];
 
    $this->postJson(route('courses.store'), $course)
        ->assertStatus(422)
        ->assertJsonValidationErrors(['teacher_id']);
});
 
it('create course successfully with 1 students', function () {
    Teacher::factory()->create(['name' => 'Godruoyi']);
    Student::factory()->create(['name' => 'Bob']);
 
    $this->assertDatabaseCount(Teacher::class, 1);
    $this->assertDatabaseCount(Student::class, 1);
 
    $course = [
        'name' => 'Laravel',
        'description' => 'The Best Laravel Course',
        'teacher_id' => 1,
        'students' => [1],
    ];
 
    $this->postJson(route('courses.store'), $course)
        ->assertStatus(201);
 
    expect(Course::find(1))
        ->students->toHaveCount(1)
        ->students->first()->name->toBe('Bob')
        ->teacher->name->toBe('Godruoyi');
});

Update & Select & Delete

接下来我们来看如何在 Laravel 中实现查询/删除/更新操作，这部分的记录你可以参考下面这几个 Commit：

public function index(Request $request)
{
    $courses = Course::when($request->name, fn ($query, $name) => $query->where('name', 'like', "%{$name}%"))
        ->withCount('students')
        ->with('teacher')
        ->paginate($request->per_page ?? 10);
 
    return new CourseCollection($course);
}
 
public function show(Course $course)
{
    return new CourseResource($course->load('teacher', 'students:id,name'));
}

在 Laravel 中可以高效的使用 Eloquent ORM 实现各种查询；如上面的例子中我们使用了 withCount 来查询课程的学生数量、用 with 加载课程对应的教师；还可以指定生成的 SQL 查询只包含某几个字段如 students:id,name。我们还使用了 Laravel Resource 来格式化最终的输出格式，这样做的原因是很多情况下我们不希望直接将数据库的字段暴露出去，你甚至还能在 Laravel Resource 中按不同的角色显示不同的字段，如下面的 secret 字段只有当用户是 admin 时才返回：

public function toArray(Request $request): array
{
    return [
        'id' => $this->id,
        'name' => $this->name,
        'email' => $this->email,
        'secret' => $this->when($request->user()->isAdmin(), 'secret-value'),
        'created_at' => $this->created_at,
        'updated_at' => $this->updated_at,
    ];
}

Abstract API

Laravel 另一个优雅的地方是给开发者提供了很多优秀的组件，如 Cache、Filesystem、Queue、View、Auth、Event、Notifaction 等。这些组件都用一个共通的设计：即开发者只需要面对一套高度抽象的 API 而不用关心具体的实现。举个例子，Laravel Cache Store 的部分 API 定义如下：

interface Store
{
    public function get($key);
    public function put($key, $value, $seconds);
}

在使用 Cache 时，我们基本不用关心到底用的是文件缓存还是 Redis 缓存；在使用队列时也不用关心用的是 sync 队列还是专业的 MQ 如 Kafka。这在日常开发中十分有用，因为你不需要在本地配置各种复杂的服务。你可以在开发阶段在 .env 文件中将你的缓存驱动改为本地磁盘，将你的队列驱动改为本地同步队列；当你完成所有开发后，只需要在 staging/prod 环境修改 .env 的值就可以了，你几乎不需要做什么额外的工作。

Laravel Core - Container

Laravel Container 是整个 Laravel 框架中最核心的部分，所有的一切都是建立在它之上的。

我们知道容器只有两个功能：

装东西(bind)
从容器里取东西(get) 所有用到容器的框架其本质都是在框架启动的时候疯狂的往容器里装东西，容器里面的东西越多，容器提供的功能越大。如 Java 的 Spring 会在编译时为 Sprint Container 填充不同的对象，在使用时就能向容器获取不同的值。Laravel Container 也类似；Laravel 还巧妙的提供了 Service Provider 的方式来往容器里装东西，它的定义如下：

interface ServiceProvider
{
    /**
     * Register any application services.
     */
    public function register(): void
 
    /**
     * Bootstrap any application services.
     */
    public function boot(): void
}

每个 Service Provider 在注册阶段都会向 container 中设置不同的值；如 CacheServiceProvider 会向容器中注册 Cache 对象，后续在使用 Cache::get 时就使用的是这里注册的 Cache 对象，在注册阶段不应该向容器中获取值，因为此时服务可能还没有 Ready；启动阶段一般用来控制如何启动你的服务，如你可以在这个阶段中 Connect to Server、Start engin 等等。Laravel 默认会注册 20 多个 Service Provider，每个 Service Provider 都为 Laravel 提供了一种新的能力：如 Cookie/Session/DB/Filesystem 等。它的所有的核心组件都是通过这种方式注册的，正是因为如此众多的 Service Provider 才使得 Laravel Container 更加强大。

我最喜欢 Laravel Container 的一点是它支持获取任何对象，即使容器里没有，它也能给你造一个。Laravel Container 支持自动帮你构造容器中不存在的对象，如果这构造这个对象时还依赖另外的对象，Laravel 会尝试递归的创建它，举个例子：

class A
{
    public function __construct(public B $b) {}
}
 
class B
{
    public function __construct(public C $c) {}
}
 
class C
{
    public function __construct(public string $name = 'Hello C')
}
 
 
$a = (new Container())->get(A::class);
 
expect($a)
    ->not->toBeNull()
    ->b->not->toBeNull()
    ->b->c->not->toBeNull()
    ->b->c->name->toBe('Hello C');

正是因为这个特性，所以在 Laravel 的绝大多数方法参数中，你可以随意的注入任意数量的参数；这也是我最喜欢的一点。Laravel 会自动帮我们从容器中获取它，如果容器不存在，则会尝试初始化它。如我们上面的 CURD 的例子中，Request 对象就是 Laravel 自动注入的，你还可以在后面注入任意数量的参数：

class CourseController extends Controller
{
    public function index(Request $request, A $a, /* arg1, arg2, ... */)
    {
        // ...
    }
}

Laravel Pipeline

Laravel 另一个优秀的设计是 Pipeline ；Laravel 的 Pipeline 贯穿了整个框架的生命周期，可以说整个框架都是在一个流水线的管道里启动起来的。而 Laravel Pipeline 的实现也很有趣；我们知道在常见的 Pipeline 设计中，大多会通过 for 循环来实现，而 Laravel 则采用的是最简单却又最复杂的实现 array_reduce。

我们知道 array_reduce 可以将一组数据串起来执行，如：

array_reduce([1, 2, 3], fn($carry, $item) => $carry + $item) // 6

但当 array_reduce 遇到全是闭包的调用时，情况就复杂了：

$pipelines = array_reduce([Middleware1, Middleware2, /* ... */], function ($stack, $pipe) {
    return return function ($passable) use ($stack, $pipe) {
        try {
            if (is_callable($pipe)) {
                return $pipe($passable, $stack);
            } elseif (! is_object($pipe)) {
                [$name, $parameters] = $this->parsePipeString($pipe);
                $pipe = $this->getContainer()->make($name);
        
                $parameters = array_merge([$passable, $stack], $parameters);
            } else {
                $parameters = [$passable, $stack];
            }
        
            return $pipe(...$parameters);
        } catch (Throwable $e) {
            return $this->handleException($passable, $e);
        }
    })
}, function ($passable) {
    return $this->router->dispatch($passable);
})
 
// send request through middlewares and then get response
$response = $pipelines($request);

上面的代码其实是 Laravel 中间件的核心代码，也是 Laravel 启动流程的核心实现；虽然加入了各种样的闭包后导致函数阅读起来十分痛苦，但它的本质其实很简单；就是像洋葱一样将所有的中间件包起来，然后让请求从最外层一层一层的穿过它，每一层都可以决定是否继续向下执行，而最后的心脏部分是最终要执行的操作。举个简单的例子，我们可以将一段文本通过各种过滤后再保存进数据库，如：

(new Pipeline::class)
    ->send('<p>This is the HTML content of a blog post</p>')
    ->through([
        ModerateContent::class,
        RemoveScriptTags::class,
        MinifyHtml::class,
    ])
    ->then(function (string $content) {
        return Post::create([
            'content' => $content,
            ...
        ]);
    });

Laravel Comnication

Laravel 的强大离不开社区的支持，这十年来 Laravel 官方已经发布了 20 多种周边生态，这里摘抄一个来自@白宦成关于 Laravel 和其他框架的对比图。

项目	Laravel	Rails	Django
ORM	有	有	有
数据库迁移	有	有	有
发送邮件	~~Mailables~~	~~ActionMailer~~	~~SendMail~~
接收邮件	无	~~Action Mailbox~~	无
管理框架	~~Nova~~	无	~~Django Admin~~
单页管理	~~Folio~~	无	~~flatpages~~
系统检查框架	~~Pluse~~	无	~~checks~~
Sitemap	无	无	~~Sitemap~~
RSS & Atom	无	无	~~Feed~~
多站点框架	无	无	~~Sites~~
前端处理	~~Asset Bundling~~	~~Asset Pipeline~~	无
WebSocket	~~Broadcasting~~	~~Action Cable~~	~~Django Channels~~
队列	~~Queues~~	~~Active Job~~	无
文本编辑器	无	~~Action Text~~	无
GIS	无	无	~~DjangoGIS~~
信号调度框架	无	无	~~Signals~~
支付框架	~~Cashier~~	无	无
浏览器测试	~~Dusk~~	无	~~System Testing~~
自动化部署工具	~~Envoy~~	无	无
Redis 调度	~~Horizon~~	无	无
完整用户系统	~~Jetstream~~	无	无
Feature Flag	~~Pennant~~	无	无
Code Style Fixer	~~Pint~~	无	无
搜索框架	~~Scout~~	无	无
OAuth	~~Socialite~~	无	无
系统分析	~~Telescope~~	无	无

除了官方，社区本身已有非常多的第三方扩展；有快速生成 Admin 管理后台的各种 Generater、有操作 Excel 的 SpartnerNL/Laravel-Excel、有高效操作图片的 Intervention/image、还有最近要被纳入默认测试框架的 Pest 以及在屎一样的 API 之上构建出来的最好用的微信 SDK EasyWechat。你几乎能在 PHP 生态中找到任何你想找的轮子。

说到这儿，不得不说 PHP 生态中了一个强大的存在 Symfony。Symfony 完全是另一个可以和 Laravel 媲美的框架，甚至在很多设计上比 Laravel 还要超前；并且 Laravel 的核心组件如路由/Request/Container 都是构建在 Symfony 之上的。但 Symfony 的推广没有 Laravel 那么好运，Symfony 发布到现在已经 12 年了，仍然处于不温不火的地位(国内看的话)，我想大概是没有一个像 Taylor Otwell 一样即会写代码还会营销的 KOL 吧。

正是因为这些强大的社区支持帮助 Laravel 变得更加强大，也正是因为这些繁荣的生态保护着 PHP 一步一步走到现在。有些开发者可能觉得 PHP 已经走向衰亡了，并且十分鄙视 PHP 着门语言。我其实很不明白作为一名工程师为什么我们会瞧不上某一门语言？每一门语言都有着自己天然的优势，PHP 作为一门脚本语言在 WEB 开发这块儿有着极快的开发速度，加上上手难度低，工资不高，对于初创型企业来何尝不为一个好的选择呢。我不会因为写 Python 就觉得 PHP 屁都不如，也不因为写 Rust 就觉得 Go 狗都不如；在我看来，语言只是实现产品的一种方式，不同的语言在不同的领域有自己的优势，我们应该学习不止一门语言，并尽量了解每一门语言的优缺点，在完成开发时选择自己以及团队合适的，而不是只会写 Java 就觉得其他语言啥都不是。

不足

Laravel 为人垢弊的问题就是太慢了，一个普通的应用一个 RTT 可能也要 100～200 ms；当遇到稍微大一点的并发请求时，CPU 的负载就奔着 90% 去了。为了解决 Laravel 速度太慢这一问题，Laravel 团队在 2021 年的时候推出了 Laravel/Octane，如果你对 Laravel Octane 感兴趣，也可以看看我之前写的文章 — Laravel Octane 初体验。加持了 Laravel Octane 的应用，我们可以把请求响应做到 20ms 以内。

不过我觉得 Laravel 的不足不在性能，毕竟 PHP 作为脚本语言，就算我们把它优化到极致，也不可能达到类似 Go 那么高的吞吐率，如果真的是为了性能，那为什么不选择其他更适合的语言呢？

在我看来最大的不足是繁重的社区生态；Laravel 之前只有 Blade 模版引擎，其语法和其他模版引擎大同小异，学起来很容易上手；后来 Laravel 推出了 Livewire 和 Inertiajs。Livewire 和 Inertiajs 都是一种类前端框架，它们提供了一种更加高效的方式来管理前端页面，并且能更好的和 Laravel 整合在一起。但是它却带来了更高的学习成本和更多人力资源的浪费。本来我们只需要熟悉标准的 Vue/React API 就好了，现在却不得不学习一种新的语法，而这些语法是构建在我们熟悉的 API 之上的；有时候你原始的 API 你知道怎么写，但是新框架的新语法让你不得不查看更多的文档甚至源码，你不得不花更多的时间去适配它；而当你的团队有新人接手这些项目时，他也得跟你走一样的路，并且 Laravel 团队说不定哪天还会弃用它们(如 Laravel-Mix)。

这里还有个例子是 Laravel 在之前推出了 Laravel Bootcamp 用来教新人怎么快速上手 Laravel，但这之前只推出了两个版本，即 Livewire 和 Inertia，好在是被社区大佬及时反应后才在再后来加上了最原始的 Blade 支持。

Laravel 官方还推出了 Laravel Sail、Laravel Herd 还有更早之前推出现在被弃用的 Laravel Homestead 等本地开发环境工具；而部署工具 Laravel 推出了 Laravel Forge、Laravel Vapor 还有 Laravel Envoyer；如果你作为一个 Laravel 新人你知道用什么搭建本地开发环境吗？又用什么部署你的 Laravel 应用吗？说实话我用了 Laravel 这么久我也不知道。我更建议大家的是如果你对 Laravel 感兴趣，不要一来就接触 Laravel 这些复杂的概念，老老实实的在本地安装好 PHP/Nginx/PostgreSQL 或者 Docker；而如果你要还要用它写前端页面，老老实实的用原生框架如 Vue/React/Bootstrap 甚至 Blade 才是更好的选择。

Laravel 还有很优秀的设计我没有在这篇文章中指出来，如果你对 Laravel 感兴趣或者想写出一手还不错的代码，我真的建议你看一看 Laravel 的源码，看一看他的设计，我觉得这些设计在所有的语言中都是通用的，enjoy。

参考

一条甲鱼

Sat, 04 Nov 2023 15:21:48 GMT

老丈人在自家的鱼塘里钓了一个甲鱼。

说是甲鱼，但若你说是乌龟，我也是信的。「头大的就是甲鱼」，老丈人说道。「乌龟是长不大的」，阿宝补充说。我其实是不忍心杀来吃的，我想它也不愿意被我们吃，不然也不至于一直把头缩进壳里。我更意愿把它养在院坝边上的池塘里，哪里有一个倾斜的大石头，平时是用来洗鞋子洗衣服。我想它很愿意躺在上面嗮太阳。但它晒太阳时会不会被狗叼走呢。

老丈人收拾鱼时，黄标和大白就睡在他旁边；时不时的摇摇尾巴，或者用嘴巴咬咬腿上的格蚤。黑儿不见了。听老丈人说是被哪些骑摩托车的狗贩子打了去，怕是回不来了。我挺喜欢黑儿的；它是最忠诚的狗。不管老丈人开着三轮车去哪里，它都永远跟在后面。现在它不见了，我猜老丈人还是有点感情的吧。但农村的猫狗要是不见了，是不会在电线杆上贴告示重金求狗的。乡里人想的是，说不定那天它就回来了，要是一个月还不回来，那回不回来已经不重要了，他们早已经忘记了对方。

对于看家护院来说，两条狗就已经够了；丈母娘就经常对老丈人说：「喂那么多狗，狗吃的比人还多，简直是浪费粮食」。老丈人虽然不是地主，但余粮还是有，几条狗也是养得起的。不过有些狗越养越懒，要是有一天变为流浪狗了，它甚至都不能自力更生，少有能自食其力者，不是偷这家的蛋，就是偷哪家的鸡，搞得附近几个村子鸡犬不宁。想想他的祖先狼，狗都觉得惭愧。

好，就写到这儿吧。

老丈人系列

NativePHP 的技术原理和实现细节

Tue, 25 Jul 2023 08:37:52 GMT

这次的 LaraconUS 发布很多很有意思的项目，比如我在这里提到的 Laravel Prompts/Laravel Folio/Laravel Herd/Pest 2 以及 ~~beyondcode~~ 这两天发布的比较重量级的产品 —— NativePHP 等。

需要强调的是这次发布的诸多产品中只有 Laravel Prompts/Laravel Herd 属于官方出品，其他均为社区项目。

这篇文章主要想探讨一下 NativePHP 的实现细节、使用了哪些技术、它的生命周期和工作原理等，如果文章中有任何纰漏，欢迎留言指正。

在使用 NativePHP 之前，官方文档第一步就是需要在 Laravel 项目中安装 nativephp/electron：

$ composer require nativephp/electron
 
$ php artisan native:install
$ php artisan native:serve

安装成功后即可通过 native:install 安装所需的 Node 依赖并通过 native:serve 启动 Native APP。从 Electron 这个名字就可以大概猜出，目前的 NativePHP 生态中，主要是使用 Electron 来进行 APP 打包。我们先顺着 native:serve 看看整个 Native APP 是如何启动起来的。

Boot NativePHP

命令 native:serve 是一个标准的 Laravel Command，它的核心逻辑类似于 CD 到 resources/js 目录并执行 yarn run dev 来启动 Navite APP。

NativePHP Electron 这个包下面的 resources/js 目录是一个完整的前端工程，它主要使用 electron-vite 来编译及调试 Electron 项目，package.json 的部分编译代码如下所示：

"scripts": {
  "start": "electron-vite preview",
  "dev": "electron-vite dev --watch",
  "build": "electron-vite build",
}

整个前端工程除了使用 electron-vite 来启动 Electron App 外，并没有做其他额外的事情。从他的入口文件 main/index.js 你可以看到它主要是调用 nativephp-electron 这个前端插件来启动 NativePHP APP。

NativePHP 的 Electron binding 的全部功能都是在这个前端插件 electron-plugin 里实现的，主要的流程包括：

通过 express 启动一个 API Server
通过 PHP -S 127.0.0.1 启动 PHP Server
通过 artisan 运行 Laravel 数据迁移
通过 artisan 运行 Laravel WebSocket
通过 artisan 运行 Laravel Queue
启动定时任务
发送 Booted 通知
添加事件监听
添加 Terminate 事件

Start Express API Server

其中最核心的是通过 expressjs 框架启动一个 API Server，在这个 Server 中定义了许多和 APP 交付的 RESTful API；比如操作剪辑版、窗口管理、菜单管理等。当我们想在 Laravel 系统中操作 Electron APP 时，实际上操作的就是这些 API。

举个例子，在 Laravel 中你可以直接通过 Window Facade 快速的设置窗口大小，这个操作本质上会发起一个对 Express Api Server 的 POST 请求；Express Server 在收到这个请求后，会通过 Electron 的 BrowserWindow 对象设置 APP 窗口大小。

use Native\Laravel\Facades\Window;
 
// POST window/open {width: 800, height: 800}
Window::open()->width(800)->height(800);
 
// Electron
const window = new BrowserWindow({
    width: windowState?.width || parseInt(width),
    height: windowState?.height || parseInt(height),
})

Start PHP Server

Express API Server 启动完成后，Electron Plugin会尝试启动 PHP Server。这里非常简陋的使用了

php -S 127.0.0.1:$phpProt

的形式来启动 PHP 服务。因为这个项目还未正式发布 1.0 版本，所以目前的这个临时过度我认为是可以接受的。期待后期社区添加专业的 Web Server 支持。

注意这里每启动的一个 Server 如 API Server、PHP Server 都会是一个单独的进程；Electron Plugin 会收集这些进程的 PID，待关闭 APP 时会一并把这些所有进程 KILL 掉。

还需要注意的是由于每个进程都是单独启动的，也没有使用 Supervisor 一类的进程管理工具，当某个进程意外退出时，可能会导致你打包的整个 APP 不可用。

Add Event Listeners

Electron Plugin 插件在主要的 API Server 及 PHP Server 都启动完成后，会注册大量的事件。这些事件主要是为了捕获 APP 端的状态变化。比如用户重新设置了窗口大小、用户打开了一个 URL 等；而这些事件全都会通过 RESTful API 发往 PHP Server。

window.on('resized', () => {
  notifyLaravel('_native/api/events', {
    event: 'Native\\Laravel\\Events\\Windows\\WindowResized',
    payload: [id, window.getSize()[0], window.getSize()[1]]
  })
});

举个例子，上面的程序会监听 Electron BrowserWindow 的 reseized 事件，当 Electron APP 触发这个事件后，会向 PHP Server 发起一个 Post 请求，请求的路由 _native/api/events 被定义在 NativePHP/laravel 这个 composer 包当中，这个包会随着你在刚开始安装 nativephp/electron 一并安装。

await axios.post(
  `http://127.0.0.1:${state.phpPort}/_native/api/events`,
  payload,
  {
    headers: {
      "X-NativePHP-Secret": state.randomSecret,
    },
  }
);

PHP Server 中这个更新 Events API 的功能很简单，就是将传入的 Event 初始化并触发事件；这样一来整个 Laravel 系统都会感知来自 Electron APP 的任何状态变化。

// route.php
Route::group(['middleware' => PreventRegularBrowserAccess::class], function () {
    Route::post('_native/api/booted', NativeAppBootedController::class);
    Route::post('_native/api/events', DispatchEventFromAppController::class);
})->withoutMiddleware(\App\Http\Middleware\VerifyCsrfToken::class);
 
// DispatchEventFromAppController.php
class DispatchEventFromAppController
{
    public function __invoke(Request $request)
    {
        $event = $request->get('event');
        if (class_exists($event)) {
            $event = new $event(...$request->get('payload', []));
 
            event($event);
        }
 
        return response()->json([
            'success' => true,
        ]);
    }
}

所有事件注册完成后，Electron APP 就算启动完成了。不过这并不会打开任何窗口，我们必须得在 Laravel 中注册你想打开的窗口。随着你执行 native:install 已经在 NativeAppServiceProvider 中注册了根目录 / 为默认打开的窗口，如果你的 PHP Server 运行在 127.0.0.1:8080 上，那 http://127.0.0.1/ 就会是 Election APP 默认打包的页面，至于 Election 如何将一个网页打包为 APP 不在这篇文章的讨论范围内，我们只需要知道更定一个 URL 地址，Election 就能将它整个打包为一个 APP。

我们也可以通过 Window 设置为默认打开的窗口为登陆页面，这将使用 http://127.0.0.1/login 路由为默认的打包窗口。

// NativeAppServiceProvider.php
Window::open()->url(url('/login'))->width(800)->height(400);

Why NativePHP

如你所想，由于 Electron APP 是运行在 JavaScript 环境的，而 Laravel 是运行在 PHP 环境的，在 PHP 环境中我们不能直接操作 Electron APP。NativePHP 在这里的价值就是提供了一套相对完整的 API，通过操作这些 API 我们就能非常方便的和 Electron APP 进行交付。而且我们不需要关心项目打包的具体细节，也不需要手动对接这些 API；NativePHP 已经非常深度的把他们集成到了 Laravel 环境中，我们可以高效的在 Laravel 中使用这些魔法而不用关心具体的细节实现。

可以理解为 NativePHP 为我们提供了一套统一的 API 去操作 Native APP，我们不需要关心 Native APP 的底层是使用的 Electron 还是 Tauri，NativePHP 都会适配这些第三方的打包工具，并为他们实现一套完整的 API Server。不管是现在已经发布的 Electron Plugin 还是即将发布的 Tauri Plugin，作为开发者我们都只需要站在更高的纬度使用 NativePHP 就好了。未来 NativePHP 会不止适配 Laravel，还会适配如 Symfony 等其他框架，这给我们使用 PHP 开发 Native APP 提供了一个很好的机会。不过就目前发布的 Electron Plugin 插件来说，想要适配其他框架可能还很麻烦，如果后续仍然使用这个前端 Package 来同时适配多个 PHP 框架，可能还需要做比较大的重构比如单独抽离一个 Event Core、Core Server API 等等。

感激社区，PHP IS DEAD.

佐玩的面试挂了

Sat, 22 Jul 2023 14:18:53 GMT

佐玩的面试挂了，我很伤心。

其实我有信心能过的，毕竟我对自己的 Laravel 还是很有自信。但是很遗憾，打脸了，我和预期可能还差很远。我开始想要是能进这家公司的话，我又能愉快的写 Laravel 了，又能在全是大佬的氛围下学到更多了。但现在看来我的自己好好规划下后面的路。

我之所以想改变的原因是因为现在的工作我觉得我学不到太多的东西，或者说付出的时间和得到的收获并不匹配，我担心这样下去自己会丧失竞争力，所以才想着改变。而这短暂的尝试发现自己能力可能并没有达到自己预期的样子，我得静下心来想想怎么提升自己。

首先要做的是花更多的时间学习英语。学好英语我后面才有更多的选择，才敢把选择的范围放大。现在的我基本每天都只在 Duolingo 打个卡，平时交流也是用 OpenAI 翻译，这一年下来虽说有所进步但一直没有什么质的变化；口语还是稀烂，英语口语课也不去上，也听不太懂别人说什么，更没有勇气参加英文面试。

第二件我觉得需要做的就是从现有的工作中深入学习，挖到更多值得学习的内容。比如公司项目一个请求的生命周期，整体的部署架构，用到的中间件；如何模仿公司的项目架构自己搭建一个一样的；目前负责这一块儿的完整的业务逻辑。从这些总能学到更多我以前忽视的东西。既然没有其他更好的变化，我就得着保持目前工作的稳定。

第三件需要做的是保持激情，时刻对新的东西充满热爱，敢于尝试。学习更多的新技术并尝试做点不同的 demo 出来。多输出，哪怕是在推上发一些小的看法和学习的心得。其次就是对中意的公司或者项目保持关注，多贡献自己的 PR 哪怕是改个单词。我觉得只要是对一个项目付出别人十倍的时间，并提交各种不同的 PR 或帮助解决不同的问题，总有一天你会被项目 OWNER 看到，说不定就会收到面试机会。这也算是参与开源的小私心吧。

这世界充满了比你优秀的人，你只要一直保持认真，他就输了。

21 Jul 2023 at 23:50

老家的变化

Sun, 26 Mar 2023 12:48:51 GMT

我的老家在贵州的一个山沟里，那里有四五个小村庄坐落在几座大山脚下，中间有一些田和一条小河，还有条水泥马路把它们串起来形成一个长约 3 公里的跑道；还有新安的路灯；我们家门口就有一盏路灯。

前几天接到老妈的电话，说邻居家有人过世了，我必须得回去一趟。平时村子里的红白喜事我多半是不会回去的，偶尔回去一次可能会听到「连波回来了啊，请到假了吗」的嘲笑声，这时我多半会拿出回家之前买的二十五一包的中华，化解尴尬的同时希望能堵住他的嘴。

我不知道这规矩是什么时候开始的，但规矩就是不管谁家要办酒，周围的人每家都自少要回来一个人帮忙，哪怕你父母就在老家。「人家在上海的都回来了，你在重庆这么近不回来不像话」老妈在电话里这样给我说道。我也问过他们家里有人还大远处赶回来的人，得到的回答基本都是「那有什么办法呢」。

我觉得办法肯定是有的，乡里人好面子这事情也是真的，大家回去的目的多是为了得到一个好名声，这些好名声通常会在长辈闲谈时体现出来：谁家办酒所有人都来了，王二好像又没回来，以后他家办酒大家都不去帮忙，让他抬丧都找不到人。而说是帮忙，其实大部分是来打牌的，谁家打牌的人多，也侧面说明了他家的人脉广。主人还不要忘记照顾好打牌的人，热茶香烟，炭火宵夜都是要有的。

噢还有女人们，她们总是最忙的人。她们会在厨房从白天忙到晚上，而帮忙的人们是不进厨房的。待到女人们把宵夜煮好用茶盆端到牌桌上，帮忙的人也不会停下手里的工作，而是一边看牌一边吃。吃完后碗多半你是找不到的，毕竟这东西放在牌桌上碍事，它应该放在其他任何顺手就能放的地方。

我问过她们这样累吗，她们好像麻木了，世界就是这样的。

老家越来越好了，可我第一次有了不愿回去的想法。

2022 年终总结

Wed, 04 Jan 2023 09:55:30 GMT

多年后我会向我女儿讲述这一年发生的各种事，就像已故的爷爷给我讲述「人民公社」时代的故事一样。

这一年，国家站在战争发起的一方，人们嘲笑被刺杀的首相，孕妇会因为新冠拒诊而流产，火灾会活活烧死逃生通道被焊死的孩子们，清零的大巴在夜间翻车，诸如等等，以至于忍无可忍的人们举起了白纸……

但就具体的个体而言，即使这世界充满了太多的糟粕，我的故事还是时而平淡、时而惊喜的往前走着。

Life

惊喜的是年初的时候老婆怀孕了，我俩有了共同的希望都在小心翼翼的呵护着；我很庆幸因为全职远程的缘故，可以有更多的时间陪着她，可以一起看电视、一起散步、一起看我打游戏。由于散步的地方多了，以至于三个月后每个地方都能找到她孕吐时期留下的残留物。度过了艰难的孕早期，我们在七月离开了重庆前往贵州的老家，在那里我们呆了一个多月。我太喜欢在老家的那段时间了；房子后有山，可以去找点什么吃的，荔枝、板栗、猕猴桃；村前有河，和钱红们抓的鱼熬的汤老婆现在都在说好吃；还有那承包养殖小龙虾不成变成的耦田，每个从城里回去的姑娘总会来护两朵荷花在胸前拍照留恋；晚饭后还可以围绕村村通的水泥路溜达一圈，要是时间凑巧的话，西下的太阳散发出的肉眼可见的光，照在马路边栏杆旁农户种的茄子黄瓜和手拉着手散步的你们身上，又有什么比这样的日子更值得向往和留恋呢。况且在农村也能把钱挣了。

年底的时候老婆给我生了个闺女，从此我变成一个有软肋的人了。在生产的前几天，老婆阳了；住院后，我也阳了。所以那两天的晚上，是一个待产的孕妇照顾她那发烧发冷的丈夫，而她的丈夫在白天醒来后才会软绵绵的端水打饭；好在这个妈妈足够坚强，甚至于不打无痛也能在一个半小时左右顺下我们的闺女。当她发消息告诉我：「生了，是个妹妹，没打无痛」时；我眼泪都流出来了，一半是因为激动，一半是因为心痛。

有了闺女后，我开始担心这个黑暗吃人的世界，我担心你墙上的影子看多了，就以为它原本就是那样。父本淡泊，该如何保护你，让你健康快乐的长大呢？有时候甚至在想：学好外语吧闺女，以后逃离这个丑陋的国度，顺便带上父母一起离开；有时候又想，世界本来就是这样，不能让人处处满意，当你遇到什么不开心的事时，试着想想它好的一面，乐观的看待这个世界会给我们带来更多的快乐，毕竟生活是自己的，快乐也是自己的。

Something Else

去年的这个时候我还在新公司 OnBoarding，一晃我已经全职远程一年啦。我很喜欢这样的工作形式，我感觉所有的时间都是自己的，可以早上十点开始上班，中午躺在床上睡个自然醒的午觉，醒来后阅读下 Slack 同事们的讨论，单测写完后提两个 PR。有时候一张 Ticket 要几天或者几个月才能完成，当然不是因为偷懒呢，更多的是需要等待别的团队的同事先完成其他的任务。但就技术而言，我这一年并没有多大的提升，因为他们会尽量把要做的任务拆分为一个个可独立开发和测试的最小单元，并且非常完整及详细的描述这个任务应该怎么做。这导致你在做这个任务的时候接触的面十分受限。我猜这也是为什么连 Senior Engineer 离职也不需要写交接文档的原因。不过就像同事说的那样，还可以在其他软技能如开发流程、组件的使用(AWS/DataDog/Jira/GoogleWorkspace)、公司架构的摸索(MonoRepo/Thrift/gRPC)、英语口语、邮件沟通等方面找到弥补的。

今年下半年开始我一直在 Duolingo 上学习英语，到现在已经坚持 180 天了，虽不太确定这样会有多大的效果，但起码 Twitter 上的英语推我大抵是看得懂了，在和同事沟通时也不再像年初那样每次都要用 DeepL 翻译了，不过口语和听力还是很差，每次站会看着同事们用英语你来我去的交流时，我好想把他的英语能力复制一份到我脑里。对于我们开发工程师来说，我真的建议每一个人学好英语，然后把你的雇主从某一个具体的城市扩大到全国甚至全世界。当你把你的工作目标放到全世界后，哪里又有什么 35 岁危机呢？况且从 Linkedin 上的招聘来看，只要你英语达到能正常交流的程度，技术匹配，薪资都能在 $6K+ 左右，我希望我能在五年内达到这一目标。

Last

写到这儿 2022 年就算过去了，也不再展望来年，只愿每一位身体健康。

2023-01-04 17:31

一九三九年春在太原

Mon, 19 Sep 2022 12:48:32 GMT

自由被关在城外了。

只有时候，从野外吹来的风，使你嗅到一点着自由的气息。很细致，很新鲜，很温暖，并且很有生气。在这种感觉里，你可以想到，黔南已解封了，草已经发芽了，戏已经演完了！

但我却出不了门。

一整天，我所看见的，是白色的墙，白色的土，和穿着白色衣裳在街头守望的兵。我气闷而且窒息。连行动也被强度的限制着了。出门。要通行证；到街上去，要健康证。并且七点钟已经开始戒严了。为了免掉那些白色同志对你采取攻击式，端起枪来，并且对准你的脑袋，我只好一个入关在屋子里。

而我的屋子，又恰巧临着街。一整夜，我全听见「这是为你好」的声音，这在深夜里，特别加重了恐怖的氛围。

2021 年终总结

Fri, 28 Jan 2022 10:31:19 GMT

劝君更尽一杯酒，西出阳关有故人。

11 月底从公司离职后，我变成了一个自由人；这个时间点离职很尴尬，一是距离过年还有两个月，二是不太好找工作；果不其然半个月下来面试都垮掉了，想去的诸如腾讯、字节、吉利等大一点的公司，都失败了。今年年初的时候其实已拿到两家的 offer，只是嫌工资低大小周没去。如今时过境迁，养尊处优的过了大半年后处处碰壁，才晓得在重庆这个互联网行业不太景气的城市，选择的机会是越来越小。

在公司的最后几个月里，几乎每个月都要吃一两顿散伙饭，你可以从这条 Twitter 时间线看出个大概。而未离职的大家刷题的刷题，考公的考公，也有朋友今年成功上岸的，甚是厉害。我对于进体制内一直不感兴趣；一是我的性格不适合这样的工作，就算考过可能连政审也通不过，二是钱太少。当然最重要的是我害怕就如大学刚毕业时进入体制内的朋友说的那样：“我这辈子就这样了！”。不过这只是属于我自己的看法罢了，每个位置都能发挥他的价值，有些鸟是关不住的；从朋友圈看的话🐶，也有朋友在公务员这个位置干的风生水起的。只是我在这个岗位上看不到我的价值，你没法说服我同意你的看法，我也没法说服你认同我的看法，相互尊重就好啦。

I have to remind myself that some birds aren’t meant to be caged. Their feathers are just too bright. And when they fly away, the part of you that knows it was a sin to lock them up does rejoice.

今年还想反思的就是自己的表达能力，很多时候心里是这样想的，说出来就变成另外一种意思了，并且自己还没意识到说错了。因为这个问题，没少跟媳妇吵架，也因为这个问题，没交到几个珍惜的朋友。我现在都还后悔几年前因为自己表达能力的问题失去了一个知心好友的机会，虽然现在我们也算是朋友，但我感觉始终有隔阂再也难成长起来了。

去年定的目标今年看来就勉强完成了锻炼身体这一项，从 iWatch 的统计看的话，今年大部分时间都合上了三环记录。下图是我今年每月运动次数统计（绝大部分都是走路上班）。虽然自我感觉良好，但身体是真的大不如前了；现在一个普通的感冒靠自愈一个星期也好不了，还得吃药做雾化。

还有件值得高兴的事是我终于有自己的车了。原本这辆车是超预算了的，为了诱惑老婆让我买这辆，我天天在她面前用迈克唱 Dangerous 的调子唱星越 L 星越 L 才得偿如愿，接下来就可以开车去兜风咯。

年底的时候我终于找到了我曾梦想的工作，Full Time Remote Work，做到了如推特网友说的那样，在国内拿美刀，希望新的一年我能做出一些有意思的事情。

TODO

参考我在推特上已经发表的 Keywords that describe 2022 for me 为来年细化一个目标吧。

往年总结

他们的 2021

刷抖音

Fri, 12 Nov 2021 03:10:04 GMT

从前听人说：中国人人人具有三种博士的资格：拿筷子博士、吃瓜子博士、刷抖音博士。

而三种技术中最进步最发达的，要算刷抖音。近来抖音大王的畅销，便是其老大的证据。据关心此事的人说，抖音大王一类的视频 APP，最近市上流行的有许多种类。最初是某大公司”用推荐算法” 创制的，后来有什么“某手公司” 、“某红书公司” ……等种种出品陆续产出。到现在差不多无论哪个穷乡僻处的小产品上，都有几 TB 的视频陈列而倾销着了。现代中国人的精通刷抖音术，由此盖可想见。

我对于此道，一向非常短拙，说出来有伤于中国人的体面，但对自家人不妨谈谈。我从来不曾自动地找求某音来刷。但到人家作客，受人劝诱时; 或者在酒席上、重庆的茶楼上，也会不由自主的把手机拿出来，而当发现一个消息也没有后，也便点开抖音滑了起来。我必须注意选择，选那较短、搞笑、而或乡村田野的视频，而对于那些奇装异服的、好嗨哟一类的，我多半是拒绝的。而每每到了饭点，或被人惊扰时，才发现已经过了半小时。碰到这种时候，我就下个决心，从此戒绝抖音。戒绝之法，大抵是站起身来，喝一口茶漱一漱口，点起一支香烟，或者把手机推开些，以示不再对它发生关系。然而过了几分钟，与别人谈了几句话，不知不觉之间，手机就已经在手上了。等到自己觉察破戒的时候，往往已经看了好几个视频，而这时候会想，不要紧的、在刷几分钟，后面在戒的了。这样，吃了非戒不可，戒了非吃不可；吃而复戒，戒而复吃，我为它受尽苦痛。这使我现在想起了抖音觉得害怕。

但我看别人，精通此技的很多。我以为中国人的三种博士才能中，刷抖音的才能最可叹佩。常见闲散的少爷们，一只手指间夹着一支香烟，一只手握着一个手机，烟雾缭绕，且滑且笑，且笑且走。从容自由，真是「交关写意」！他们精心的挑选自己喜欢的视频，遇到不满意的，只消“格”地一滑，再把嘴里的烟“啪”地一吐，而在那里嚼食着新的食粮了。那手指真象一具精巧灵敏的机器，不绝地塞进视频去，不绝地咀嚼着，……全不费力，可以永无罢休。

发明刷抖音的人，真是一个了不起的天才！这是一种最有效的“消闲”法。要“消磨岁月”，除了抽鸦片以外，没有比刷抖音更好的方法了。

在世间一切事物之中，想来想去，只有抖音。所以我说发明刷抖音的人是了不起的天才。而能尽量地享用抖音的中国人，在消闲一道上，真是了不起的积极的实行家！试看理发店、地铁上抖音大王的畅销，试听小面馆里、公交车上、家庭中满屋的流行音乐，便可想见中国人在此之道上消磨去的时间，每年统计起来为数一定可惊。将来此道发展起来，恐怕是全中国也可消灭在朗朗笑声中呢。

我本来见抖音害怕，写到这里，觉得更加害怕了。

《吃瓜子》

一包烟

Fri, 29 Oct 2021 07:45:49 GMT

读小学的时候我有机会通过自己的劳动获得一包烟，但我拒绝了。

那是小学三四年级，正值播种，我和小伙伴叫鸡一起去大田坎排秧。什么是排秧呢？排秧不及栽秧，排秧是把牙签长的秧苗一根根的插到细田里；而栽秧要等其发芽长大后，再一根根的把它们扯起来，捆成一把一把的甩在田里，再三五两根的插在田中。排秧这活路要是用一个大劳力来做的话，就显得大材小用了，所以种田较多的农户一般都是喊些孩子来帮忙。

我们去了一天，还在农户家睡了一晚。忘记了是开工前还是收工后，农户一人给我们发了个咸鸭蛋，还有一包烟。农户把烟递过来时，我一边摆手一边说：我不抽烟。2002 年，应该是我爸抽的那种 1 块 5 一包的黄果树吧。农户问了一遍后也没有勉强，就递给了下一个小伙伴，看着小伙伴都收下那包烟后，我好像感觉我做错了，我内心甚至幻想农户再来问我一次，我就能得到这包烟了，虽然我不抽，但我可以带回去给爸啊。通过自己的劳动换来的礼物，爸爸肯定会喜欢的。

但幻想的场景并没有出现，在回去的路上，伙伴就说我为什么不接下那包烟，拿回去给你爸爸抽多好。本来就有点后悔的我更加抑郁了。回到家后的第二天，我在菜土里跟爸爸说了这件事：我真该给你拿回来的。没想到我说完反被老爸骂了：你不抽烟就不该拿别人的，不要以为别个都拿了你不拿你就做错了，老子还买不起一包烟让你在外面拿回来吗。被骂完后我的抑郁一扫而空，又高兴得是一个孩子了。

这么多年过去了，我还对这件事印象深刻；虽然老爸没读过什么书，只知务农和种烟，但他却从来没让我的三观走歪过。

我的阅读清单

Mon, 18 Oct 2021 08:11:09 GMT

记录我目前正在看的或已经看完的部分书籍(纸质)，并记录当时（现在觉得当时）可能存在的感想。

2023

《小米创业思考》
《WhatIf》
《一只特立独行的猪》
《万寿寺》
《微服务架构设计模式》
《性能之巅》
《凤凰架构》

2022

《白鹿原》
《邓小平时代》
《娱乐至死》
《松本行弘的程序世界》
《精通正则表达式》
《黑客与画家》
《我的二本学生》
《草房子》
《窗边的小豆豆》
《苏菲的世界》
《人性的弱点》
《自己动手实现Lua》
《未来世界的幸存者》
《乌合之众》
《结网》

2021

已完成

《图解TCP/IP》
《Linux程序设计第4版》
《CODE（编码）》磁生电，电生磁，方生万物；
《态度》看完以至于我在做一些特别 LOW 的事情时都在想：要是吴军老师来做这件事的话肯定不会这样做。然后我就换一种方式了，虽然可能会更差。
《动物庄园》一群猪的革命。
《两周自制脚本语言》设计还行，但有点过时了，14年出版的书了，现在设计脚本语言的话可看「自己动手实现Lua」。
《Go 语言专家编程》名字很浮夸，但内容却是很实在，值得一看。
《Go 语言高级编程》
《数据密集型应用设计》
《Redis 设计与实现》虽然书中使用的 Redis 版本比较久，但如书名一样真真实实的讲解了各种数据结构的细节实现。期待作者的新书。
《黄金时代》第一次读王小波的书，感觉还可，后面在买点来读读。
《四个春天》这两年最喜欢的同名电影的衍生物，超合我胃。
《浪潮之巅（上下册）》版本买低了，很多预言已经成真。推荐买新版，书很不错。
《刀剑神域01》没动漫好看，动漫看起来更刺激。
《文城》不是很好看，你要是喜欢余华老师的话还是可以一读，见读文城有感。
《读库2103》多抓鱼拼单买的，其中「我在北京送外卖」和「我在上海开出租」是很不错的。
《三体》我是一直努力向上的虫子，见读三体有感。

2020

《Go 语言设计与实现》作者是一个大神，写的很深奥，一直「想」通过通俗易懂的文字翻译一篇他的博客。
《深入理解计算机系统》神书，推荐每一个从业者阅读。我看了两年，目前看到第三章。
《每天5分钟玩转Kubernetes》每天玩5分钟的话，还是玩不转，建供参考。
《计算机是怎么跑起来的》
《程序是怎么跑起来的》
《网络是怎么链接的》这三部曲比较通熟易懂，适合如何；但一些细节没有解释清楚。
《且听风烟》且当作一个小故事来读吧，没有什么特别的营养。
《通往奴役之路》读不下去了，准备换本。
《硅谷革命》回忆苹果公司的疯狂往事，见读硅谷革命有感。
《在细雨中呼喊》
《第七天》那是另一个天堂，在人死后。
《码农翻身》用故事的方式讲技术最好的书籍，虽然细节不太关注，但原理给你说得明明白白。
《重构改善代码的既有设计》搁浅中。
《MySQL技术内幕，InnoDB 存储引擎》搁浅中。

2019

《你不知道的 JavaScript（上/中卷）》
《程序员的自我修养链接、装载与库》一书了解程序的本质。
《计算机网络自顶向下方法》
《程序员修炼之道从小工到专家》初读太过理论了，可能当时工作年限较小，很多地方觉得无所谓。应抽时间再读一遍。
《许三观卖血记》究竟是谁，在逼我卖血？

2016

《MySQL必知必会》 MySQL 入门必备，不过现在试图/存储过程等概念用的少了，可做了解。
《JavaScript 高级程序设计第三版》 JavaScript 圣经级书籍，讲的很全面，可用作系统学习 JS 的参考书。未看完。
《Head First 设计模式》设计比较好的入门书籍，有一定工作年限在看更好理解。
《深入PHP：面向对象、模式与实践（第3版）》面向对象程序设计，内容一般般。
《PHP与MySQL程序设计（第4版）》入门书籍，内容较为简单，学到的东西不多。
《Thinking in Java》当初学 Java 时买的，后来转 PHP 就送给我朋友了；朋友后来又转前端了，下次遇到他我要让他还我，我还没看呢。

2011

《白夜行》我的天空里没有太阳，全是黑暗，但并不黑，因为有东西代替了太阳。看完《平凡的世界》再来看这部，我心中的信念更强烈了，没有什么能够阻挡，我对生活的向往，哪怕是我在工地搬砖，我也能够看到我的太阳。
《人生》生活总是这样，不能让人处处都满意。但我们还要热情地活下去。
《平凡的世界》有生以来影响我最大的一本书，四年大学最有价值的事就是在同学那里借了五十块钱在地摊上买下这本书。他在我最需要的时间里，告诉我不管处于什么样的环境，不管以后是在工地搬砖还是深坑挖煤，在面对生活时依然保持乐观继续学习。看着书时我大概写了 20 来篇日记，直到晓霞走时我竟完全不敢看下去，我抑郁了好几天，我不知道少平听到这消息会怎么办。
《活着》这是第一部读余华老师的作品，酣暢淋漓，简直一口气就能读完。好像活着就是为了活着而已，若大的苦难，皆可乐观。余华老师现在的作品没有能超越这部的。
《边城》讲些什么忘记了，看来印象不深，只记得有个小女孩有个老人，插画很美。
《霍乱时期的爱情》说实话我觉得这书一般般，一位享受完荣华富贵的女子在年老丈夫死后，回头选择了最求自己一生的人。
《忏悔录》不知道写的什么了，只看了上部，没警醒我需要忏悔的地方；现在在家垫台灯。
《悲伤逆流成河》还是被结局所震撼了，居然全都写死了。
《围城》围来围去大可不必，若你吃到一颗好吃的鸡蛋，你会去寻找下蛋的母鸡吗？
《穆斯林的葬礼》其他忘了，只记得最好的生日礼物是：「海上生明月，天涯共此时」。还有一句：随珠和璧，明月清风。
《追风筝的人》说实话感觉这书没那么神，可能是我当时不知道在那小巷子里发生的是什么事吧。

2008

《钢铁是怎样炼成的》高一时期期末考试第一名学校的奖励，后来把他赠给表弟了，不知道他是否看完。那时冬妮娅是我心中唯一的女神。

讲个鬼故事

Mon, 11 Oct 2021 02:34:06 GMT

鬼到底是有的是没有的？传说上有人见过，还跟鬼说过话，还有人在后边被鬼追赶过，吊死鬼一见了人就贴在墙上。但没有一个人捉住一个鬼给大家看看。

连波先生讲了他看见过鬼的故事给大家听：

“那是在丝绵……” 连波先生说，“十六年前……”

那时候连波先生刚上初中，下午放学后要是带的米不够做饭了，连波先生就会回家去吃。两地相隔 4-5 里路，最快要走四五十分钟。几里路不算远，但必得经过一处山坳，山脚山顶都无人家，传言山脚小溪旁的白橡树上还有人在哪里上过吊，如今枯了的树干更显得荒凉。

连波先生有时候吃饭吃的晚了，六七点才回学校的事也常有。有一天连波先生就回得很晚，天空模模糊糊，能看见行人，但也不至于太黑。

连波先生向着归路走得很起劲时，往山坡处一看，远远有一个白影。

连波先生不相信鬼的，乡里有人谈起鬼时，连波先生常常不屑一顾，只认为那是他自己产生的幻觉，所以对于这个白影，连波先生是不怕的。

走了不几步，那远处的白影没有了，在看突然又有了，走了不几步，那远处的白影没有了，正和鬼一样，鬼不就是变幻无常的吗？

连波先生有点踌躇了，到底向前走呢？还是回过头来走，但去学校的路就此一条了。

连波先生仍是向前走，到底要看一看鬼是什么样，虽然那时候也怕了。

连波先生那时候有了一双回力鞋，鞋底还算厚实。连波先生决心快步走过去，等走到一公里处的人家户去，鬼就不敢追来了，鬼是不敢去人多的地方的。

连波先生就开始大步走了起来，大腿和大脑向着两个不同的方向。

连波先生走到鬼消失的地方时，那路边蹲着的白影噢的一声叫起来，随着就站起来，连波先生定眼看去，他却是个人。

连波先生说在他走过那段路时，他是害怕的，好像若那东西在上面布置好陷阱等他，自己反而会遭殃的，所以走的很快。

原来是个男子在路边蹲着屙屎。

连波先生说到这里就笑了起来。

“鬼也是要方便的，一方便就立刻变成人了。”

我想，倘若鬼是常常能遗矢也是好的，因为给了他一个作人的机会。

本文改编自「萧红 - 回忆鲁迅先生（节选）」。参考三遗矢.

文城

Thu, 23 Sep 2021 05:50:30 GMT

最近比较颓，晚上地下城游戏疲劳用完后，我躺在沙发上看起了仅剩一点的文城。

在看这本书前，我听过一期梁文道和余华老师的播客，从播客的内容上知道，这本书作者没有想要表达什么，也没有想要反应什么，只是叙事。少了写「活着」和「兄弟」时需要考虑反映什么，讽刺什么的压力。这本书在叙起事来，一如既往的游刃有余，或者可以说是听马行空。

书分为前后两半部分，前半部分主要讲林祥福；看完这部分后，总觉得差点什么，对结局也不是很满意，还有很多人物最后的去留也没交代清楚就草草结尾。后半部主要是讲小美，这部分从小美的视角把所有的事情都交待出来，看着看着感觉是一个爱情故事。直到小美冻死在雪地前，我都抱有一丝她见到了林祥福抱着女儿对她笑的场景；但很遗憾没有，作者不带一点儿拖泥带水的把她写死了，也有可能她选择冻死来逃避，一边是女儿和自己可能向往的生活，一边是自己的丈夫。林祥福看着小美的尸体从眼前抬过，死的人看不见，活的人也看不见；林祥福苦苦寻找了十多年的小美，直至他死后，也没能见上一面，他们之间隔的最近的距离，是田二兄弟抬着林祥福的尸体回家时，在小美的坟前歇息的距离。不到一米，但两个死了的人，看不见，活着的人，也看不见。余华老师真是把苦难和悲情写的淋淋尽致。

你要是还没看，就把它当作一个故事看就行了。不然要是曹雪芹老师醒过来，你还要问她什么时候出一部超越「红楼梦」的作品吗？其他莫多想，打个 7.2 分。

推荐你收听下面两期播客：

说一说公众号

Thu, 19 Aug 2021 05:37:06 GMT

很久就想写一篇公众号相关的感想了，刚好在推特上刷到了这条时间线，我就来简单写写；如果因此得罪了大佬们，请勿怪罪。因为我只是想谈谈写作这件事。

最近在学 Go，关注了很多国内的大佬，时间久了，就会发现这个社区太不健康了。有一些成长期很优质的博主，慢慢的就都往公号去了。你若翻看他们以前写的博客文章，还是能学到很多东西的。而现在好好的博客需要关注公号才能继续查看，公号的内容还要等几天才有可能同步到博客。而对于文章质量，一开大佬们可能花一两天写一篇文章，这是超级负责的，往往这样的文章也是有保证的。

慢慢的，你会发现文章质量越来越低，都是诸如什么你不知道系列，脱坑系列，xxx 技巧，吊打面试官，xxx 一篇就够了等等。而这类文章，看完后或许会豁然开朗，或许会轻哦一声，当时以为看到的知识都会了，而过几天就全忘了，因为这样的文章除了增加阅读量外，能吸收到的东西太少了。而也是这类文章，能吸引越来越多的关注，越来越多的关注促使作者更多写这类文章，周而复始，生生不息。再往后，作者开始转载别的工号的文章，开始相互推荐，开始接广告，朋友圈里极客时间的广告满天飞；而另人伤心的是不止一个作者这样，更另人伤心的是读者们都好像觉得这很正常。所以是作者们变了吗？或许是吧，也或许是环境变了吧。

我不喜欢被这样的事情所影响，所以从今年初开始，我取关了几乎所有的技术号，我不相信我错过的东西真的就那么有价值，我也不相信真的能用碎片时间从工号上学到什么新知识；如果要说真能学到，那应该是能把深奥的原理像讲故事一样讲出来的公众号，这方面我只知道 2018 年前的码农翻身。

我在社区认识一个很不错的小伙，还相赠了书，他送了我一本「Go 语言编程之旅」，我送了他一本 Go 专家编程。刚结识的时候，他正开了一个新的工众号，准备开始技术写作，而他今年的目标就是，公号有 500 个粉丝。现在看来，估计已经达到了，不得不说还是很腻害。我并不是想说在公号上写作有什么不好，而是很纳闷，我们写作到底是为了什么，是为了涨粉为了出名，还是写作本身？若一开始就是想好了靠写作公号张粉，涨粉后变现；那写作本身反到变的不重要了。因为涨粉的方式有很多，好的内容，亦或好的技巧；如公号互推、相互装载、各种微信群等。当你把技巧运用的越来越熟练后，你就偏离写作越来越远了。但若你只是把粉丝数作为衡量自己文章质量的一个标准，那也是很令人赞叹的；令人伤心的是，就目前的情况看，大家都更愿意去提升涨粉的技巧，而不是文章内容本身。

还有一个大佬，相信国内的 Go 语言开发者都看过他的博客，其中的「Go 语言设计与实现」系列更是经典，他就是面向信仰编程的作者 Draven。如果你看过他的博客文章，你会发现每一篇都很硬核，有理有据，这才是技术博客应有的样子。他也有同名的公众号，翻翻历史你会发现里面一篇水文一篇广告都没有。更让人愉悦的事，作者先是有了博客，博客人气很旺，文章老是被转载后才开通的公号（参考2019 年总结）；更难得可贵的是，即使作者公众号粉丝数超过 2w（参考2020 年总结），他依然保持初心，从不恰饭，要知道如果按一块钱一个阅读量算，随随便便一篇水文，也是好几千啊。保持初心，不忘始终，这才是值得我们学习的最佳案例呀。

说了这么多，并不是说用公众号写作的就不好，而是更想让大家知道，你究竟为什么而写作？愿你我能在正确的道路上，持之以恒。

为什么我们需要数据库事务

Tue, 03 Aug 2021 07:41:41 GMT

日常工作中我们可能会遇到如下的问题，在未引入数据库事务这一特性前，应用程序在处理这些问题时总显得过于复杂，如：

数据库在写入一半数据时崩溃
订单数据保存一半后网络链接中断
多个客户端可能会同时写入数据库
多个客户端之间的条件竞争可能会扰乱整个应用程序

而事务一直是简化这些问题的首选机制。他为上层应用程序提供一个可靠性保障：将多个读写操作组合成一个逻辑单元来执行，要么全部成功，要么全部失败。应用程序在处理这些问题时将不再关心一半成功一半失败的情况，也不再拘泥于下层各种不可靠的系统，因为大多数数据库系统都会从多个维度（事务的ACID）来保证数据的正确性。

计算机发展到今天，我们一直在不可靠的环境中构建可靠的系统。

事务的 ACID

ACID 并不是什么高大上的术语；而是数据库系统在实现事务时为保证其正确可靠而必须满足的几个约束，不同的约束提供了不同的保障。

Atomicity（原子性）

原子性并不是指把事务当作一个整体来运行，既运行过程中不可中断、不可切换；而是指事务再遇到出错时，能终止事务，丢弃该事务的所有变更。事务一旦终止，实现这一特性的数据库会保证数据恢复到原始状态，应用程序不在担心各种可能存在的中间结果，只用专注于处理成功或失败两种状态。

Consistency（一致性）

一致性主要是指数据状态的一致性，考虑这样一个例子：从 A 账户转入 100 元到 B 账户，最终的一致性状态是指 A 账户的支出和 B 账户的收入达到收支平衡。

而在 DDIA 这一书里，作者认为一致性是应用程序的属性，不应该由数据库来实现。拿上面例子来说，账户 A 转出 100 元但由于程序问题账户 B 却收入 200 元，虽然最终状态是收支不平衡，但这并不影响数据库会按正确的方式来保存这些数据。状态是否一致的判断，应该交由应用程序去处理，数据库系统只会正确的保存你给他的所有数据，而不会关心数据本身（参考 ACID 中的 C 是被扔进去拼凑的单词）。

Isolation（隔离性）

当多个 client 同时操作同一数据时，就可能会出现并发问题（race conitions）。事务的隔离性要求并发执行的事务之间互不干扰，如果在一个事务中进行多次写入，则另一个事务要么看到她全部写入结果，要么什么都看不到。

下面的例子就不满足事务的隔离性：User1 先后进行了两次写入，在她未提交前，User1 读取到了部分新增的数据。

图 1.0 违反隔离性：一个事务读取另一个事务的未提交的写入

为什么不能读取一个事务未提交的写入？是因为一个未提交的写入，其后续可能会被终止，终止后该事务的所有写入都会被回滚；若一个事务读取到了另一个事务未提交的变更，而该事务回滚后，程序将得到一个完全不应该存在的值。

Durability（持久性）

事务的持久性是一个承诺，即一旦事务成功提交，即使发生硬件故障或数据库崩溃，写入的数据也不会丢失。

这只是一个美好性承诺，我们小心翼翼地祈祷不会出现如硬盘被偷、文件损坏等故障导致的数据丢失。虽然这有点杞人忧天，不过也说明了并不存在绝对 100% 的保证。

事务的隔离级别

为了简化应用程序在面对并发时的各种问题，大部分关系型数据库都提供了不同的隔离级别。隔离级别并不是一个什么高深的概率，只是数据库系统在简化并发问题时的抽象。不同的隔离级别对应不同的保障，保障系数越高，相应的性能就越低。在选择不同的隔离级别前，我们应该思考该隔离级别提供了什么样的保障？相同的代码在不同的隔离级别下可能会存在什么问题？不同的隔离级别可能会带来什么问题？而不是一味为了应付面试而了解的诸如脏读、幻读、不可重复读、MVCC 等抽象的概念。

Read Committed

正如名字一样，在 Read Committed（读已提交）隔离级别下，一个事务只能读取已提交的数据（对照上面隔离性时的例子）。如下面的例子中，在 User1 未提交前，User2 前两次读取的结果都相同，而当 User1 提交后，User2 就能读取到提交后的数据。

图 2.0 Read Committed User2 在 User1 提交后才能看到新值

Read Committed 的实现

Read Committed 是 Oracle 11g、PostgreSQL 的默认隔离级别，通常采用加锁来防止并发写入（写写）。一个事务在尝试更新（写入）对象时，必须先获得该对象的锁，同一时刻只能有一个事务持有该对象的锁，未获得锁的事务需要一直等待，直到持有锁的事务提交或终止。此种方式相当于将两个并发写请求通过加锁的方式串联起来，使得同一时刻最多只允许一个事务进行写入，也就不会存在数据竞争等情况。

几乎所有的数据库系统都允许多个事务并发读取（读读），并发读取数据时并不会对资源加锁，在 Read Committed 和快照隔离级别下，写操作也不会柱塞读操作。

若存在读写并发时（读写），写操作的事务会记录所操作资源的两个版本，一个是原始值，一个是修改后的新值；读事务写事务提交前，都只能读取到原始值，而看不到新值。只有当写事务提交后，读事务才能读取到他提交后的新值。

如图 2.1 所示，写操作把 ID 为 1 的记录从 18 更新到 28，但未提交；其内部可以简单的理解为有一个指向上一个版本的「链接」，通过这个「链接」就能获取上一次已提交的值。读操作在检索到这一对象时(where id = 1)，由于最新值 28 是 UnCommitted，将通过「链接」获取上一次已提交的值作为查询的返回值，既返回 18。

**图 2.1 Read Committed **

通过这种方式，Read Committed 就能保障读取到的数据，一定是已经提交了的。

Read Committed 带来的问题

Read Committed 相较于其他隔离级别，不但提供了较好的性能，并且能够满足绝大多数的应用场景，但这并不代表它就是完美的。如下面的例子，在一个事务中，程序筛选满足条件的记录数量，若数量大于 0，再获取相应的数据集合，并返回记录条数和数据集本身。

考虑到当事务执行完第一个查询条件后，另外的事务新增了几条数据并提交，由于在 Read Committed 隔离级别下，事务能读取到另一事物已提交的更新，这将导致后面一次查询出来的数据集条数和第一次查询的 count 不匹配（不可重复读问题）。

start transaction;
count = select count(1) from t where foo = bar

if count > 0 {
    return {
        count,
        datas: select x from t where foo = bar
    }
}
commit;

Read Committed 认为这种问题是可以被接受的，也没打算解决这一问题；因为当你重新执行一遍事务，你可能会得到正确的数据。

Snapshot Isolation（快照隔离）

快照隔离（Snapshot Isolation）相比于 Read Committed 提供了更严谨的保障，在 Read Committed 的基础上，还能解决上述的不可重复读现象。这也是 MySQL InnoDB 的默认隔离级别，在 MySQL 中快照隔离被称为可重复读(repeatable read)，其名字在不同的数据库系统实现中有不同的叫法，我们只需要知道其具体原理即可。

Snapshot Isolation 的实现

快照隔离在处理多事务并发写入（写写）和多事务并发读取（读读）时，采用与 Read Committed 一样的机制，既允许「读与读」并发而「写与写」互斥。参考 [Read Committed 的实现](Read Committed 的实现)。

在处理多事务并发读写时（读写），不同于 Read Committed，快照隔离通常会保留所操作资源的多个版本，并在每个版本中记录更新数据时的事务 ID（事务 ID 在事务开始时由数据库系统分配，通常是单调递增的）。如图 3.0 所示，记录了 ID 为 1 的数据更新历史，其值先后被更新为 0 -> 6 -> 15 -> 18 -> 28，其事务 ID 依次为 1、3、5、7、9；最后一次更新操作暂未提交。

图 3.0 多版本控制

读操作在读取数据时，会过滤事务 ID 大于自身的版本。假设有一个读事务正在读取 ID 为 1 的这条记录，其 txid 为 6，由于程序运行较慢，该记录已经向前提交了两个版本，既上图的 txid 为 7、9 的两次提交；则读操作在查询时，只会获取 txid<=6 并且已提交的版本作为查询的返回值，所以查询将返回 {txid:5, value: 15}。

通过这个机制，事务在整个生命周期内进行的多次查询，都将使用同一个版本的数据，即使查询的对象已经提交了多个版本，查询时都将使用事务开始时的数据。相当于在事务启动的时候就生成了一个一致性快照，但这个快照并不是一个数据备份，其并没有 Copy 数据的开销，而是在运行时通过 txid 动态计算的不同版本。

Snapshot Isolation 带来的问题

快照隔离和 Read Committed 都通过「写与写互斥」来解决多事务并发写入的问题，但在某些场景下这种方式并不能保障数据的正确性，其中最主要的就是丢失更新问题（Lost Update）。

如图 3.1，两个并发请求开始读取到的 counter 都是 42，应用程序将值自增后在更新到数据库，最后保存的结果却为 42，User1 的更新被覆盖了。

图 3.1 Lost Update

更新丢失准确来说不算是数据库的问题，也不应该要求数据库做出这方面的保障，毕竟数据库在保存数据时，并不知道数据本身的合法性。通常，更新丢失有以下几种解决办法：

原子写

update t set count = count + 1 where id = 1

排它锁（FOR UPDATE）

通过在 SQL 语句后面指定 FOR UPDATE 来锁定查询条件返回的记录数，在事务未提交期间，其他查询&写入必须等待。

start
select count from t where id = 1 for update

count ++
update t set count = count where id = 1

commmit

Serializable

最后一种隔离级别是可序列化，可序列化隔离通常被认为是最强的隔离级别。他将多个并发执行的事务串行化，一个事务必须等待之前的任务处理完成后才能接着处理。这种隔离级别可以防止所有可能的竞争条件。

Serializable 的实现

Serializable 通常采用两阶段锁（two-phase locking，2PL）的方式来实现。他允许多事务并发读取，既读与读之间互不干涉。但如果要对某一对象进行写入时，需要等待该对象上的所有读&写事务完成后，才能写入；如果要对写入的对象进行读取时，需要等待写入事务提交或终止后，才能读取。

Serializable 带来的问题

由于两阶段锁在遇到写操作时，都会对资源进行加锁，并且写操作还会柱塞读操作。所以 Serializable 带来的性能十分低下。并且还可能会发生死锁和写放大等现象，毕竟在生产环境中，当其中一个服务读写变慢时，他就有可能会拖坏整个应用的吞吐率，并逐渐扩大至整个程序不可用。这也是 Serializable 即使提供了更好的隔离级别却很少使用的原因。

总结

数据库事务为我们提供了一个良好的抽象，让开发人员不在担心各种不可靠的环境，不在关心各种模凌两可的状态。有一点需要知道，事务不是天然存在的，我们不要想当然的以为他能够处理好所有的问题，而不考虑他在不同场景下可能带来的影响。

虽然文章标题叫做「为什么我们需要数据库事务」，但其实作者大部分篇幅都在写隔离级别，因为我发现再解释完为什么后，还需要接着解释 Why，那姑且就这样吧。如果你觉得文章对你有帮助，你也可以订阅作者的博客 RSS 或直接访问作者博客二愣的闲谈杂鱼。

参考

人的一生应该怎样度过

Thu, 03 Jun 2021 03:22:32 GMT

今天突然发现我还有个 wordpress 站点，进去看才发现不知什么时候写了这样的一篇。原文发布于 2016-07，这应该是在中移物联网的时候写下的，现把他搬到我的博客。

从毕业到现在差不多快一年了，现在的我在一家二流公司里做一个 codeer。团队大于有 20 人左右，我只是其中的一个小角色，默默的编着码，时不时问问一些特别弱智的问题，虽然坐的位置还算显眼，然而这并没有什么卵用，你在还是走都不会跟团队造成任何影响；相当于工地上的小工。而不论是生活中还是工作上，我都不喜欢表露，宁愿自己一个人呆着，也不愿去和别人谈天谈地，十足的内向。虽然也毕业一年了，但不管是思想上还是这张脸，都写着幼稚两大字。社会经验不足，社会技能不足，不爱交流，还爱幻想，我真的是受够我自己了，这样的我还一天老谈人的一生应该怎样度过，真的是日乐购了。

记得在大学 4210 教室听毕业宣传大会的时候，我还在和永智谈体制化，然而那就是谈谈而已；现在的我已经被体制给化了，每天傻逼似的上班下班，出门前天才亮，回家天都黑了，还一天自以为是的以为过得很充足，还以为这样下去就能像柯察金一样，“他不因虚度年华而悔恨”。于是我开始不满这个社会，不满这个国家，我不满他没有给我后盾，不满他让我每个月的五号都在计算：还了信用卡还有 3000，除去 1500 的生活费还剩 1500，再存 1000 块钱 …. 。还傻逼似的以为这样下去生活会愈来愈好的，然而我就连房租都交不起，我还要怎么像柯察金一样为人类的伟大胜利而奋斗终生。。醒醒吧，你又在信用卡上刷了 50 块钱去买菜了。

今天看到我老家邻居（同龄人，初中辍学/包公头）回家开始修房子了，我又开始慌了，读了这么多年的书，终究还是要和钱过得去。别人的孩子初中毕业就出去鬼混了，现在回到家，修了一个窝，就近找了点事，能照顾父母，能安度余生，可怜的连波还在重庆花 800 块钱租着房子，更不奢求照顾自己年迈的父母了。有时候就在想，城市里生活和乡下生活到底差了什么呢，为什么我要拼了命的往城市里钻。

这就是你的生活，连波。

搬出路遥来安慰安慰我吧，

生活就是这样，不能让人处处满意，但我们还要热情的生活下去，人活一生，值得爱的东西很多，不要因为一个不满意，就灰心。

可以看到当时的情绪还是挺激动的；刚毕业那年，我欠下了很多信用卡，大约 1W 左右，后面陆陆续续花了一年才还完。而又看到小时候的玩伴初中未毕业就外出务工，现在「混」得有模有样的，心理难免有点失落。现在看来才发现书上说的都对：当他回首往事时，他不因虚度年华而悔恨，也不因碌碌无为而羞耻。

三体

Thu, 20 May 2021 09:53:37 GMT

这本书已经在家里的客厅躺了一两个月了，最后的一小部分的内容终于在公司摸鱼中看完了。整体评价的话，第二部最好看，其次是第一部，最差是第三部。

最喜欢的内容来自第一部；在三体世界用智子封锁死地球的基础科学并大举侵犯的前提下，两位科学及汪淼和丁仪陷入了深深的绝望和等死。

你带我们来这儿干什么？汪淼问。

看虫子。大史点上一支斯坦顿上校送的雪茄说，同时用雪茄指指面前的麦田。

汪淼和丁仪这才发现，田野被厚厚的一层蝗虫覆盖了，每根麦秆上都爬了好几只，地面上，更多的蝗虫在蠕动着，看去像是一种黏稠的液体。

这地方也有蝗灾了？汪淼赶走田埂一小片地上的蝗虫，坐了下来。

像沙尘暴一样，十年前就有了，不过今年最厉害。

那又怎么样？大史，什么都无所谓了。丁仪带着未消的醉意说。

我只想请二位想一个问题：是地球人与三体人的技术水平差距大呢，还是蝗虫与咱们人的技术水平差距大？

看看吧，这就是虫子，它们的技术与我们的差距，远大于我们与三体文明的差距。人类竭尽全力消灭它们，用尽各种毒剂，用飞机喷撒，引进和培养它们的天敌，搜寻并毁掉它们的卵，用基因改造使它们绝育；用火烧它们，用水淹它们，每个家庭都有对付它们的灭害灵，每个办公桌下都有像苍蝇拍这种击杀它们的武器……这场漫长的战争伴随着整个人类文明，现在仍然胜负未定，虫子并没有被灭绝，它们照样傲行于天地之间，它们的数量也并不比人类出现前少。

虫子从来就没有被真正战胜过。

当我看到这里的时候，十分震惊。是啊，就算比你再优秀的人，也不是可望不可及的；只要你在一点点的进步，终将会像虫子一样傲行于天地之间。

我是如何走向技术这条路的

Mon, 17 May 2021 06:11:42 GMT

2011 年 9 月，在姐姐的陪同下，我来到了隔壁山城——重庆，准备入学报道。那是作者第一次离省。

从家乡的小县城出发，坐上早上发往重庆的大班车，在来来回回的在山路上开了 4、5 个小时，接近正午时，班车停在了菜园坝长途汽车站。车站看起来一点也不像繁华都市应有的样子，普遍不高的建筑物加上到处吆喝的小贩，给我一种从一个县城到达另一个县城的错觉；但当我前脚刚跨下大巴后，一股热浪带着风被我吸来，我第一次体会到了山城的热情。出发前爸妈说的原来是真的，重庆是一座火城。

记得在高三教学楼一楼电脑室填完高考志愿出来后，我还不知道所选的计算机专业会有怎么样的就业前景；当时听同学说计算机是红牌专业，也不知道这是危险还是火热的意思。比起那些选学校选专业有老师参谋家长建议的同学来说，我是幸运的；所有的一切，我自己说了算；爸妈也没法给我任何类型的帮助，在他们看来，能考上师范大学就心满意足了。但他们不知道的是，我不想呆在本省，我不想小学、初中、高中、大学都呆被困在同一个省，这样很大概率我毕业后还得留在这里，我想去外面看看；但碍于自己的软弱，又不想离家太远，就只敢选择于川渝之间，别的太远，一是不想去，而是钱不够。

高中时期我也算得上一个优等生，在县重点中学最高排名能挤进年级前 50。而到了大学后，作业靠抄，考试靠蒙，连体育也能挂科，活生生坠落成一个狗样。除了上课，大部分时间都在玩游戏，从 CF(穿越火线)、DNF(地下城与勇士)到 LOL(英雄联盟)；中午玩几把再睡、下午从课后玩到晚上、晚上玩到断网，甚至断网了还要来几把单机 CS，不放过任何可以游戏的时间。

这样浑浑噩噩过了三年，直到大四上学期，校方「勾结」某培训机构来学校免费讲课，主要是讲 Java EE。培训机构也真会挑时间：大四这一年，基本没得课程安排，大部分同学都会离校参加社会实习；但是前面三年都在游戏中度过的我们，根本没有任何资本找到实习工作；少有学的好的同学，也只停留学校传授的粗枝烂叶上；所以培训机构这时候进场，自然而然给大家提供了另一个选择。

机构老师讲的，很大不同于大学教授；机构老师讲的是实实在在的东西，诸如环境变量的搭建，Eclipse 的使用，如何用 Servlet/JSP 开发网页等；不但听得明白，下课后还能自己动手试错；而大学老师所教的，三年过去了我都不知道教的是什么。和大部分学校一样，计算机专业的学生首次接触的基本都是 C 语言，教材是那本误人子弟的谭浩强版；不但老师讲得云里雾里，教材上的知识也牛头不对马嘴。一般上三四节理论课，再上一节实验课，理论课上讲语法，实验课让你上机运行。作者深深记得第一次 C 语言上机课时，在集成环境中写完 Hello World 后输出一段文字后的无助；这能干什么，这他妈有什么用？完全找不到任何乐趣所言。还不如后面选修的《网页设计》，在这门课上，我第一次知道原来将一个 .txt 文件改为 .html 文件后，就能直接用浏览器查看效果了，并且还可以通过 H1，H2 及一些简单的 CSS 来控制样式。

一个多月后，培训机构带走了同寝室的两个小伙伴，剩下三个伙伴中，肉杰已经找到了工作，就在学校附近的一家大公司，偏向市场方向；鸟是我们寝室技术最好的，已在学校附近找到了 Java 实习，月薪 2K。只剩下一个我，空气瞬间安静了下来。有时候早上一觉醒来，寝室里一个人都没有，我坐在床上一手抓头发一手抓着床边的栏杆，望着正前方的门发呆。我不知道干什么，我好压抑，我想找人说话，我真想大吼一声。我变成了那种明知在浪费青春而又无能为力的废人。我一刻也不想呆在寝室，游戏也不愿意打了，有时候带着本书，在图书馆看一早，有时候在后校门租个自行车，漫无目的的游荡着；有一次骑到了一个小村里，拐上右手边的一个山坡，上面有户人家，旁边有个鱼塘，鱼塘里有一些荷花；我看了看鱼塘，又看了看路上背着背篼的行人，又倒回来回校了。我也不知道我在追求什么。

一连好几天，我都漫无目的的过着。鸟中午休息的时候会回学校，看到毫无斗志的我，告诉我不能再这样颓废下去，问我要不要学学 Java，并发了一套朴乾老师的 Java Web 视频给我，让我跟着学；到这一刻，我都不知道我接下来的人生是怎样的，我设想过无法的可能，可能在某个公司干着可有可无的工作，可能在工地搬砖，可能永远都是能被无成本替换的那一批。

从那天起，我早上 7 点起来开始看视频，有时候快到吃午饭了，才去洗漱。中午去食堂吃完饭回来后肯定要打一局游戏，不过已经开始克制只打一局。然后午休，1.30 左右鸟去上班了，我又起来看视频，看到下午饭点快到了，再去吃饭，吃完饭回来免不了的又要打两把游戏，接着又开始看视频，看到晚上 10.30 左右。这时肉杰才提着公文包醉轩轩的回来。

就这样修炼一个月后，我开始投简历了。很庆幸，就第二天收到了一家公司的面试邀请。这家公司位于渝中区鹅岭公园附近，随着电梯的层层上升，我越来越激动起来。这是我第一次面试。和前台简单聊了几句后，面试官出现了，结结巴巴的自我介绍结束后，面试官问了一些很简单的技术问题，我回答得都还不错；接着我被推进到下一流程，一个 HR 小姐姐走了过来；她开始向我说起了公司的企业文化，福利待遇，职业发展，就业空间；并告诉我因为你的基础不扎实，需要进行六个月的岗前培训，培训期间无费用，但得从六个月转正后的薪资里扣除。我耐心的听她慢慢讲完，并没有任何疑问后，HR 小姐姐给了我一张表让我填写，我拿着那表就笑了。除了名字一栏填写真实的外，其他的我都在乱写；正好旁边有个朋友也在填表，我问他你也是来面试的吗？得到他肯定的答复后我告诉他：这家是外包公司，不要听他们的和他们签合同。小哥半信半疑的看着我，说完我把填好的表交给前台，头也不回的走了，身后传来前台姐姐「等等，还没结束」的声音，我并没有理他。下楼后，我看到一个背着书包的小孩，那一刻我竟然无比的开心。

回到学校后，慢慢又开始烦躁起来了，天真的我才发现，事情并没那么简单；视频是看完了，自认为学的也差不多了，也投了那么多简历，但就是收不到面试邀请；曾以为学完了就能顺顺利利的找到实习，但事总与愿违；而面试受挫加简历石沉大海，使我无心学习越发烦躁；一星期后我选择收拾行李回家看看，在心里仿佛有声音告诉我，即使再难的不知所措，回家后都能又见一春。我拖上了零几年老爸打工带回来的红色小拉箱，去往菜园坝汽车站坐车。在菜园坝车站附近花 60 块找了个旅社，被吆喝住宿的阿姨带着爬上一个狭小的楼梯，再穿过一个五块钱灯光的走廊，走廊尽头左手边第一间单间正在那静静等着它的新主人。房间四周无窗，空气弥漫着一股精液腐烂的味道，灯开后，才能看到门前有一张小桌子，左手边有一张床，床上铺了一个两边已经坏掉的凉席，感觉一米五的凉席只有中间一米可用，床上的被子凌乱的躺在床尾，让我想到一句诗描述的那样：布衾多年冷似铁，娇儿恶卧踏里裂。

我坐在床上，开着门，让风尽量的多进来一些。不一会我接到一个电话，天极传媒邀请我明天参加面试；接完电话的我长舒一口气，要是这电话晚一天打来，我就已经在回家的路上了。听隔壁传来的阵阵呻吟声，我在期待着明天的面试。

面试当天就结束了，问得都比较简单，实习月薪 2000，两天后上班。在这里，一开始面试我的面试官成了我的恩师，后来他告诉我，你其实是技术最菜的那一个，但在你身上我看到了年轻时的样子。我也不知道老师年轻的时候是什么样子，可能是那稚嫩的脸上表现出的阳光和对新知识的向往吧。从那时候起，我算是真正踏上了技术这条路。而时隔五六年后，我依然没能企及老师的高度。

这就是我的入职经历，每个人都有他自己的故事，我的故事并不有趣，也不励志，但我愿意把他写出来，你的呢？

老丈人的三轮车🛺

Thu, 06 May 2021 02:40:42 GMT

老丈人有一辆三轮车 🛺，每次不开车回去时，我都能坐上老丈人的三轮车。以前，我和阿宝会在镇上下大巴 🚌，老丈人就从家开着三轮车来接我们。阿宝坐在前面——和老司机坐在一起，不知道在和他老爹嘀咕些什么。我坐在三轮车后面的车厢里。天气好的时候，我在后面还可以站起来，一只手比着向前进的动作，像老毛阅兵一样，俯视着自己的大好河山，就差喊一句同志们辛苦了；一只手牢牢抓住车边儿上的栏杆；下坡的时候，老丈人像没踩刹车一样，轰隆隆的任凭车滑下去，我就得把另外一只问候同志们好的手收回来，死死抓住边儿上的栏杆。而天气不好的时候，我就得坐在老丈人准备的小凳子上，一只手抓着栏杆，一只手打着伞。伞不能打太高了，不然要被吹翻；也不能太低了，不然脖子淤着不好受。我不喜欢打伞，打伞后我就不能看到沿途的风景了。

老丈人的三轮车是油点混合的，动力非常强劲；回去的路上开始很平稳，用电动方式就能载得动我们仨呢；而后面有一段坡度很陡的路，每次走到这里的时候，老丈人就会停下来，让站在车厢里的我把油门打开；然后老丈人切换为油模式，轰轰轰的发动机始转动，载着我们一点点的往坡上爬；如果旁边恰好有过路的行人，你会发现他走的居然比我们还快。我站在后面提心吊胆的，为了重心前移，还不得不半个身子往前倾，生怕爬到一半爬不上去而倒退。

老丈人家了养了三只狗，一只黑儿 🐕‍🦺，一只黄标 🐕，一只好像没得名字，就暂且叫他大白吧 🐩。每当老丈人要开车外出时，这三狗子就会追着车子一起走。其中尤其黑儿跑得最快，走的最远。以前黄标和大白都不追车的，只有黑儿，老丈人开车去哪里，他就跟着去哪里，不管多远的路程。有时候会被路上的其他狗一直追一只咬，黑儿就夹着尾巴使劲儿跑；有时候泡在三轮车后面、有时候跑在前面、有时候又跑在轮子附近；赢得老丈人一句「狗日的黑儿，你走开点」。

我喜欢这样的生活，

老丈人系列

Laravel Octane 初体验

Thu, 29 Apr 2021 09:51:32 GMT

Laravel Octane 已经发布好几周了，虽说目前还处于 beta 状态，也挡不住开发者对他的热爱，一个月不到，其在 GitHub 的 star 数量已超过 2K；部分开发者已将他们的项目运行在 Laravel Octane 之上。

如果你还在观望，也可等等~~一两周后的稳定版~~ I’ve tagged Laravel Octane 1.0 - Taylor Otwell。

We will likely go ahead and tag Octane 1.0 as stable next week @Taylor Otwell on Twitter.

为了体验一把加速的魔力，作者已拿一个简单的 H5 项目在生产环境下试了试水，除了一些乱七八糟的问题，其他的都令作者激动不已，客户还表示我们的平台好快啊，下次还找你。

Laravel Octane 的组成

Laravel Octane 内置了两个高性能的应用服务：Swoole 和 RoadRunner，正如官方文档介绍的：

Octane boots your application once, keeps it in memory, and then feeds it requests at supersonic speeds.

我们知道，Laravel 框架一直很优秀，但是他在性能方面却一直为人诟病。框架的 boot 时间可能比业务处理时间还长，并且随着项目第三方 service provider 的增多，其启动速度越来越不受控。而 Laravel Octane 则通过启动 Application 一次，常驻内存的方式来加速我们的应用。

Laravel Octane 需要 PHP8.0 支持，如果你是在 macOS 下工作，你可以参考这篇文章来更新你的 PHP 版本 Upgrade to PHP 8 with Homebrew on Mac。

Octane 简单示列

虽说官方文档已经描述的很详细，不过作者这里还是通过一个简单的示列项目来演示。

Create Laravel Application

➜ laravel new laravel-octane-test

 _                               _
| |                             | |
| |     __ _ _ __ __ ___   _____| |
| |    / _` | '__/ _` \ \ / / _ \ |
| |___| (_| | | | (_| |\ V /  __/ |
|______\__,_|_|  \__,_| \_/ \___|_|

Creating a "laravel/laravel" project at "./laravel-octane-test"
Installing laravel/laravel (v8.5.16)
...
Application ready! Build something amazing.

Install Laravel Octane

$ composer require laravel/octane

安装成功后，读者可以直接执行 artisan octane:install 来安装依赖；Octane 将提示你想使用的 server 类型。

➜ php artisan octane:install

 Which application server you would like to use?:
  [0] roadrunner
  [1] swoole
 >

如果你选择的是 RoadRunner，程序将会自动帮你安装 RoadRunner 所需的依赖；而如果你选择的是 Swoole，你只需要确保你已经手动安装了 PHP swoole 扩展。

使用 RoadRunner Server

RoadRunner 的使用过程不尽人意，作者在安装过程中总会出现一些官方文档忽视的错误。

下载 rr 可执行文件失败

在执行 octane:install 安装 RoadRunner 依赖时，作者本机根本无法通过 GitHub 下载 rr 可执行文件，提示的错误如下：

In CommonResponseTrait.php line 178:

HTTP/2 403  returned for "https://api.github.com/repos/spiral/roadrunner-binary/releases?page=1".

如果你也遇到了这样的错误，建议直接去 RoadRunner 官网下载对应平台的 rr 可执行文件及 .rr.yaml 配置文件并放到项目根目录。如 macOS 平台的可执行文件及配置文件地址：

最后记得修改 rr 的可执行权限及 RoadRunner 的 Worker starting command。

chmod +x ./rr

server:
  # Worker starting command, with any required arguments.
  #
  # This option is required.
  command: "php artisan octane:start --server=roadrunner --host=127.0.0.1 --port=8000"

ssl_valid: key file ‘/ssl/server.key’ does not exists

RoadRunner 的配置文件中，默认开启了 ssl 配置，若你不需要启用 https 访问，可注释 http.ssl 配置。

Error while dialing dial tcp 127.0.0.1:7233

RoadRunner 默认开启 temporal 特性，其 listen 端口为 7233，若你不想启用该特性，可注释 temporal 配置。

# Drop this section for temporal feature disabling.
temporal:

关于 temporal 的信息可查看官网 temporalio/sdk-php: Temporal PHP SDK

Executable file not found in $PATH

这种情况一般是配置文件中未制定程序执行路径，请检查以下配置。

Server.command

修改为 RoadRunner worker 的启动命令，如：

php artisan octane:start —server=roadrunner —host=127.0.0.1 —port=8000

Service.some_service_*.comment

如果你不想使用该特性，注释该配置。至此，作者的 RoadRunner 终于启动起来了。

AB Test For RoadRunner

作者用自己的笔记本(2018-13inch/2.3GHz/16GB)做了一个简单的 AB Test，框架代码未做任何改动，为 Laravel 默认的 welcome 页面。

经过改变不同的并发参数和请求数，得到的结果都如下图所示上下轻微波动，其 QPS 基本维持在 230/s 左右。

➜  ~ ab -n 2000 -c 8 http://127.0.0.1:8000/
Server Software:
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /
Document Length:        17490 bytes

Concurrency Level:      8
Time taken for tests:   8.418 seconds
Complete requests:      2000
Failed requests:        0
Total transferred:      37042000 bytes
HTML transferred:       34980000 bytes
Requests per second:    237.59 [#/sec] (mean)
Time per request:       33.671 [ms] (mean)
Time per request:       4.209 [ms] (mean, across all concurrent requests)
Transfer rate:          4297.28 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        3   11   4.6     11      29
Processing:     3   20  34.8     15     270
Waiting:        3   18  34.8     12     270
Total:          7   31  35.2     25     284

默认情况下，Laravel 的 welcome 页面会先经过 web 中间件，最后在渲染 blade 页面；而 web 中间件包含大量 Cookie 和 Session 操作：

protected $middlewareGroups = [
    'web' => [
        \App\Http\Middleware\EncryptCookies::class,
        \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
        \Illuminate\Session\Middleware\StartSession::class,
        \Illuminate\View\Middleware\ShareErrorsFromSession::class,
        \App\Http\Middleware\VerifyCsrfToken::class,
        \Illuminate\Routing\Middleware\SubstituteBindings::class,
    ],
];

所以作者重新定义了一个测试路由，该路由不包含任何中间件（全局除外），并只输出一个 Hello World。

// RouteServiceProvider.php
public function boot()
{
    require base_path('routes/test.php');
}
 
// test.php
Route::get('/_test', function () {
    return 'Hello World';
});

再次测试后如下，可以看到其 QPS 已经达到官方宣传标准 2300/s（难道官方测试也是这样 Remove All Middleware?）。

$ ab -n 2000 -c 8 http://127.0.0.1:8000/_test

Server Software:
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /_test
Document Length:        11 bytes

Concurrency Level:      8
Time taken for tests:   0.867 seconds
Complete requests:      2000
Failed requests:        0
Total transferred:      374000 bytes
HTML transferred:       22000 bytes
Requests per second:    2307.81 [#/sec] (mean)
Time per request:       3.466 [ms] (mean)
Time per request:       0.433 [ms] (mean, across all concurrent requests)
Transfer rate:          421.45 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       3
Processing:     1    3   8.8      2     143
Waiting:        1    3   8.8      2     142
Total:          1    3   8.8      2     143

上述测试过程中，作者本机的资源限制如下。

~ ulimit -n
256

使用 Swoole Server

Swoole server 的使用就要顺畅多了；通过 pecl 安装好 PHP swoole 扩展后，无需任何配置就能启动。

AB Test For Swoole Server

作者用同样的配置对 swoole server 进行 AB Test，结果如下，其 QPS 也基本维持在 230/s 左右。

$ ab -n 2000 -c 8 http://127.0.0.1:8000/_test

Server Software:        swoole-http-server
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /
Document Length:        17503 bytes

Concurrency Level:      8
Time taken for tests:   8.398 seconds
Complete requests:      2000
Failed requests:        0
Total transferred:      37130000 bytes
HTML transferred:       35006000 bytes
Requests per second:    238.15 [#/sec] (mean)
Time per request:       33.592 [ms] (mean)
Time per request:       4.199 [ms] (mean, across all concurrent requests)
Transfer rate:          4317.61 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        3   11   6.6     10     102
Processing:     4   20  50.3     12     442
Waiting:        2   18  50.3     11     441
Total:          7   30  50.9     23     450

无中间件路由测试结果如下，可以看到其 QPS 已达到了 1650/s。

$ ab -n 2000 -c 8 http://127.0.0.1:8000/_test

Server Software:        swoole-http-server
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /_test
Document Length:        21 bytes

Concurrency Level:      8
Time taken for tests:   1.212 seconds
Complete requests:      2000
Failed requests:        0
Total transferred:      528000 bytes
HTML transferred:       42000 bytes
Requests per second:    1650.63 [#/sec] (mean)
Time per request:       4.847 [ms] (mean)
Time per request:       0.606 [ms] (mean, across all concurrent requests)
Transfer rate:          425.55 [Kbytes/sec] received

从 AB Test 结果来看，两种 Server 的性能基本持平；但由于是在本地开发环境测试，未考虑到的因素较多，测试结果仅供参考。

部署上线

Laravel Octane 虽然提供了 start 命令用于启动 Server，但该命令只能在前台运行（不支持 -d）；在部署到生产环境时，常见的办法还是利用 Supervisor 来进行进程管理。读者可以参考 Laravel Sail 的 Supervisor 配置。

[program:php]
command=/usr/bin/php -d variables_order=EGPCS /var/www/html/artisan serve --host=127.0.0.1 --port=80
user=sail
environment=LARAVEL_SAIL="1"
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0

后续持续交付时，可通过 Jenkins 连接到服务节点，使用 octane:reload 命令重新加载服务。

stage("部署 ${ip}") {
    withCredentials([sshUserPrivateKey(credentialsId: env.HOST_CRED, keyFileVariable: 'identity')]) {
        remote.user = "${env.HOST_USER}"
        remote.identityFile = identity
        sshCommand remote: remote, command: "php artisan config:cache && php artisan route:cache && php artisan octane:reload"
    }
}

不过这里需要注意的是，当你更新了 Composer 依赖，如新增了一个第三方包时，你最好在生产环境重启下 Laravel Octane。

sudo supervisorctl -c /etx/supervisorctl.conf restart program:php

否则可能会出现如 Class “Godruoyi\Snowflake\Snowflake” not found 的错误。

Laravel Octane 是线程安全的吗？

在回答这个问题之前，我们先来看看 Laravel Octane 的请求处理流程。

随着 Server 的启动，程序会创建指定数量的 Worker 进程。当请求到来时，会从可用的 Worker 列表中选取一个并交由他处理。每个 Worker 同一时刻只能处理一个请求，在请求处理过程中，对资源（变量/静态变量/文件句柄/链接）的修改并不会存在竞争关系，所以 Laravel Octane 时线程(进程)安全的。

这其实和 FPM 模型是一致的，不同的地方在于 FPM 模型在处理完一个请求后，会销毁该请求申请的所有内存；后续请求到来时，依然要执行完整的 PHP 初始化操作（参考 PHP-FPM 启动分析）。而 Laravel Octane 的初始化操作是随着 Worker Boot 进行的，在整个 Worker 的生命周期内，只会进行一次初始操作（程序启动的时候）。后续请求将直接复用原来的资源。如上图，Worker Boot 完成后，将会初始化 Laravel Application Container，而后续的所有请求，都将复用该 App 实例。

Laravel Octane 工作原理

Octane 只是一个壳，真正处理请求都是由外部的 Server 处理的。不过 Octane 的设计还是值得一说的。

从源码也可以看出，随着 Worker 的 Boot 完成，Laravel Application 已被成功初始化。

// vendor/laravel/octane/src/Worker.php
public function boot(array $initialInstances = []): void
{
    $this->app = $app = $this->appFactory->createApplication(
        array_merge(
            $initialInstances,
            [Client::class => $this->client],
        )
    );
 
    $this->dispatchEvent($app, new WorkerStarting($app));
}

在处理后续到来的请求时，Octane 通过 clone $this->app 获取一个沙箱容器。后续的所有操作都是基于这个沙箱容器来进行的，不会影响到原有的 Container。在请求结束后，Octane 会清空沙箱容器并 unset 不再使用的对象。

public function handle(Request $request, RequestContext $context): void
{
    CurrentApplication::set($sandbox = clone $this->app);
 
    try {
        $response = $sandbox->make(Kernel::class)->handle($request); 
 
    } catch (Throwable $e) {
        $this->handleWorkerError($e, $sandbox, $request, $context, $responded);
    } finally {
        $sandbox->flush();
 
        unset($gateway, $sandbox, $request, $response, $octaneResponse, $output);
 
        CurrentApplication::set($this->app);
    }
}

再次注意，由于同一个 Worker 进程同一时刻只能处理一个请求，故这里是不存在竞争的，即使是对 static 变量的修改，也是安全的。

注意事项 & 第三方包适配

由于同一个 Worker 的多个请求会共享同一个容器实例，所以在向容器中注册单例对象时，应该特别小心。如下面的例子：

public function register()
{
    $this->app->singleton(Service::class, function ($app) {
        return new Service($app['request']);
    });
}

例子中采用 singleton 注册一个单例对象 Service，当该对象在某个 Provider 的 Boot 方法被初始化时，应用容器中将始终保持着唯一的 Service 对象；后续 Worker 在处理的其他请求时，从 Service 中获取的 request 对象将是相同的。

解决方法是你可以换一种绑定方式，或者使用闭包。最值得推荐的办法是只传入你需要的请求信息。

use App\Service;
 
$this->app->bind(Service::class, function ($app) {
    return new Service($app['request']);
});
 
$this->app->singleton(Service::class, function ($app) {
    return new Service(fn () => $app['request']);
});
 
// Or...
 
$service->method($request->input('name'));

强烈推荐读者阅读官方提出的注意事项。

参考

Upgrade to PHP 8 with Homebrew on Mac https://stitcher.io/blog/php-8-upgrade-mac
Laravel Octane https://github.com/laravel/octane
Laravel Sail https://github.com/laravel/sail
FastCgi 与 PHP-fpm 之间的关系 https://godruoyi.com/posts/the-relationship-between-fastcgi-and-php-fpm
PHP-FPM vs Swoole https://developpaper.com/php-fpm-vs-swoole/
Swoole 编程须知 https://wiki.swoole.com/#/getting_started/notice

Go 语言的雪花算法实现

Thu, 15 Apr 2021 08:30:29 GMT

An Lock Free ID Generator for Golang implementation View on GitHub.

Snowflake is a network service for generating unique ID numbers at high scale with some simple guarantees.

The first bit is unused sign bit.
The second part consists of a 41-bit timestamp (milliseconds) whose value is the offset of the current time relative to a certain time.
The 10 bits machineID(5 bit workid + 5 bit datacenter id), max value is 2^10 -1 = 1023.
The last part consists of 12 bits, its means the length of the serial number generated per millisecond per working node, a maximum of 2^12 -1 = 4095 IDs can be generated in the same millisecond.
The binary length of 41 bits is at most 2^41 -1 millisecond = 69 years. So the snowflake algorithm can be used for up to 69 years, In order to maximize the use of the algorithm, you should specify a start time for it.

The ID generated by the snowflake algorithm is not guaranteed to be unique. For example, when two different requests enter the same machine at the same time, and the sequence generated by the node is the same, the generated ID will be duplicated.

So if you want use the snowflake algorithm to generate unique ID, You must ensure: The sequence-number generated in the same millisecond of the same node is unique.

Based on this, we created this package and integrated multiple sequence-number providers into it.

AtomicResolver (base sync/atmoic)

Each provider only needs to ensure that the serial number generated in the same millisecond is different. You can get a unique ID.

Feature

✅ Lock Free
🎈 Zero configuration, out of the box
🚀 Concurrency safety
🌵 Support private ip to machineid
🐡 Support custom sequence resolver

Installation

$ go get github.com/godruoyi/go-snowflake

Useage

simple to use.

package main
 
import (
    "fmt"
 
    "github.com/godruoyi/go-snowflake"
)
 
func main() {
    id := snowflake.ID()
    fmt.Println(id)
    // 1537200202186752
}

Specify the MachineID.

package main
 
import (
    "fmt"
 
    "github.com/godruoyi/go-snowflake"
)
 
func main() {
    snowflake.SetMachineID(1)
 
    // Or set private ip to machineid, testing...
    // snowflake.SetMachineID(snowflake.PrivateIPToMachineID())
 
    id := snowflake.ID()
    fmt.Println(id)
}

Specify start time.

package main
 
import (
    "fmt"
    "time"
 
    "github.com/godruoyi/go-snowflake"
)
 
func main() {
    snowflake.SetStartTime(time.Date(2014, 9, 1, 0, 0, 0, 0, time.UTC))
    id := snowflake.ID()
    fmt.Println(id)
}

Parse ID.

package main
 
import (
    "fmt"
    "time"
 
    "github.com/godruoyi/go-snowflake"
)
 
func main() {
    id := snowflake.ID()
    sid := snowflake.ParseID(id)
 
    fmt.Println(sid.ID)             // 132271570944000000
    fmt.Println(sid.MachineID)      // 0
    fmt.Println(sid.Sequence)       // 0
    fmt.Println(sid.Timestamp)      // 31536000000
    fmt.Println(sid.GenerateTime()) // 2009-11-10 23:00:00 +0000 UTC
}

Best practices

⚠️⚠️ All SetXXX method is thread-unsafe, recommended you call him in the main function.

package main
 
import (
    "fmt"
    "time"
    "net/http"
 
    "github.com/godruoyi/go-snowflake"
)
 
func main() {
    snowflake.SetMachineID(1) // change to your machineID
    snowflake.SetStartTime(time.Date(2014, 9, 1, 0, 0, 0, 0, time.UTC))
 
    http.HandleFunc("/order", submitOrder)
    http.ListenAndServe(":8090", nil)
}
 
func submitOrder(w http.ResponseWriter, req *http.Request) {
    orderId := snowflake.ID()
    // save order
}

Advanced

Custom sequence resolver. you can customize the sequence-number resolver by following way:

package main
 
import (
    "fmt"
    "time"
 
    "github.com/godruoyi/go-snowflake"
)
 
func yourSequenceNumber(ms int64) (uint16, error) {
 
}
 
// usage
 
snowflake.SetSequenceResolver(yourSequenceNumber)
snowflake.ID()

Blog 3 周年

Fri, 02 Apr 2021 05:12:22 GMT

2021-04-04 号，博客就满了 3 周年了。作者已经忘记了博客具体上线时间了，只记得 Timeline 里，最早的文章发布于 2018-04-04。

三年前因为朋友推荐的便宜服务器，120/年，可续费三次；心想搭个博客吧，三年后看看自己能折腾成什么样子；而一晃三年真过去了，自己才写了不到 50 篇文章，博客也没有变成想象中成功的样子。

截图于 2021-03-26

Google Analytics

Google Analytics 显示去年一年的 uv 才不到 1000 人（博客上线很长一段时间后才开始支持 Google Analytics，所以前面 10 个月都没有数据记录）。

PV

最常访问路径

这时我又想起了那段话：「我没有成名，没能兑现向热尼娅许下的诺言，但是还有一点我没有失信：我在一堆缴获的汽车当中，以廉价买了一部旧奥佩尔。我换上一套簇新的衣服，开着奥佩尔向大剧院驶去」。

当然，这是我记录生活记录感悟的地方，太多人关注说不定还影响自己内心的想法；只希望 10 年 20 年后，博客还在，回头再看看这些年的变化时，能对着屏幕会心一笑。

前几天得到了老婆的支持，又准备续三年的服务了。

Go 语言的词法分析和语法分析(2)—Import声明的解析

Thu, 25 Mar 2021 07:21:21 GMT

上篇文章 Go 语言的词法分析和语法分析(1) 作者阐述了渐渐式词法分析的过程；通过这一步，源文件已被转化为 Syntax.File 结构体，其属性情况如下：

图 2.0 Syntax.File 结构体

File 结构体中的 PkgName 属性已被初始化为 syntax.Name{Value: “main”}。Go 语言扫描器 Scanner 再处理完包名 PkgName 后，下一次解析将扫描出 import token；此时 *scanner 的 b, r, e 属性如下图所示：

图 2.1 import token

同样，通过 buf[b:r] 计算出当前扫描的 token 为 import 字符串，对比 Go 关键字列表后将 tok 设置为内置 _Import，此时 *scanner 内部各属性如下图所示：

图 2.2 scanner content

ImportDecl 解析

然后扫描器将开始循环解析源文件的 import 声明，直至扫描到的 token 不等于 _Import，并把 import 的 path 部分（如 net/http, main）等保存到扫描器的 DeclList 数组（slice）中。

for p.got(_Import) {
    f.DeclList = p.appendGroup(f.DeclList, p.importDecl)
}
 
func (p *parser) got(tok token) bool {
    if p.tok == tok {
        p.next()
        return true
    }
    return false
}

Import 有多种不同格式的声明，常见文法有：

import . path/package
import alias path/package
import path/package
import _ path/package
 
// by group
import (
    . path/package
    alias path/package
    path/package
    _ path/package
)

Go 语言内部用 ImportDecl 结构体来描述 import 声明，其结构如下：

ImportDecl struct {
    Group *Group       // 分组，同一括号下的为同一组
    LocalPkgName *Name // 别名
    Path *BasicLit     // 路径，如 net/http
}

在进行 import 词法解析时， Go 语言会尝试初始化 ImportDecl 结构体并为其各属性赋值；下面作者针对不同情况来查看赋值后的 ImportDecl 结构体内容。

假设申明语句为 import "net/http"，解析完该语句后结构体内容如下：

图 2.3 常见的 Import 声明

结构体中的 PkgName 属性（包别名）被设置为 syntax.Name{Value: ""}，Group 被设置为 nil，Path 部分被设置为 syntax.BasicLit{Value: "net/http"}。

假设申明语句为 import alias "net/http"，解析完该语句后结构体内容如下：

图 2.4 别名类型的 import 声明

假设申明语句为 import . "net/http"，解析完该语句后结构体内容如下：

图 2.5 Dot 格式的 import 声明

假设申明语句为下面分组

import (
    "fmt"
    "net/http"
)

解析完该语句后结构体内容如下（多个 *ImportDecl 指向同一 Group）：

图 2.6 Import Group

至此，Import 语法申明已基本解析完毕，接下来 Go 语言将解析 const, val, func, type 等 TopLevelDecl 级别的声明；毕竟 Go 语言的顶级申明就只有这六个关键字，全部解析完毕后，Go 语言的词法语法分析就完成了。

package
import
const
var
type
func

针对上篇文章 Go 语言的词法分析和语法分析(1) 中的 main.go 文件，进过这一步解析后，syntax.File 结构体信息如下：

图 2.7 import声明解析后的结构体信息

TopLevelDecl

下面是 Go 语言处理完 import 声明后开始处理其他 TopLevelDecl 的函数代码，代码所在位置 src/cmd/compile/internal/syntax/parser.go:399。

// { ImportDecl ";" }
for p.got(_Import) {
    f.DeclList = p.appendGroup(f.DeclList, p.importDecl)
}
 
// { TopLevelDecl ";" }
for p.tok != _EOF {
    switch p.tok {
    case _Const:
        // 处理常量
    case _Type:
        // 处理类型定义
    case _Var:
        // 处理变量
    case _Func:
        // 处理函数
    default:
        p.syntaxError("non-declaration statement outside function body")
    }
}

从这里也能看出，import 声明只能放在 package 声明后面，其他顶级声明前面；因为在 import 声明解析完成后，扫描器将进入下一个 for 循环继续解析其他 TopLevelDecl，若这时再遇到 _Import token，程序将走到 switch 的 default 分支，从而发生编译错误。

./prog.go:11:1: syntax error: non-declaration statement outside function body

接下来阅读

下篇文章将探讨 Go 语言对常量的解析，这部分作者将在后面的文章中继续输出。

Go 语言的词法分析和语法分析(1)

Mon, 22 Mar 2021 07:02:41 GMT

这篇文章是在看完 Go 语言设计与实现前两章词法分析及语法分析后的总结，作者尽量站在宏观的角度，说一下 Go 语言中的词法分析和语法分析，尽量不涉及具体的源码探索。

词法分析

词法分析（lexical analysis）是计算机科学中将字符序列转换为标记（token）序列的过程——词法分析 - 维基百科，自由的百科全书。

图 1.0 词法分析

可以简单的理解为将源代码按一定的转换规则，翻译为字符序列的过程。

如给定的如下转换规则：

%%
package      printf("PACKAGE ");
import       printf("IMPORT ");
func         printf("FUNC ");
\.           printf("DOT ");
\{           printf("LBRACE ");
\}           printf("RBRACE ");
\(           printf("LPAREN ");
\)           printf("RPAREN ");
\"           printf("QUOTE ");
\n           printf("\n");
[0-9]+       printf("NUMBER ");
[a-zA-Z_]+   printf("IDENT ");
%%

其中第一条规则表示将源代码中的 package 翻译为 PACKAGE ，其他类似；若用该规则来翻译如下的源代码：

package main
 
import (
    "fmt"
)
 
func main() {
    fmt.Println("Hello")
}

则输出的 Token 序列为：

PACKAGE  IDENT

IMPORT  LPAREN
	QUOTE IDENT QUOTE
RPAREN

FUNC  IDENT LPAREN RPAREN  LBRACE
	IDENT DOT IDENT LPAREN QUOTE IDENT QUOTE RPAREN
RBRACE

输出的 Token 序列已经看不出是什么语言了；当然，这种纯字符的 Token 对后续的分析帮助不大，一般分析器都会把他封装为一个结构体，以包含更多信息。

type tokenx struct {
    tok token   // 解析的 Token 序列（如上的 IDENT）
    lim string  // 原始值（如 main）
}

语法分析

图 2.0 语法分析

语法分析是将词法分析的输出当作输入，按照给定的语法格式进行分析并确定其语法结构的一种过程。

举个列子，假设输入序列为 S，对应的语法规则为：

S -> E + F

其含义为输入序列 S 可以表示为两个子项 E、F 相加；而 E 可以表示为：

E -> E + F
  -> F

其含义为 E 可以分解为两个子项 E、F 相加；或分解为一个单独的 F 项；

F -> num{1, 2, 3, 4, 5}

而 F 表示数字集合，假设只有上述数字集合，即 F ∈ {1, 2, 3, 4, 5}。

则下面的字符序列都是有意义的，即给定的字符序列 S，是否能从语法规则中被推导出来

1 + 1
1 + 2
2 + 3 + 4
1 + 2 + 3 + 4
1 + 3 + 2 + 4 + 5

假设给定的字符序列 S 为 2 + 3 + 4，按上述的规则 S -> E + F，分步推到如下（按最右推导，即从最右边字符开始）：

S -> E + F // 原规则
S -> E + 1 // 将 F 解析为数字 1，1 ≠ 4 继续回溯
S -> E + 2 // 2 ≠ 4 继续回溯
S -> E + 3 // 3 ≠ 4 继续回溯
S -> E + 4 // ok，数字 4 已最小不可分解
S -> (E + F) + 4 // 将 E 按推导为 E + F 格式
S -> (E + 1) + 4 // 将 F 解析为数字 1，1 ≠ 3 继续回溯
S -> (E + 2) + 4 // 将 F 解析为数字 2，2 ≠ 3 继续回溯
S -> (E + 3) + 4 // ok
S -> (F + 3) + 4 // 将 E 按推导为 F 格式
S -> (1 + 3) + 4 // 将 F 解析为数字 1，1 ≠ 2 继续回溯
S -> (2 + 3) + 4 // ok

即通过给定的规则，推导出字符串 S1，该字符串和原始字符序列 S 相等，语法分析即认为该输入序列是合法的。

而下面的字符序列是无效的，即语法错误；

7 + 1 // 不合法，不可能推出数字 7
1 + 2 + 6 // 不合法，不可能推出数字 6

可以看到，语法分析器将采用递归的思想，一层一层分析，直到子项不可再分；具体的推导过程推荐观看编译原理 — 中科大_哔哩哔哩 P39。

Go 语言的词法分析 & 语法分析

Go 语言中的词法分析和语法分析是放在一起进行的；经过这一步，最终将源代码生成抽象语法树。

图 3.0 Go语言的词法分析与语法分析

作者将通过下面的列子来探索 Go 语言的词法分析过程。假设目标文件夹中有两个文件 hello.go 和 main.go，其内容如下；

// main.go
package main
 
import "fmt"
 
func main() {
    fmt.Println(Hello)
}
 
// hello.go
package main
 
var Hello string = "Hello world"

Go 语言的编译器入口是在 src/cmd/compile/main.go；在进行一些初始化准备工作后，编译器获取待解析的文件数组，并将其交给 Go 语言解析器负责解析。

var filenames = []string{
    "main.go",
    "hello.go",
}
 
// src/cmd/compile/internal/gc/main.go:578
parsefiles(filenames)

解析器会利用多个 goroutine 来并发解析源文件，其 goroutine 数量取决于处理器的核心数 + 10，主要作用是为了控制同时打开的文件数量。

// Limit the number of simultaneously open files.
sem := make(chan struct{}, runtime.GOMAXPROCS(0)+10)
 
for _, filename := range filenames {
    go func(filename string) {
        sem <- struct{}{}
        defer func() { <-sem }()
        
        file := syntax.Parse(os.Open(filename))
    }(filename)
}
// wait

syntax.Parse 解析器会将每一个源文件解析为一个 source 结构体，其简化的格式如下：

type source struct {
    buf []byte  // 源代码字节数组
    ch  rune    // 指向当前解析的字符
    b,r,e int   // 指向buf数组的开始/当前扫描字符/结束指针
}

解析器在初始化时，会将 buf 初始化为一个 4k 大小的空 slice，并将第一个字节设置为空格 ' '，如图所示：

图 3.1 buf初始化

然后解析器开始一个字符一个字符的读取并分析，但由于 buf 目前是空的，第一次解析时会尝试读取目标文件内容到 buf 中；针对上面的 main.go 文件，读取后 buf 内容为：

图 3.2 读取文件内容

接下来，解析器会尝试从 buf 中一个字符一个字符的读取，再遇到 ' ', \n, \t, \r 等字符时分离。

for s.ch == ' ' || s.ch == '\t' || s.ch == '\n' && !nlsemi || s.ch == '\r' {
    s.nextch()
}

针对图 3.2 的 buf 内容，第一次操作结束后，扫描器中的 b,r,e 指针如下图所示：

b: begin 开始位置；r: read 当前读取到的位置；e: end 结束位置。

图 3.3 解析第一个 token

解析器通过 b,r 指针计算（类似 buf[b:r]）出本次解析获得的字符串 package；再和 Go 预定义的关键字列表对比后，最终将设置当前 sacnner 扫描器的 tok 属性设置为 _Package。

第一次解析结束后，扫描器的各个属性如下图所示：

图 3.4 扫描器scanner基本属性情况

Go 语言的词法分析是渐渐试的，在获得第一个 token 后，解析器尝试初始化 SourceFile；每一个 SourceFile 对应一个 go 文件，其中包含包的名称，变量、常量、函数等的全部定义，其简化结构如下：

type File struct {
    PkgName  *Name  // package name
    DeclList []Decl // 包含包名/变量/常量/函数等的定义
}

Go 源码中使用 fileOrNil 方法初始化 file，解析器将检查第一个 token 是否为 pakcage，否则将报错；毕竟所有的 go 文件都是以 package 开头的。

// 伪代码
func fileOrNil() {
    f := new(File)
 
    if tok != _Package {
        p.syntaxError("package statement must be first")
    }
 
    f.PkgName = ?
}

接下来解析器将设置当前 file 的包名，但此时解析器并不知道具体的包名是什么；不过根据语法规则解析器知道 package 关键字后面一定是跟的包名，只需要解析出下一个 token，该 token 就是对应的包名称。

第二次解析结束后，扫描器中的 b,r,e 指针如下图所示：

图 3.5 第二次解析结束

在需要什么的时候，显示的解析什么，这也是 Go 解析器渐渐试解析的体现。

同样，根据 b,r 指针，计算出当前解析获得的字符串为 main；该字符串非内置 token，Go 语言将设置当前 sacnner 扫描器的 tok 及 limi 属性为 _Name 及 main，其中 lit 是被扫描符号的文本表示。

_Name 一般表示变量名/常量名/方法名等，可以理解为非内置关键字的文本类型。

第二次解析结束后，scanner 的各个属性如下图所示：

图 3.6 扫描器scanner基本属性情况

检查 _Package 及设置当前文件 PkgName 的伪代码如下：

f := new(File)
 
if tok != _Package {
    p.syntaxError("package statement must be first")
}
 
tok := parser.next() // 伪代码 get next token
if tok != _Name {
    // 验证：包名必须是一个 name 类型的 token, 
    // 可以理解为非内置关键字的文本类型
}
 
f.PkgName = &Name{Value: "main"} // 伪代码

到目前为止，解析器已经成功的初始化 syntax.File 结构并为其 PkgName 属性赋值，如图 3.7：

图 3.7 syntax.File 属性

接下来，解析器将开始分析 Go 语言的 import 关键字，这部分作者将在后面的文章中继续输出。

// { ImportDecl ";" }
for p.got(_Import) {
    f.DeclList = p.appendGroup(f.DeclList, p.importDecl)
    p.want(_Semi)
}

接下来阅读

参考

金瓶梅

Fri, 19 Feb 2021 08:23:15 GMT

今儿用微信听书听金瓶梅，听到有一段特别有意思，心想用程序来描述出来肯定也不错。

下面是背景描述：

王婆给西门庆定的挨光十记，满足这十条，就能妥妥的挨光了。

武大郎为人软弱，每天早出晚归，只知道做买卖，所以潘金莲一般不出门；老身（王干娘，以下为第一人称）没事，有机会过去就和她闲坐聊天，她有事儿呢，也请我帮忙。大官人（西门庆）如干此事，便买来一匹蓝绸、一匹白绸、一匹白绢，十两好绵交给我，我去让她帮我挑个日子我请裁缝来做衣服。

package main
 
func main() {
    _, 答应替我做 := 向她借黄历挑缝制衣服的日子()
    if !答应替我做 {
        return
    }
    println("这光便一分了")
 
    if !愿意到我家来做() {
        return
    }
    println("这光便二分了")
 
    if !愿意留在这儿吃饭() {
        return
    }
    println("这光便三分了")
 
    // 这天你不要来，直至第三天晌午前后，你整整齐齐打扮了来，以咳嗽为号。
 
    if 我邀你进来喝茶她就要走() {
        if 不让她走() {
            panic("强扭的瓜要长蛆")
        }
        return
    }
    println("这光便四分了")
 
    // 进来坐下后，我介绍你就是让我做衣服的官人，
    // 便夸你的许多好处，你便夸她针线活好。
 
    if 她若不理你() {
        return
    }
    println("这光便五分了")
 
    // 为了感谢娘子为你做衣服我提议让你作东请我们吃饭，你并拿钱让我去买酒肉。
 
    if 她起身离去() {
        return
    }
    println("这光便六分了")
 
    // 我拿上银子，临出门时对她说：有劳娘子相待官人坐一坐。
 
    if 她起身离去() {
        return
    }
    println("这光便七分了")
 
    // 买完东西回来后我让娘子「且吃一杯儿酒，难得这官人坏钱」。
 
    if 不肯一起吃饭() || 她起身离去() {
        return
    }
    println("这光便八分了")
 
    // 待他吃得酒浓时说得入港时，我便推道没了酒，你并拿出银子让我去买酒。
 
    if 她起身离去() {
        return
    }
    println("这光便九分了")
 
    // 独处一室后，大官人却不可燥暴，别动手动脚，把事儿打搅了。
    // 你用袖子把桌子上的筷子拂下去，然后假装捡筷子，并在她脚踝上捏一捏。
 
    if 她闹起来() {
        return
    }
 
    println("此事十分光了") //
		
    println("🈲，未满18岁请在大人陪同下观看")
    println("🈲，未满18岁请在大人陪同下观看")
    println("🈲，未满18岁请在大人陪同下观看")
}

顺道编译运行下：

$ go run main.go
这光便有一分了
这光便二分了
这光便三分了
这光便四分了
这光便五分了
这光便六分了
这光便七分了
这光便八分了
这光便九分了
此事十分光了
🈲️，未满18岁请在大人陪同下观看
🈲️，未满18岁请在大人陪同下观看
🈲️，未满18岁请在大人陪同下观看

2020 年终总结

Thu, 11 Feb 2021 15:42:01 GMT

二愣和阿宝今年过年没回家。这是二愣第一次不回家过年。小两口坐在重庆小家的沙发上，嗑着坚果、喝着果汁、嘻嘻哈哈的看着春晚。

对于我来说，过完农历三十才叫新年呐。看着 bear 里只埋了标题的年终总结，压的我看春晚都看不起劲。

怎么说，今年也是不平凡中平凡的一年；不平凡是因为今年确实发生了很多事；小宝走了、阿宝怀孕了、二愣生病了、富贵儿走了、连我的小摩托也被人顺走了。而平凡则是即使我们发生了再多的事，就像拿去年和前年来比，也并没有什么是大不了的。而疫情？时逢乱世我对这并没有什么想说的，我也不关心多少人感染了多少人又离世了。只要我及我的亲人健康平安，其他的都随缘吧！我就是这大千世界平凡而普通的人。

工作 & 技术

去年立下的 flag，现在回过头看，似乎大部分都未完成。年中的时候，由于公司转型，我开始接触 go 语言。用了它做了一两个项目后，愈发感觉 go 语言骨子里的简单。在保持原生多并发支持前提下，并没有额外增加面向对象、继承、范型等特性。虽说写的代码量可能变多了，但比起简单和高效这完美的平衡来说，已经足够了。

~~我其实并不看好范型，这会严重增加语言的复杂程度，保持这样的简单就好了。~~ 自从看了 Rust 后，我收回以前的观点，我现在觉得 Go 应该早点支持范型的。

虽说 go 语言确实简单，但深入到原理后，就越来越多的特性需要学习的了。随着使用的加深，我现在甚至在开始学习计算机系统相关了。诸如内存管理、内存分配、编译原理。大部分工作了几年的程序员，估计都会回过头去捨起自己当初丢下的东西吧。

今年开源了 2～3 个开源库，新增了 300 多个 Star。并在时隔两年后，终于完善了 OCR 的 2.0 版本，虽说没什么人用，但对得起自己当初开源的初衷了。

Todo 2021

目标还是要定，即使我完全不按这样做。等到明年再来写总计的时候，也好有个照应。

学习Rust
深入学习 Golang
看完 CSAPP
锻炼身体

最后一句，还是要多说话、多说话，自信一点。

往年总结

2019 年终总结

九华山的和尚

Thu, 04 Feb 2021 03:33:39 GMT

当二愣拿着从体检中心领取的早餐站在门口时，一位身穿黄色大褂的和尚出现在他面前。圆顶方袍、颈带佛珠，符合二愣心中对和尚的一切想象。他一手搓着佛珠，一手做着阿弥陀佛，操着流利的普通话：

小伙子，我看你这么阳光明媚，满脸红光，20 几了啊？

那几天二愣刚剪了个短发，看起来着实眉清目秀。但心怀警惕的二愣说了就当没说的回答道：

20 多岁。

你们年轻人不要一直搞手机啊，我看你站在哪里玩手机，我叫了三遍你都没有回应。

和尚这样说，让二愣觉得好似有什么好事朝我游过来后又流走了似的，愈发珍贵起来。

哦我刚在跟我老婆说我检查完了。好像一定要让他知道，我和别人那些低头玩手机的不一样，但又有什么不一样呢，二愣也说不出来。

我看你脸带阳光、面色和蔼，还长着一对连字眉，一般人都没有你这样的眉毛。但你额头淡黑，今年运气不怎么好吧。

二愣今年运气确实不佳，丢了猫、生了病、掉了宝。

佛渡有缘人，遇见就是缘。你最近要提防小人，交朋友这些切忌不要交尖嘴猴腮之人、鼻子塌的人。这些人会挡住你往后的鸿运。今年后，你将会大运不断，你也会遇到生命中的贵人，但是切记切记不要被小人影响。

那一刻我仿佛感到一束阳光照了下来，感觉过往的再多不是，都已烟消云散。连忙双手合十学着阿弥陀佛的样子答道：

借你吉言，借你吉言。

父母不在身边吧，她们年纪也大了，抽时间多回去看看，他们养大你也不容易。

但你眼眶干涩淡红，心脏是不太好吧？

二愣心里一惊，他只是肝和肺不太好，心脏应没问题吧！

和尚边说边走，好像下一句说完了就要匆忙赶路走了的样子。

我是九华山的和尚，来华岩寺参加佛事，佛渡有缘人。

他又说了一次，佛渡有缘人。但二愣还沉迷阳光普照无法自拔。居然还用手比划了一个您忙您先走的手势。

和尚又说了一句，佛渡有缘人，我会向佛祖表达你的善意，并掏出了自己的收款码。

最后，二愣掏出了手机，扫了扫道士的收款码，径直离去。他又长了点心，但他好像也没后悔。

和尚为什么要随声携带收款码这个东西。

axios 的错误处理

Thu, 21 Jan 2021 08:06:17 GMT

Axios 是目前使用最为广泛的 http 请求工具包，在进行错误处理时，基于框架提供的拦截器，我们可以快速的实现错误处理。

axios interceptor

axios.interceptors.response.use(function (response) {
    return response;
}, function (error) {
    // 如4xx/5xx等基本错误的处理
    alert('全局错误处理')
 
    return Promise.reject(error); 
});

但 axios 提供的 response 拦截器是全局的，若我们想对某个具体请求进行错误处理时，情况就稍微有点复杂了。

如有一个投票接口，由于后端限制了投票次数，当投票超限时我们需要单独处理；返回的响应如下：

HTTP/1.0 429 Too Many Requests
 
{"error_code":4291011,"message":"今日投票次数超限"}

可能对于部分前端同学来说，处理方式是直接在 response 拦截器加上相应的条件判断就好了：

axios.interceptors.response.use(function (response) {
    return response;
}, function (error) {
    if (error.response.status == 429) {
        if (error.response.data.error_code == 4291011) {
            // 单独处理投票错误
        } else if (error.response.data.error_code == 4291011) {
				    // 作品票数异常，需先通过滑动验证码
				}
    }
 
    // 处理其他 如4xx/5xx等基本错误的处理
    return Promise.reject(error); 
});

但是这样做却存在很多问题

随着各种错误码的增多，拦截器需要处理的情况越来越多，最终充满着大量的 if-else
具体的错误码应该和具体发起请求的代码放在一起，一来方便查看，二来好扩展及定位

所以我们可以把错误处理逻辑移到调用代码处，如下：

axios.post('/vote/1').then(function (response) {
    // success
}).catch(function (error) {
    let code = error.response.data.error_code
    if (code == 4291011) {
        alert('投票超限')
    } elseif (code == 4030001) {
        alert('作品票数异常，需先通过滑动验证码')
    }
});

但这样又存在一个问题，由于 axios 拦截器的代码会比 catch 先执行，所以当执行到 catch 时，实际上 response 拦截器的代码已全部执行完成，所以会先后弹出「全局错误处理」-> 「投票超限」。

这显然不是我们想要的，我们希望当我们单独处理错误后，先执行具体的业务错误处理，最后在执行全局的错误处理。

如下：

针对这种没有 catch 的情况，当请求错误后，我们希望由全局错误进行处理。

axios.post('/vote/1').then(function (response) {
    // success
})

这默认是可行的，不需要做额外的准备工作。

当我们使用 catch 后，我们希望应该先处理自定义的错误，最后在处理全局错误。

axios.post('/vote/1').then(function (response) {
    // success
}).catch(error => {
    // custom error 
})

然而目前这样是行不通的，看了 axios request 方法源码后得知，框架在发起请求时，并没有给我提供相应的钩子；所以在 Promise 执行到 catch 时，拦截器里的代码一定已经执行过了。

axios config

我们只能依赖 axios 提供的 config 来完成这个特性，如下所示：

axios.interceptors.response.use(function (response) {
    return response;
}, function (error) {
    error.globalErrorProcess = function () {
        switch (this.response.status) {
            case 401: // 处理基本 401 错误
                break;
            case 404: // 处理基本 404 错误
                break;
            case 403: // 处理基本 403 错误
                break;
                      // 处理其他4xx/5xx等基本错误的处理
        }
 
        return Promise.reject(this);
    };
 
    if(error.config.hasOwnProperty('catch') && error.config.catch == true) {
        return Promise.reject(error);
    }
 
    return error.globalErrorProcess()
});

我们定义一个全局的错误处理器，并把他赋给 error 对象的 globalErrorProcess 方法。接着判断当前请求 config 是否启用 catch，若启用，默认不进行任何错误处理，交由调用方自行负责；否则用全局错误处理。

在使用时，若需要自定义捕获错误，可显示传递一个 config，相应请求方法的 API 如下：

axios.request(config)
axios.get(url[, config])
axios.delete(url[, config])
axios.head(url[, config])
axios.options(url[, config])
axios.post(url[, data[, config]])
axios.put(url[, data[, config]])
axios.patch(url[, data[, config]])

axios.post('https://api.github.com/xxx', null, {catch: true}).then(function (response) {
    console.log(response);
}).catch(function (error) {
    let code = error.response.data.error_code
 
    if (code == 4291011) {
        // 今日投票次数太多，显示关注公众号二维码
    } else if (code == 4031011) {
        // 不允许的投票时间段，
    } else if (code == 4291012) {
        // 作品票数异常，需先通过滑动验证码
    }
 
    return error.globalErrorProcesser()
});

最后别忘了显示的调用全局错误处理，否则是不会懒觉到其他异常处理的。

如果你有更好的方案，欢迎留言一起探讨。

参考 & 讨论

Go 语言限流器的实现

Fri, 15 Jan 2021 09:41:08 GMT

今天在看 GitHub 趋势榜的时候看到一个小巧的 go 框架 chi，看了下他限流器中间件的实现，觉得还挺有趣的。

我们知道 Laravel 的 Throttle 中间件是用计数器实现的，每次请求计数器 +1，可以大概限制每一分钟允许多少个请求。所以在看源码前我就在想：

这个限流器是不是也用的计数器实现的？
他是怎么解决某一时间区间内实际请求数大于限制条件这一问题的？

然而看完后才醒悟，golang 中直接使用 channel 来实现即简单又可靠。

程序启动的时候，向一个带缓冲的 chan 发送一个空结构体 struct{}{}，简化版如下：

func main() {
    tokens := make(chan struct{}, 10)
 
    // 随程序启动，创建一个带缓存的 chan
    for i = 0; i < 10; i ++ {
        tokens <- struct{}{}
    }
 
    http.HandleFunc("/", func(rw http.ResponseWriter, r *http.Request) {
        select {
        case <-tokens:
            rw.Write([]byte("success"))
            break
        default:
            rw.Write([]byte("Too many request"))
        }
    })
 
    http.ListenAndServe(":9911", nil)
}

程序启动完成后，针对每一个请求，通过 select 从缓冲通道 tokens 里获取数据；因为一开始缓冲通道已初始化 10 条数据，所以对于前 10 个请求，肯定能从 tokens 里获取到数据。

而对于后续的请求，由于此时通道里也没有任何数据，所以程序默认选择 default 分支执行代码，会从而返回 Too manay request。

➜  ~ curl 127.0.0.1:9911/
success
➜  ~ curl 127.0.0.1:9911/
success
 
...
 
➜  ~ curl 127.0.0.1:9911/
Too many request

当然这样实现的话这个限流器就只能处理前 10 个请求了，为了能真正达到同一时刻只有指定数量的请求能被处理，只需在从通道里获取到数据后，处理完具体的业务逻辑，再返还给通道即可。

select {
case btok := <-tokens:
    rw.Write([]byte("success"))
    tokens <- btok // join to chan
    break
default:
    rw.Write([]byte("Too many request"))
}

这只是一个简单的实现，CHI 的这个中间件还添加了超时、cancel 和 backlog 的支持，具体可参考chi/throttle.go at master · go-chi/chi · GitHub。

去医院的一天

Mon, 23 Nov 2020 09:49:54 GMT

下午请了半天假，今天又是去医院的一天。

爬上门诊部二楼开始排队取号时，看了看时间，才下午两点半。前面的夫妻预约取号按成了预约挂号，还指着已经满号的医生问我为什么按不动，我说满号了，挂不起，他说我取号怎么操作啊，我默默的帮他按了下 Home 按钮并指它这个才是取号。

看着他操作了半天后，屏幕提示请在一个小时后取票，我并不知道为什么，心想可能是他刚挂的号需要等一个小时吧。结果我轮到我依然是一样的提示。

得，昨晚预约的是 16.30 到 17.00，看起来只能在 15:00 左右的时候才能取到号了。心想要不是试下窗口吧，说不定能取到。

窗口排队的人是真的多，好不容易排到我了，结果时间还是没到，还是不让取号，只差几分钟，工作人员都在无私的坚持自己的职业道德。可能是我没对他微笑吧！

15.30 后，我又在取号机前排起了队。但是这次按着按着取号机就卡住不动了，左边的大叔钱都扣了，屏幕还是一直转，一动不动；我问了旁边扫地的阿姨这排机器该找谁维护，他说去老年科背后找一卡通的人。好不容易人挤人的过去了，一卡通的说这是网络的问题，他们不是技术人员无能为力，让我等一会再试，交了钱的去 1、2 号窗口人工处理。

心想他们可能经常遇到这问题，就像开发对测试说这是网络问题，你重新试试一样。

我又去一楼的机器打印，排到一个大姐姐后面，看着他一步步操作，输入密码，插入银行卡，至于为什么要插入银行卡，社保里有钱的人可能永远也体会不到。操作一切都还顺利，成功的拿到取号凭据。轮到我把社保卡插进去后，就开始转圈了，一分钟过去了，还是在转圈。。

我放弃了，转而走向了二楼呼吸科分诊台门口，看到窗口排队的还是这么多，想想算了，直接去找分诊台的医生吧！趴在分诊台的柜台上，灵机一动的给医生看了我线上支付的凭据后，他终于取到号了；而接下来又开始了漫长的排队等待。

三个小时过去了，他还在排队，他可真笨啊，早不这样干。

Ocr 2.0 Release（拖延症）

Fri, 20 Nov 2020 08:53:41 GMT

三年前在 Github 发布了一个图片识别的 PHP 扩展包 godruoyi/ocr，主要功能是整合几大厂商的图片识别接口，方便统一调用。

当初设计都比较简单，基本是能用就行；

~~一年后觉得自己技术牛逼了，知识过硬了~~ ，打算重新发布个版本，已更新下那难看的 last commit，随便慰藉自己当初开源的初衷吗。

然后大刀阔斧的开整，结果婚结完了，朋友朋友的婚都结完了、两年过去了，我才重构了 20%。

趁着现在大家都去旅游去了而我还在公司上班的打工命，噼里啪啦完成了 2.0 的改造，算是完成了今年的一番壮举吧。

其实当初还规划了在 2.0 添加响应过滤的功能，原型都写好了：

use Godruoyi\OCR\Support\Response;
 
$application->aliyun->filters(function (Response $response) {
    $body = $response->toArray();
    return $body['Response']['IdNum'] ?? null;
})->idcard('...'); // will return string|null

然鹅没想到完美的错误处理方式，那还不如不做，交给开发者自己来魔改吧。阿宝就经跟常我说：「你的拖延症啥时候改改啊」。

就连这篇文章都是几天前写的，然后写了一半，还得现在来补齐。啥时候能一鼓作气，再而兴，三而旺呢。

Bus Dispatcher & Event Dispatcher

Wed, 04 Nov 2020 05:17:23 GMT

Laravel 提供的 Bus 总线组件主要为了解决什么问题？我们平时使用的 event、dispatch 等方法和他有什么关系？他和 Event 组件提供的 Dispatcher 有什么区别？

Bus 总线和 Event 的组件都提供了 Dispatcher 服务，但主要区别如下：

Bus 总线提供的 Dispatcher 可以 dispatch 任何 command
Event 组件提供的 Dispatcher 只能 dispatch 已经注册的 event
都提供了 dispatch new 和 dispatch to queue 的支持

EventDispatcher dispatch 的 event 若事先未注册，则不会有任何反应。

Bus Dispatcher

完整应用了管道流的原理，可以将任意的 command 对象通过该总线发射出去。

$busDispatcher->pipeThrough($piples)->dispatch($command);

如下面的例子，用户注册成功后，通过一系列的检查操作后，发送邮件。

app('Illuminate\Contracts\Bus\Dispatcher')->pipeThrough([
    'Check1', 'Check2', 'Check3'
])->dispatch($user);
 
// need have `handler` method.
class User
{
    public function handle()
    {
        // send email.
    }
}

如果上面的 command 实现自 ShouldQueue，那么发送邮件这一步操作将会放到队列中去执行。

⏰ 此处的 handle 方法参数可自动注入你想要的任何对象。

通常我们不会将「处理器」和 command 放在同一个类中，可以通过下面的方式指定单独的处理类（发送邮件）。

手动指定处理器后， handle 方法不可在自动注入参数。

app('Illuminate\Contracts\Bus\Dispatcher')->pipeThrough([
    'Check1', 'Check2', 'Check3'
])->map([
    'App\User' => 'App\SendEmailHandler'
])->dispatch($user);
 
class SendEmailHandler
{
    public function handle(User $user)
    {
        // send emial for user.
    }
}

也可以直接调用 dispatchNow 来立即发送，这种发式无论 command 是否实现自 ShouldQueue，都不会经过队列；并且你还可以指定额外的处理器来覆盖默认的处理操作。

app('Illuminate\Contracts\Bus\Dispatcher')->pipeThrough([
    'Check1', 'Check2', 'Check3'
])->dispatchNow($user, new \App\SendReadpackHandler);

Laravel 还为我们提供了一个叫做 PendingDispatch 的类，用来「延迟」具体的 dispatch 操作。其原理和 Bus Dispatcher 一样，只是利用 PHP 的 __destruct 当对象引用被销毁或程序退出时再执行真正的 dispatch 操作。

public function __destruct()
{
    app(Dispatcher::class)->dispatch($this->job);
}

所以若你直接在命令行执行如下的代码，其实是没有任何输出的；但当你将其赋空时，程序将会正常执行。

✗ tinker
Psy Shell v0.9.9 (PHP 7.3.14 — cli) by Justin Hileman
>>>
>>> $dispatch = dispatch(new \App\Jobs\SendEmail('send email to lianbo'))
=> Illuminate\Foundation\Bus\PendingDispatch {#3076}
>>>
>>> $dispatch = null
Ok, received
=> null

Event Dispatcher

Event 组件提供的 dispatch 只能转发已经注册到事件服务上的 event，如下所示：

Event::listen($eventName, $listener);
 
$eventDispatcher->dispatch($eventName); // ok
$eventDispatcher->dispatch($otherName); // null

所以我们经常使用 event($eventName) 来发射事件。

总的来说，Event Dispatcher 的功能远不如 Bus 组件那么强大，Bus Dispatcher 基于 Laravel 强大的 Container，我们可以 dispatch 任何对象并自动注入我们需要的依赖。

连波的春天

Tue, 03 Nov 2020 04:06:42 GMT

“一家人的日常读起来就像是在看是枝裕和的电影，温情柔软，却笑中带泪。”

拍摄于贵州独山的这部剧，一开头就感觉那么亲切，老太太唱的进酒歌，仿佛就是儿时从我妈那儿听到的一样。

儿子过完年又去北京上班了，看着他上了出租车，父亲掏出钱提前付了车费，母亲看着出租车掉个头慢慢开去。

在教两老人用微信语音时，两老笑的不亦乐乎。

孩子们走后偌大的一个房子，还好有燕子叽叽喳喳。我能想到当燕子归来后，老头那种小孩似的开心的表情。

老太说，我能陪你一两年是一两年，人到暮年，我们最大的陪伴，就只有老伴了吧。

向往这样的日子

我意愿我老来的时候

在大山脚下有个房子

和阿宝种点包谷茄子

再养一头狗，像电影「百鸟朝凤」里面的妞妞一样，我在田里干活，她给我送饭。

Go 语言中的 init 函数（译）

Fri, 30 Oct 2020 09:42:11 GMT

本文译自 The Go init Function

有时候，在创建 golang 应用程序的时候，我们经常需要在程序初始化的时候执行某些操作。如初始化数据库的连接、载入本地配置文件等。

而在 Go 语言中，这些操作都是通过 init() 函数来完成的。在本篇教程中，我们将探讨如何更优雅（fame and glory）的使用 init() 函数，或许能帮助你构建你的下一个 go 项目。

Go 中的初始化函数

在 Go 语言中，init() 函数的功能非常强大，并且比其他语言更容易使用。init() 函数可以在 package 的 block 中使用，并且无论该包被导入多少次，init() 函数将始终仅被调用一次。

现在，请看下面的列子，init 函数定义的内容只被执行了一次。这种特性能使用我们有效的建立数据库连接、注册各种各样的服务，或执行您只想执行一次的其他任务。

package main
 
func init() {
  fmt.Println("This will get called on main initialization")
}
 
func main() {
  fmt.Println("My Wonderful Go Program")
}

请注意，在上面的示例中，我们并没有显示的调用 init() 函数，Go 语言会隐式地为我们处理执行，因此上述程序应提供如下所示的输出：

$ go run test.go
This will get called on main initialization
My Wonderful Go Program

利用这个特性，我们可以做一些很棒的事情，例如变量初始化。

package main
 
import "fmt"
 
var name string
 
func init() {
    fmt.Println("This will get called on main initialization")
    name = "Elliot"
}
 
func main() {
    fmt.Println("My Wonderful Go Program")
    fmt.Printf("Name: %s\n", name)
}

在上述示例中，与必须显示的调用定义的函数相比，init() 函数会更受欢迎。当运行上述程序时，变量名 name 的值已经被初始化。

$ go run test.go
This will get called on main initialization
My Wonderful Go Program
Name: Elliot

Multiple Packages

让我们来看看一个更复杂的场景，它更接近于生产环境。想象一下，我们的应用程序中有 3 个不同的 Go 包，分别是 main、broker、database。

在每一个包中，我们都可以指定一个 init() 函数，比如用于设置 Kafka 或 MySQL 的连接池。当我们调用 database 包中的函数时，它将自动调用 init 函数并初始化连接池。

🐜：你不能依赖多个 init() 函数的执行顺序。与其如此，还不如把精力花费在其他逻辑的编写上。

Init 的初始化顺序

对于更复杂的系统，你的每个包中可能包含多个文件。每一个文件都可能有自己的 init 函数。那么 Go 是如何初始化这些包的顺序的呢？

当涉及到初始化顺序时，需要考虑一些事项。 Go 通常按照声明的顺序进行初始化，但如果声明的变量依赖另外包中的变量或方法，那将但是会在它们可能依赖的任何变量之后显式初始化。这意味着，假设您在同一软件包中有两个文件 a.go 和 b.go，若 a.go 中任何内容的初始化都取决于 b.go 中的内容，则 a.go 将首先被初始化。

🐜：可以在官方文档中找到有关Go中初始化顺序的更深入概述：The Go Programming Language Specification - The Go Programming Language

来看下面的列子：

// source: https://stackoverflow.com/questions/24790175/when-is-the-init-function-run
var WhatIsThe = AnswerToLife()
 
func AnswerToLife() int {
    return 42
}
 
func init() {
    WhatIsThe = 0
}
 
func main() {
    if WhatIsThe == 0 {
        fmt.Println("It's all a lie.") // 输出这行
    }
}

在这种情况下，您会看到 AnswerToLife 函数将在 init 函数之前运行，因为 WhatIsThe 变量是在调用我们的 init 函数之前声明的。

同一文件，多个 init 函数

如果我们在同一个 Go 文件里定义多个 init() 函数会怎样？一开始我认为这是不可能的，但 Go 确实支持在一个文件中拥有 2 个独立的 init() 函数。

这些 init() 函数按声明顺序依次调用。

目前同一个 go 文件中是支持多个 init 函数的，不止 2 个。

package main
 
import "fmt"
 
var initCounter int
 
func init() {
    initCounter ++
}
func init() {
    initCounter ++
}
func init() {
    initCounter ++
}
func init() {
    initCounter ++
}
 
func init() {
    initCounter ++
}
 
func main() {
    fmt.Println(initCounter) //5
}

但我们为什么要将 init 拆分为多个呢？这样做有什么好处？其实对于复杂的系统，这使得我们可以将复杂的初始化过程分解为多个易于理解的 init 函数。从本质上讲，它使我们可以避免在单个 init 函数中包含一大推代码。需要注意的是，同一文件中的多个 init 函数是按声明时的顺序初始化的，这点在拆分时要特别小心。

结论

至此，关于 init() 函数的基本介绍就结束了。一旦你掌握了包初始化的使用，你可能会发现它对掌握基于 Go 项目的结构化艺术很有用。

原文地址 [[The Go init Function | TutorialEdge.net]]

美国中情局保藏的前苏联段子

Tue, 29 Sep 2020 10:26:48 GMT

今天给大家讲个美国中情局保藏的前苏联段子。

恐怖的兔子

两只兔子在街上碰面。

兔子甲：“出了什么事？你怎么这么急慌慌的？”

兔子乙：“你没听说吗？传的很凶呢，所有的骆驼都要被阉割。”

兔子甲：“你又不是骆驼。”

兔子乙：“等人家把你抓住、阉了，你再去想法证明自己不是骆驼吧。”

言论自由

一个美国人向俄国人解释为什么说美国是一个真正言论自由的国家。美国人说：

“我可以走到白宫前，高喊让里根下地狱！”

俄国人很不以为然：

“你这算什么，我也可以走到红场上高喊，让里根下地狱”！

共产主义与科学

一位群众问党支书：

“共产主义是谁发明的，共产主义者还是科学家？”

支书回答：“这还用问，当然是共产主义者了！”

群众：“我猜也是。如果是科学家发明的，他们一定会先拿狗实验一下。”

知识的源头

停电

Fri, 28 Aug 2020 09:11:03 GMT

前段时间贵州大雨，电力局提前发了短信，说可能会停一两个小时的电

我们家是用电来烘烟的，没电了，万把块钱一烘的烟，就全部烂掉了

爸去街上抬发电机

但是发电机太大，至少需要三个人

找不到人

姐夫说用钱请人也的去抬啊

可能是先去街上试了下

差零件

联系海军开车送去黄都购买

买回，上好，什么筛子又坏了

后面还是没抬回发电机

电停了

那就在烘烤烟的地方守着

一守就是半天

一个人或坐着、站着、蹲着、却始终无能为力

看着这幸苦办弄出来的

也只能往心里面吞

操他妈的

后联系到电力相关的人

爸跟他们吼起来了

我知道他为什么吼

换成是领导也要被吼

12 小时后，电来了

烟，却全部烂了

换一种方式，交换两个变量的值

Mon, 24 Aug 2020 15:02:22 GMT

在日常编程中，我们经常涉及到交换两个变量的值，常见实现如下。

func inplaceSwap(a, b int) (int, int) {
    c := a
    a = b
    b = c
 
    return a, b
}
 
func main() {
    println(inplaceSwap(1,2))
}
 
// output 2 1

当然，你也可以使用 a, b = b, a 来快速交换两个变量的值。

利用中间变量，快速简单又快速的实现了变量的交换。但今天发现一种高逼格的实现，虽然并没什么用，如下：

func inplaceSwap(*a, *b int) (*int, *int) {
    *b = *a ^ *b
    *a = *a ^ *b
    *b = *a ^ *b
 
    return a, b
}
 
func main() {
    a := 1
    b := 2
 
    inplaceSwap2(&a, &b)
 
    fmt.Printf("a=%v, b=%v\n", a, b) // a=2, b=1
}

在此过程中，没有用到任何临时变量，而是由下面这特性完成的。

对于任意向量 a，有 a ^ a = 0

我们假设变量 a 的内存地址为 0x80，变量 b 的内存地址为 0x90，则换算成二进制为：

a := 0x80
b := 0x90
 
// a = 1000 0000
// b = 1001 0000
 
// a ^ b = 0001 0000

则对于上面的三行运算

// 第一行
*b = *a ^ *b // 1000 0000 ^ 1001 0000 => *b = 0001 0000
 
// 第二行，这行计算完成后，变量 a 的内存地址已成功换为变量 b 的地址
*a = *a ^ *b // 1000 0000 ^ 0001 0000 => *a = 1001 0000
 
// 第三行，这行计算完成后，变量 b 的内存地址已成功换为变量 a 的地址
*b = *a ^ *b // 1001 0000 ^ 0001 0000 => *b = 1000 0000

至此，通过上三行代码，我们成功的将两个变量的内存地址交换，且没有用到零时变量。

这种交换的方式并没有性能上的优势，它仅仅是一个智力游戏。 — 深入理解计算机系统

但是这种有一个严重的弊端，当变量 a 和 b 是同一个变量时，将会导致其值为 0。

a := 0x80
b := 0x80
 
// a ^ b = 10000000 ^ 10000000 = 00000000
 
// 这将导致变量 b 的指针地址指向的值为 0
// *b = *a ^ *b   =>   *b = 0
 
// 而 a 和 b 指向的同一个地址，故 &a = 0，
// 后面即使再多操作，也只是在操作 0，本质不会发生变化。

秋老虎

Thu, 20 Aug 2020 05:36:27 GMT

家里面的老人说立秋后的第一场雨就是要强降温的前奏，跟着就会反一波热浪，重庆称为「秋老虎」（意思就是强降温之后再来一波强升温达到 38° 39°那种天气，还是有点热的哦），跟着就会越来越冷身上越来越厚进入到了寒风萧萧的冬季~。

距离动手术拿掉小福贵的那天已经过去了 57 天，身体已几乎恢复了正常，也回到岗位一个月零 9 天了，为了避免自己在这个时候生病裙子几乎很少穿了，在公司尽量避开了空调的所有风口。同事如果找不到遥控器的情况下，没话说，~准在我这儿！这 57 天我已经吃了 3 只大母鸡，2 大袋鸡蛋（记不住多少个反正两位数），碍于是手术初期避免伤口拉伤也没有做任何锻炼运动（当然我是一个坦然的人，你可以直接说我懒我不介意的），于是我的体重从 53kg 上升到了 56kg，可真是了不起，可我自己依然很自信的觉得自己很瘦？？？买了 3 条裤子退了 3 条裤子，买了 1 双凉鞋也退了 1 双凉鞋。不久的将来我可能就可以和收件的快递成为朋友了吧！

今年立秋后的重庆一直晴朗，雨很少。感觉都下到了我们的邻居四川去了，连续好几天的大雨涨洪不得了，记得 18 年那年夏天住在华新街，而工作在渝中区的嘉滨路，大概是下午 15.00 左右吧吹起了狂风，当时微博上有网友拍了一个观音桥步行街的一颗大树直接被大风连根拔起，后来大雨就来了，刮倒了好多电线杆和树，全城太多地方水电气受到了影响；人家政府的也忙不过来呀，于是下班了的时候雨停了但是交通瘫痪了全都堵在了路上，还好那一年住的地方距离上班大致上隔了一座渝澳大桥，看到这个场面于是我选择了走路回去。可能走了 40 分钟左右到家了。路上遇到全是被风雨打乱的电杆和树枝，大桥上，公交车师傅们拿着工具在捅桥上的排水洞，有些乘客堵着在车里难受，也出来在桥站着吹风看着嘉陵江，也许有些人很少这样看过吧，每天都在各自忙各自的，此时也不为一番享受。

那是我和大牛交往的第 2 年，那时租的三钢厂家属楼，是九几年的老房子没电梯，没独立厨房，也没独立的客厅在 5 楼。暴风雨后各自都安全到家了，家里停电了我们晚饭就煮了碗鱼汤面吃下了，没电脑玩手机也没法充电，虽然才下过一场大雨但是雨停后热浪依旧存在，我俩就只有憨憨的坐在窗户边的榻榻上背靠着衣柜门（没沙发衣柜门凉快），大牛一直拿着蒲扇给我打扇，等呀等呀来来回来大牛都洗了 2 次冷水澡还是热，我毕竟是个女生我是不可能洗冷水澡了，到了晚上 11.00 了还没来电，大牛就让我先睡觉明天还得上早班，于是我躺下了他在一边坐着一直给我扇着，慢慢的… 慢慢的…我就睡着了…

为什么中国的传统行业没人继承

Fri, 07 Aug 2020 01:55:44 GMT

今天在坐公交车上班的时候，看到重庆电视台推送的视频，一位小男孩在跟着自己的爸爸学京剧打鼓。

爸爸剧组有演出的时候，有时就会带上小男孩；表演者在台上唱着京剧，孩子在台子左边敲着小鼓，有时候一坐就是两小时。小男孩的爸妈说，孩子从小就喜欢打鼓，也打得挺好的，所以剧组经常带着一起出去表演，有时还会让他上台。

我看到这个视频就在想，小孩子的想法真天真啊；打鼓这件事，充其量是孩子对这件事充满好奇，毕竟小孩的好奇心和想法我们是无法捉摸的。但作为家长，应该理性的引导孩子的兴趣，当然我不是觉得打鼓有什么不好，不，我就是觉得打鼓不好。在这个时代，打鼓能给你带来什么。作为成年人，我想的不是什么继承中国传统文化之类的鬼话。我门应该关注的是他能给我带来什么；当你孩子真的从事这份行业的时候，在总加速师一尊大哥大革命似加速的今天，能养活自己吗？能养活孩子吗？能养活年迈的父母吗？

这是大脑里突然呈现出小时候父母常说的一句话：“这能当饭吃吗”。这话真的是要长大了有压力了才能理解他的含义。小孩子才靠兴趣做事情，大人应该考虑得失了。

这估计也是为什么中国那么多优秀的传统行业，却没有人愿意继承；因为这些大部分的传统行业，没办法给我们带来理想的报酬，只能是在自身条件充裕的情况下，当作额外的兴趣在延续罢了，始终难入主业。

再隔十年后，传统行业可能已不复存在了，但又有什么关系呢！说不定那时早已城春草木深了。

阿宝的感悟

Thu, 06 Aug 2020 06:58:46 GMT

阿宝一觉睡醒后的感悟，她就是这么可爱（配图为最近最喜欢的电影，这也是阿宝老了的样子，肯定的）。

午休的时候被窗户外的车流声吵醒了，点开手机看了一眼 13:49 分了，外面的知了声持续不断，抬头瞧了瞧对面的男同事人不见了，办公室的胥总也不在，左边的女同事依旧睡得很香。

这个烈日的午觉后劲让我脑壳有点昏，于是起身去接了杯水喝，回工位后发现没抽纸了。于是放下了水杯出了办公室去了前台拿了包抽纸，前台和两边办公区域的灯光很明亮，伙伴们都在忙自己的事情，包扣前台的妹妹也在小心翼翼的复印一张看着有点质感的证书（也许是某个新员工的毕业证吧）！这时一股凉凉涌上心头，我不如他们一天粘贴复制的数据中心，不如前台，更不如产品部门的人，技术部的就别提了吧！做着最难的职位，拿着最低的工资。

八月一号后为了想保住工资，每天发 100-200 条微信给客户推荐产品，以前5000 元一年现在 1999 一年也没人搭理我。离开前台后我到了走廊一阵热浪向我的身体扑来，妈呀！好热。换工作这个想法到此为止吧，，，

拿着纸的我回到了自己的办公室，推开了办公室的门，在黑黢黢的办公室打开了明亮的灯，刺醒了睡得很香的同事。

被我刺瞎的同事醒了后我对她说了句话:如果价格低都没人买，我们下个月就没法替家里省点电了。。。。。。。。。。

。。。。。。。。over ! !

相比如今公众号等大热的文字创作平台，你如何看待 Blog

Sat, 23 May 2020 03:51:06 GMT

在丝经济大行其道的今天，你是不是拥有自己的信息来源呢？原文摘抄自利器对 Typlog 作者的专访，推荐你前往这里查看完整的访谈记录（可能需翻墙）。

我喜欢个人博客，尤其是在这粉丝经济大行其道之时。我喜欢看作者们的生活思考或者技能分享，感受一个个活生生的人。看个人的真实想法，而非替粉丝的说话。现在大家越来越不怎么更新了，越发显得珍贵起来。

我尝订阅过几个公众号，后来都取消了。偶尔看看朋友圈，多数文章的标题都在叫唤着「快点我快点我」，但是并没有什么好看的；又有喜欢的朋友分享的文章，点开一看，不好意思，文章已经被屏蔽了，所以现在很少会看公众号文章。这并不是说公众号里没有好的内容，但是大多数文章都是糟糕的排版，各种表情包以及不相关的图片穿插于并没有什么价值的文字之间，所以多数时候也就懒得点开了。

有时在它处看到一篇还不错的文章，但是作者一直在文章里隔三差五地推销一下他的公众号，打断阅读思路，又在每篇文章里放上一个丑陋的二维码，所以越发反感公众号了。

中文世界最大的悲剧便是封闭。从国家到公司，从公司到个人，都在打造围墙，建起一个又一个圈子。因为封闭，没有长尾效应，大家的注意力都在当下，一个热点驱逐着另一个热点，没有积淀的走马观花。更悲哀的是整个世界都在向中国学习。

我不了解为何大家会去阅读公众号，我并不觉得有什么不能错过的内容。如果想获得的是知识，那读书是更好的选择。当然我也不觉得有什么错，每个人都有自己的习惯嘛。

我自己不用国内这些平台写作，一是想自己掌握自己的数据，二是不想去猜各个网站的敏感词都是哪些。我的博客是 Just lepture。

上面的链接可能需要代理，你也可以点击下面的备用链接。

矛盾的 50% 定律

Sat, 09 May 2020 14:10:40 GMT

我们都知道矛和盾的故事，但你要是不知道，那我先同步下认知线。

大概是这样的，一个楚国的商人，说自己的卖的矛无坚不摧，然后又说自己的盾坚不可摧；路人让其「以子之矛，陷子之盾，何如？」，结果商人弗能应也。

然后今天爬楼梯的时候我就在想。

如果我的矛把我的盾捅破了，我就连世界上最坚固的盾都能刺穿；
若是我的盾防下了矛的攻击，我就连世界上最锋利的矛都刺不穿我的盾；

那是不是怎么说都有 50% 是对的呢，只要你不连在一起看这件事就行了。

姑且就叫他矛盾的 50% 定律吧。

硅谷革命

Sat, 07 Mar 2020 11:19:10 GMT

终于看完了两年前就买下的这本书。很难想象，当初的这群狂热分子，竟然是这样做出世上最伟大的产品的。

真挺羡慕的，能置身那样的时代，参与划时代的产品开发。那时候的团队氛围和对产品艺术的追求，

Macintosh 则不同，它背后的驱动力主要还是来自艺术价值，它无视外部竞争，目的是要开发出一款非凡卓越的产品。

但放到现在来看，周围已经没有那样现实扭曲磁场能力的人了。并且当平台不够强大时，可能连物质生活都满意不了，还说什么理想呢。

或者说一些数据吧。

1981 年的乔布斯，开着保时捷，Macintosh 团队年薪较低的工程师 22000 美元。

2020 继续加油

Thu, 23 Jan 2020 16:14:23 GMT

眼看着就要过除夕啦，是时候把在 Bear 里只埋了标题的这篇文章写完啦。

总的来说，今年比 2018 年要过的充实，无论从工作中还是生活上，都越来越向理想的目标近了。

搬家

年初的时候，终于搬进了我们的新家。虽然房子是一年前就买下来的，但当时并没有装修，搁置了一年终于搬进来了。

搬进来就意味着要装修，装修这件事可是真累人；原本打算写篇文章纪念的，结果如你看到的，又只写了个开头。

峨眉山

5 月份的时候，我们去峨眉山看日出，这可能是今年最受屡的一次旅行了，不但天气不好下起了小雨，还忍受着累、饿、困、冷、信念崩塌等各种 debuff 缠身。

为了纪念这次不一样的出行，我还特意写了一篇文章：峨眉山的日出

换个角度看问题

8 月份的时候，作为技术支持，随着商务的同事一起去酉阳蝶石花谷；虽说并没有我什么事，但我还是想写写。

作为码农，不应该只关注属于自己模块的功能实现，最好把自己当作为一枚 project owner（虽说自己只是一个 programmer），并了解整个项目的各个周期。

就技术上来说，要学会像测试人员一样，清楚的知道系统的业务逻辑，并尝试自行 review 同伴的代码。如果你是一枚后段工程师，也可以尝试 review 下前端同伴的代码，看看他们都用了些什么黑科技，也能更方便的进行接口设计。

产品、原型、设计、架构、技术选型、编码、CICD 等。

拿工具说，若你们团队正在使用自动构建的工具，那你知道他的工作原理吗？要是让你自己搭建一个类似的工具，或是写个类似的 workflow，如何操作呢？

从产品来看的话，尝试了解下客户的真实需求，了解下业类成熟的解决方案。并不是所有需求都需要编码才能实现的，有时候引导下客户，说不定技术上很难解决的问题，客户其实根本就不咳er。

三亚

快年底的时候，终于完成了多年的一个愿望————带着爸妈去看海。

原打算带他们去北京的，因为在我看来，老一辈的人对北京都有一种说不清的情节。但当询问了爸妈的意见后，他们居然选择了三亚。

这趟旅行很开心，回程的路上老妈还有点宁宁不舍，多半是因为我没让她买景区里她看中的纪念品；下次带老人出去玩的时候，站在他们的角度多想想，别管它是假的还是贵的了。

技术

技术方面，今年的技术并没有什么大的提升。虽说从年中开始，就开始尝试用 kubernetes 来部署生产环境应用。但在我看来，不过是在腾讯云提供的上层建筑上修修改改，对底层的逻辑一知半会，如：

Service 的工作原理
Kubernetes 的负载均衡是如何实现的
容器内的网络、DNS是如何工作的
master 节点的调度原理
PV、PVB 的设计

但也不到不说，从开始使用 kubernetes 以来，一些以前不清楚的逻辑也慢慢清晰出来。

容器的工作原理
如何写一个 Dockerfile
用 namespace 和 cgroup 如何实现一个容器
镜像的分层设计及文件的联合挂载
Deployment 是如何控制 POD 按期望的方式运行的

其他技术，由于今年交付项目周期太紧，涉及的就太少了，但对 Laravel 的使用程度正在逐步提升，希望明年能成为一个贡献者。

TODO 2020

在过去的 2019 年，工作方面我自认为还是比较努力的，但年底突然醒悟，发现有很多方面做的都不是很完善，总结下今年的不足，给来年定几个 flag 吧。

最后一点，还是要多说话，多说话，多说话，自信一点。

基于雪花算法的 PHP ID 生成器

Tue, 13 Aug 2019 05:07:09 GMT

Snowflake 是 Twitter 内部的一个 ID 生算法，可以通过一些简单的规则保证在大规模分布式情况下生成唯一的 ID 号码。

其组成为：

第一个 bit 为未使用的符号位。
第二部分由 41 位的时间戳（毫秒）构成，他的取值是当前时间相对于某一时间的偏移量。
第三部分和第四部分的 5 个 bit 位表示数据中心和机器ID，其能表示的最大值为 2^5 -1 = 31；
最后部分由 12 个 bit 组成，其表示每个工作节点每毫秒生成的序列号 ID，同一毫秒内最多可生成 2^12 -1 即 4095 个 ID。

需要注意的是：

在分布式环境中，5 个 bit 位的 datacenter 和 worker 表示最多能部署 31 个数据中心，每个数据中心最多可部署 31 台节点。
41 位的二进制长度最多能表示 2^41 -1 毫秒即 69 年，所以雪花算法最多能正常使用 69 年，为了能最大限度的使用该算法，你应该为其指定一个开始时间。

由上可知，雪花算法生成的 ID 并不能保证唯一，如当两个不同请求同一时刻进入相同的数据中心的相同节点时，而此时该节点生成的 sequence 又是相同时，就会导致生成的 ID 重复。

所以要想使用雪花算法生成唯一的 ID，就需要保证同一节点同一毫秒内生成的序列号是唯一的。基于此，我们在 SDK 中集成了多种序列号提供者：

RandomSequenceResolver（随机生成）
RedisSequenceResolver （基于 redis psetex 和 incrby 生成）
LaravelSequenceResolver（基于 redis psetex 和 incrby 生成）
SwooleSequenceResolver（基于 swoole_lock 锁）

不同的提供者只需要保证同一毫秒生成的序列号不同，就能得到唯一的 ID。

要求

PHP >= 7.0
Composer

安装

$ composer require godruoyi/php-snowflake -vvv

使用

简单使用.

$snowflake = new \Godruoyi\Snowflake\Snowflake;
 
$snowflake->id();
// 1537200202186752

指定数据中心ID及机器ID.

$snowflake = new \Godruoyi\Snowflake\Snowflake($datacenterId, $workerId);
 
$snowflake->id();

指定开始时间.

$snowflake = new \Godruoyi\Snowflake\Snowflake;
$snowflake->setStartTimeStamp(strtotime('2019-09-09')*1000);
 
$snowflake->id();

高级

在 Laravel 中使用

因为 SDK 相对简单，我们并没有提供 Laravel 的扩展包，你可通过下面的方式快速集成到 Laravel 中。

// App\Providers\AppServiceProvider
 
use Godruoyi\Snowflake\Snowflake;
use Godruoyi\Snowflake\LaravelSequenceResolver;
 
class AppServiceProvider extends ServiceProvider
{
    /**
     * Register any application services.
     *
     * @return void
     */
    public function register()
    {
        $this->app->singleton('snowflake', function () {
            return (new Snowflake())
                ->setStartTimeStamp(strtotime('2019-10-10')*1000)
                ->setSequenceResolver(new LaravelSequenceResolver($this->app->get('cache')->store()));
        });
    }
}

自定义序列号解决器

你可以通过实现 Godruoyi\Snowflake\SequenceResolver 接口来自定义序列号解决器。

class YourSequence implements SequenceResolver
{
    /**
     *  {@inheritdoc}
     */
    public function sequence(int $currentTime)
    {
          // Just test.
        return mt_rand(0, 1);
    }
}
 
// usage
 
$snowflake->setSequenceResolver(new YourSequence);
$snowflake->id();

你也可以直接使用闭包：

$snowflake = new \Godruoyi\Snowflake\Snowflake;
$snowflake->setSequenceResolver(function ($currentTime) {
    static $lastTime;
    static $sequence;
 
    if ($lastTime == $currentTime) {
        ++$sequence;
    }
 
    $lastTime = $currentTime;
 
    return $sequence;
})->id();

如果您在使用过程中遇到任何问题，欢迎提交「PR」。

少平和晓霞的故事

Fri, 02 Aug 2019 13:11:18 GMT

原文发布于我的 qzone，仅以此纪念我逝去的晓霞。

我们中学时代最后一天的最后一堂课结束了。虽然前面仍有漫长而艰难的考试，但是中学的课程再也没有了，往后将是讲座、讨论会、或参加就某一问题的学术研究，全是成年人的字眼。

热尼娅·鲁米扬采娃朝教室里探了探头：

谢廖沙，打扰你一会儿行吗？

我走到走廊里。在这不寻常的日子里，热尼娅也显得与往常不太一样了。她的衣着象往常一样有些古怪：

那条去年就显小了的连衣裙，短得遮不住膝盖
外面套着一件瘦小得连胸前都扣不拢的毛衣，里面衬着洗旧了的白绸衫
脚穿一双圆头平底童皮鞋——这身打扮象是从她妹妹那儿拿来的
她那头浓密的淡灰色的柔发虽用许多发卡和小梳子勉强别住，但还是散落了下来，遮住了她的前额和面颊
而且有一缕额发时常垂落到她那短小的鼻子上，总惹得她气恼地把它撩开

与往常不同的是，她面颊上泛出一层淡淡的红晕，那双忽而严肃正经、忽而漫不经心的灰色大眼睛里，闪耀着生气勃勃、亲切动人的光芒。

谢廖沙，我有句话想跟你说：咱们俩十年以后再见面吧？

热尼娅从来不开玩笑，所以我也一本正经地问：

为什么？

因为我想知道，你将来能成为一个什么样的人。

热尼娅把那缕垂在短鼻子上的头发甩开

知道吗，这几年来，我一直很喜欢你。

热尼娅，你为什么早不对我说呢？我问。

早说有什么用？当时你那么喜欢尼娜！

我顿时感到，一种莫名的沮丧和忧悒袭上心头，仿佛失去了什么一般。

那我们何时何地再见面呢？我又问。

十年以后的五月二十九日，晚上八点。在大剧院正中的两根圆柱之间。

要是那儿的圆柱配不成双怎么办？

那儿只有八根圆柱，谢廖扎……到那时，我就是一个著名的天文学家。

她又郑重、自豪、十分自信地补充了一句：

如果我变化很大，你就凭报上登出的照片来认我吧。

那时候，我也会成名。

刚说到这儿，我倏地停住了——我根本没想过，将来我会在哪个领域成名，甚至连报考哪个系我还没决定呢。

不管怎么说，我一定开着自己的小汽车去……。

这个回答实在可笑，然而我却找不出更合适的话来。

好极了，热尼娅笑了，那你就开着带我去满城兜风……

光阴荏苒，转瞬已过多年。一九四四年夏，我住在野战医院，从收音机里听到了授予空军少校热尼娅·鲁米扬采娃苏联英雄称号的命令。

生活的道路不断向前伸展。有时我会蓦地想到我们约定的那件事，尤其是在约期临近的几天里，我有一种强烈的忧悒和不安压在心头，仿佛我熬过的所有岁月，都是为了这次约会。

我没有成名，没能兑现向热尼娅许下的诺言，但是还有一点我没有失信：

我在一堆缴获的汽车当中，以廉价买了一部旧奥佩尔。我换上一套簇新的衣服，开着奥佩尔向大剧院驶去。

假如那次真的能见到热尼娅，我就会对她这么说，我经过无数次的彷徨，终于找到了自己的道路，

我把汽车停在街心花园旁边，向卖花女人买了一束铃兰，朝大剧院正中央的两根圆柱走去。那儿果真有八根柱子。我在那儿伫立片刻，把铃兰献给了一位脚穿运动鞋，身材纤瘦的灰眼睛姑娘，然后驱车回家去了。

我真想让时光在霎那间停止流逝，让我回顾一下那逝去的年华和我自己，让我看一眼那身穿短连衣裙、外套绒衫的少女；

找回那颗蒙昧无知的少年的心，这颗心曾轻易地错过了决定命运的时刻，轻易的错过了我一生中本来可以获得的欢乐和幸福-----致晓霞

Nginx 配置二级目录支持

Mon, 03 Jun 2019 03:25:20 GMT

Nginx 配置二级目录并不像 apache 那么简单，但二级目录的配置在实际工作中又经常用到，现整理如下。

在 /etc/nginx 目录下创建文件夹 sublocations，用于存放所有二级目录的配置：

sudo mkdir -p /etc/nginx/sublocations

在该目录下配置二级目录配置文件（如你想配置的二级目录为 example.com/bbs）：

# /etc/nginx/sublocations/bbs.conf
 
location ^~ /bbs {
    alias "/your/bbs/project/path";
    index index.php;
 
    try_files $uri $uri/ @bbs;
 
    # 引入解析配置
    include snippets/php_parse_for_sublocation.conf;
}
 
location @bbs {
    rewrite /bbs/(.*)$ /bbs/index.php?/$1 last;
}

配置针对二级目录的解析文件，不同的语言可配置不同的 CGI 解析，下面是 PHP 的解析配置：

# /etc/nginx/snippets/php_parse_for_sublocation.conf
 
# pass PHP scripts to FastCGI server
location ~ \.php$ {
    fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
 
    # 注意这里的 SCRIPT_FILENAME
    fastcgi_param SCRIPT_FILENAME $request_filename;
 
    fastcgi_intercept_errors off;
    fastcgi_buffer_size 16k;
    fastcgi_buffers 4 16k;
    fastcgi_connect_timeout 300;
    fastcgi_send_timeout 300;
    fastcgi_read_timeout 300;
}

server {
    # ....
 
    server_name example.com;
	
    location / {
        try_files $uri $uri/ 404;
    }
 
    # 引入二级目录配置
    include sublocations/tianyou.conf;
 
    # ....
}

测试配置成功并重启服务后，就能通过二级目录 example.com/bbs 访问到对应的服务了。

sudo nginx -t         # 测试配置是否成功
sudo nginx -s reload  # 重启服务

更多 Nginx 的配置请参考：

Nginx 配置跨越支持

Mon, 27 May 2019 07:24:26 GMT

用你最美的姿态，去「跨域」那座山。

在日常的开放中，我们经常遇到跨域的问题，常用的处理方式都是在代码层添加 cors 支持，但若你有 Nginx 配置权限，在 Nginx 上处理跨域将使得程序异常简单和高效。

代理

假设我们的前端域名为 example.com，API 服务架设在 api.example.com 域名下，那我们可以通过代理的形式来配置跨越请求，具体的配置为：

在 Nginx 的 example.com 虚拟主机文件中配置如下的代理
配置成功重启后，前端即可用 example.com/api 的方式和 API 交互

# /etc/nginx/sites-enabled/example.com.conf

location /api/ {
    proxy_pass http://api.example.com/;    
}

这种方式的原理是将 API 提供的服务，代理到前端域名的二级目录下，从而避免跨域。

Response Header

当然由于很多情况下我们不想将服务代理到前端域名二级目下，那可以通过在 Http Response 中添加 Header 来解决跨越，具体配置如下：

# /etc/nginx/snippets/cors.conf;
 
if ($request_method = 'OPTIONS') {
    add_header 'Access-Control-Allow-Origin' '*' always;
    add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE' always;
    add_header 'Access-Control-Allow-Headers' 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization,Content-Disposition' always;
    add_header 'Access-Control-Max-Age' 1728000 always;
 
    add_header 'Content-Length' 0;
    add_header 'Content-Type' 'text/plain; charset=utf-8';
 
    return 204;
}
 
if ($request_method ~* "(GET|POST|DELETE|PUT)") {
    add_header 'Access-Control-Allow-Origin' '*' always;
}

关于何时会发起 OPTIONS 请求及 OPTIONS 请求的内容，可参考阮老师的这篇文章—— 跨域资源共享 CORS 详解

然后在 API 服务域名下添加 CORS 支持即可

# /etc/nginx/sites-enabled/api.example.com.conf
 
location / {
    try_files $uri $uri/ /index.php?$query_string;
}
 
location ~ \.php$ {
    // 引入 cors 配置
    include snippets/cors.conf;
 
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
    ...
    ...
}

注意 include snippets/cors.conf 这段代码的位置，若直接放在 location 中，是不起作用的，如下所示：

location / {
    include snippets/cors.conf;
 
    try_files $uri $uri/ /index.php?$query_string;
}

这是因为下面的 try_files 将请求 Forward 到了 location ~ \.php$ 这个 block 下，在此之前添加的 add_header 命令是无效的。

enjoy ～_～

峨眉⼭的⽇出

Wed, 22 May 2019 12:03:18 GMT

上个周末，和⽼婆及阿婷们⼀起去峨眉⼭看⽇出。虽然结局很悲惨，过程也悲惨，却并⾮那么不如⼈意，写下来权当是安慰我们的这次旅⾏吧。

出发

周末两天峨眉⼭的天⽓其实不那么好，持续着今年的阴⾬⻤鬼天⽓。但不知道什么原因驱使着我们，还义⽆反顾的选择沐浴。我猜不可能是爱，可能是积压了好久的⾏程需要释放吧。

从重庆出发，下午 13:30 左右我们就到了峨眉⼭⼭脚。四个⼈浑浑噩噩的吃完⼀顿饭，就坐⻋到 五显岗 准备爬⼭了。

燃烧的卡路⾥

从 五显岗 ⾛了⼤约 2KM，才到我们今天爬⼭的起点 清⾳阁。在门口的空地上，坐着很多「滑工」。

以前我觉得，爬⼭这种事⼉，怎么能去坐滑杆呢。⼀个是毫⽆意义，二是⾟苦底下抬滑竿的⼈。可现在⼀想啊，你付出了你的劳动，收获了相应甚⾄更多的报酬，那我还有什么值得怜悯的呢，就像外卖一样，我付钱点的外卖，~~你凭什么让我说谢谢呢~~，每个辛勤劳动的人，都值得你为他说些谢谢，连波啊连波，你当时在想什么呢，说出这么混账的话。

人啊，真是越活越没⼼没肺了

到 清⾳阁 后，已经快下午 16:00 了，从这里开始，有两条⼭路可以进⼭；门口的老阿姨告诉我们，无论你们今天选什么线路，都是不可能徒步走到终点「雷洞庭」的。因为即使走短线，也要近 8 个小时，按 20:00 点天黑算的话，我们要走到凌晨 00:00 才能到达目的地，需要走近 4 个小时的夜路。

我其实是一直想挑战「长线」的，但「长线」的路程大约有 40km，肯定是被老婆无情的拒绝了，她说你就是不知天高地厚。

从清音阁开始到我们的终点「雷洞庭」大约有 20km 的距离。按照「正常」速度的话大约 4 个小时就能走到终点。但是我要是告诉你都是这种路的话，你还会选择往上爬吗？

40 分钟后，我们到达了第一个地点——「万年寺」，这时候天还没下雨，人还很燥热，体力还很充沛。

下午 17:30 左右，我们爬上了「观心坡」，雨这时已经越下越大，两位女性同志的小腿开始颤抖，保温杯里的水已近底；店家的脉动要买 10 块钱一瓶，好在有夫妻住店，才以他们的名义打得一瓶开水。

18:30 左右，我们在沿途的店家休息了下来，这个点儿，大部分店家都准备下山了；点了两碗蛋炒饭，店主的蛋炒饭是用韭菜混合炒的，这是吃过最香的炒饭了。再来了一瓶红牛，一只手电，骈了两根登山棍后，我们又继续上路了。

19:30，我们来到了「长老坪」，这里的视线比较好，但是店家已经关门下山了，我们连选择高价脉动的权利都丧失了。

20:12，天已经黑下来了，你依旧能看到持续上升的阶梯，和我鬼畜一般的脸。

21:00 左右，爬山还在进行，这时候必须得打手电了，背包里的棒棒糖早已吃完，吃了一块豆干后，每个人都像打了鸡血样，持续不断的前进着。

凌晨 00:00，我们终于到了「洗象池」，虽说叫洗象池，但其实是一个寺庙，门口的路灯发着微弱的光，店里还有两位值夜班的阿姨。在寺里吃完最后一块豆干后，雨却越下越大了，等了近半个小时，却没有丝毫减弱的痕迹。向阿姨买了泡面，四个人狼吞虎咽的吃了起来，多希望有个火腿，然而寺庙好像只吃素。

从这里到我们的终点雷洞庭还有 2 个多小时的路程，由于雨还在下，大家都动摇了起来。于是我们躺了下来。

凌晨 03:00，闹钟响了，按照昨晚的约定，要是没下雨的话，我们将继续起来赶路。但屋外还依旧下着大雨，墨迹了大半天，快四点的时候，四人终于满脸疲惫的上路了；这是天还很黑，雨还是很大。

凌晨 06:00 ，天渐渐亮了，雨也慢慢停了下来。阿宝披着破洞百出的雨衣，在风中凌乱着；到了凌晨 06:30 的时候，我们终于到了雷洞庭，吃了碗三两的小面，住进了昨晚未来得及入住的酒店。

金顶

上午 09:00，我们终于到了金顶，那天的金顶，风景格外美丽，连周围不安稳的风，都在四处炫耀着他的美。

可能我们四个这辈子都不会想再经历这样的经验了，从第一天下午 16:00 算起，到爬上金顶，除去中途躺下的三个小时，我们走了 10 多个小时。

下山的时候我对阿宝说：

阿宝，下次我们还要来，到时候直接坐车到雷洞庭，我再也不想爬这个山了。

遗憾肯定是有的，没有看到日出，没有看到云海，连猴子都没来抢阿宝红色的背包。但可能旅行就是这样吧。

唐玄奘的由来

Thu, 28 Mar 2019 05:23:11 GMT

这篇短文是前年（2017）年去婺源路上看《西游记》时写的，现重新整理并发布到我的博客。

时阿阿瓶登位，天下太平，人才短缺。故大力招聘 PHP 。

重庆有一人，姓陈名萼，字光蕊，见到该招聘信息，告其母，前去长安面试，一面就过，七险一金，年底分红。

皇帝御笔亲赐状元。游街三日，未曾想游到丞相门。相有一女，小名温娇，又名满堂娇，未婚。正在抛球择夫，见光蕊形似徐公（徐公，重庆之美丽者也），问其下人，实乃公务员。一球进洞，当日完婚。

次日皇帝封光蕊为温州洲主，随妻回家接母往温州上任。走了几天，行至万花店刘小二家落脚。母亲久病缠身，光蕊听闻外面买鱼。想着给母亲做一条炝锅鱼。这鱼却闪闪发光，绝非等闲，赶紧放回洪江。

母亲久病缠身不能前行，八百块租了间一室一厅。拜辞而去。明天上线，熬夜前行，到洪江渡口，有船夫刘洪，李彪二人。看到夫人长得好看，行船至没人烟处，杀其夫，坠入江。温娇望其夫已死，欲跳江中，刘洪一把抓住并挟持道。你若从我，万事皆休，你若不从，哼哼哈嘿。

时温娇已怀有身孕，无计可施，只得权时应承，顺了刘洪。刘洪拿着 offer 就前往温州任职。

光蕊尸体坠入江低，被一只螃蟹发现，告龙王。龙王一看，救命恩人矣；原来龙王就是那条鱼。寻其灵魂，喝点汤水，活了，光蕊诉其缘由。龙王告知勿忧，将其放入冰箱里，待其夫妇团聚再出。

话说温娇跟着刘洪在温州入职就定。而肚子也越来越大，一天，做一梦。梦说「此子必成大器，刘贼若回，必害其子」。温娇待孩子生下后，用栏栏装起，藏一血书，放入洪江，冲走了。

孩子冲到金山寺，被一和尚捡到，唤乳名江流。

十八年过后……

孩子已经长大，和尚又为他消发修行，取发名玄奘！！

About Godruoyi

Tue, 26 Mar 2019 18:00:48 GMT

Godruoyi，15 年毕业于西南大学计算机专业，Laravel 爱好者；目前靠 Go 养家糊口，抽空学习 Rust，全职远程中。由于看起来像二愣，说起话来也像二愣，朋友们都叫我二愣。

喜欢捣鼓各种工具，但效率也不高；喜欢买书，一定是纸质书籍，爱看小文学，伪文艺青年，你也可以查看我的阅读清单；性格有点内向，喜欢写写写写，虽然文笔也不好，~~有时候~~很多时候都爱发发闹骚，我的 GitHub https://github.com/godruoyi。

如果你想了解我更多的信息，这里有一些我觉得写得还不错的文章，http://godruoyi.com/posts#selected-articel 。

注：我使用 Bear 写每一篇博客，所有的博客内容均没有 AI 参与。

折腾 & 其他

🧚🏾 The Best Image OCR SDK For BAT 集成腾讯、阿里、百度的文字识别 SDK
📦 一个简单的依赖注入容器（from Laravel Container）
🍡 Laravel tips in terminal
🥑 Laravel Tips In Raycast
❄️ 雪花算法的 PHP 实现
🌨️ 雪花算法的 Golang 实现
🌰 Wakeup Use AI to create admirable images to surprise your every morning
📰 RESTful API 设计规范
🐶 Readog is a browser extension that can save your links to any platform
🎈 An beautiful blog built with Astro
🐝 An Raycast extension that allows you to process images using a customizable workflow

关于这个博客

六年前我将我的博客迁移到 Laravel & Vue 平台，更早的博客文章在迁移过程中丢失，你可以从这里看到这里当时的记录。最近我又将博客迁移到 Astro 平台(见Blog 的延续)，评论数据又丢了，好在是博客内容现在已经全部托管到 GitHub，这次该是丢不了了。

如果你喜欢这个博客，你可以参考这个仓库一键部署一个你自己的。

联系我

最近经常在刷推，你也可以在下面的网站或联系方式中找到我。

Email: godruoyi@gmail.com
WechatID: Youji_
Laravel China

容器的工作原理和隔离机制

Sun, 21 Oct 2018 11:50:15 GMT

由于自己最近在学习 @张磊老师的 Kubernetes 专栏，以下内容均来自每节专栏学习后的感悟、总结。张老师的Kubernetes专栏通俗易懂，欢迎大家跟我一起加入学习。

容器的本质

容器的本质是一个进程，进程与进程之间相互隔离造就了容器与容器互不影响的特性。在启动一个容器（即创建一个进程时），通过 Namespace 技术实现容器的隔离、通过Cgroups 来实现容器的资源控制。

Namespace

容器进程的创建通过 Linux 平台下的 clone 方法创建，在调用该方法创建进程时，通过指定额外的 Namespace 参数，使得刚创建的进程属于一个独立的空间。

int pid = clone(main_function, stack_size, CLONE_NEWPID | SIGCHLD, NULL)

指定额外参数 CLONE_NEWPID 创建的新进程，有一个自己的 独立进程空间，在这个空间里，它的进程 ID 为 1。它既看不到其在宿主机的真正进程、也看不到其他容器的进程。

其实这都是假象，创建的该进程在宿主机上是真实存在的，并且也受宿主机的管理和控制，也享受宿主机的资源。但在该进程内部，它处于一个独立的空间，只看得到该进程一个资源，让其误以为自己处于一个密闭的 盒子 内。这

这，就是 Linux 容器最基本的实现原理了！

你可能也注意到了，虽然通过 Linux Namespace 技术实现了进程的相互隔离，但这种隔离机制只是为不同的容器进程指定不同的 namespace，但不同的容器进程其实在宿主机上是真实存在的，并且也使用相同的宿主机内核。这也是容器在和虚拟化技术相比下，隔离得不够彻底的原因。

Cgroups

容器进程创建好后，若不进行其他处理，该进程运行时所消耗及占用的资源（如 CPU、内存）等；是可以被其他宿主机进程或其他容器进程享用的。为了解决这个问题，Linux 容器设计中引入了 Cgroups 的概念。

Linux Cgroups 的全称是 Linux Control Group，它的主要作用就是限制一个进程能够使用的资源上限（如 cpu、内存、网络等）。

在 Linux 中，Cgroups 给用户暴露出来的操作接口是文件系统，即它以文件和目录的方式组织在操作系统的 /sys/fs/cgroup 路径下。

若你的系统中没有挂载该目录，那你需要自行 google 挂载。

在该目录下，你可以看到很多诸如 cpuset、cpu、 memory 这样的子目录，也叫子系统。每个目录下面又有很多配置文件。如你可能在 cpu 目录下看到诸如 cfs_period 和 cfs_quota 这样的配置文件。而这两个配置文件，是限制 CPU 使用率的关键配置项。

这两个参数需要组合使用，可以用来限制进程在长度为 cfs_period 的一段时间内，只能被分配到总量为 cfs_quota 的 CPU 时间。其中 period 的默认值为 100 ms（毫秒），quota 的默认值为 -1，即不做限制。当修改 quota 的值为 20 ms 时，表示在 100ms 的时间范围内，cpu 只能使用 20 ms。也就是说，cpu 的使用率最大为 20%。

上面说到，容器启动后的进程我们需要用 Linux Cgroups 来限制其资源的访问。接下来我们看看到底是如何进行控制的。

我们在 /sys/fs/cgroup/cpu 目录下创建一个文件夹:

可以看到，我们创建的文件夹里面已经被系统默认创建了一些配置文件。我们把这样一个目录叫做控制组，接下来修改这个控制组的 cpu 使用率为 20% 。

我们在命令行用一个死循环来测试，也使得该进程能占用全部的 CPU。

通过 top 参数，我们看到该进程 5451 的 cpu 使用率已经达到 99.3%；由于我们创建该进程时，没有为其指定一个控制组时，他默认将享用全部的 cpu 及内存配置。接下老我们将该进程通过下面的命令加入到刚刚创建的 container 组中去。

$ echo 5451 > /sys/fs/cgroup/cpu/container/tasks

将改进程加入控制组后，改进程的 cpu 使用率一下就从原来的 100% 降到了 20% 左右。

在 docker 中，我们可以在启动容器的时候，指定 cpu 参数来控制该容器的资源占用，如下所示，这样启动的 docker 容器，只能使用 20% 的 cpu。

Docker run -it --cpu-period=100000 --cpu-quota=20000 ubuntu /bin/bash

当然，通过 Linux Cgroups 还可以限制其他参数，如网络、挂载点、内存等等。

今天就学到这儿了，明天继续吧！！！

为你的 Laravel Faker 指定中文支持

Fri, 27 Jul 2018 09:13:30 GMT

Laravel Faker

在 Laravel 中使用 Faker 构造假数据时，默认的输出为英文格式，如下

可通过在 config/app.php 增加如下配置使其支持中文。

'faker_locale' => 'zh_CN',

修改后再次执行效果如下：

今天在使用 Faker 构造数据时，纳闷为什么不能是中文，查看官方扩展包原来早就支持了啊。（是我孤陋寡闻了呀，赶紧分享给没发现的同学）

目前 Laravel >= 5.7 已经在 config\app.php 中默认添加了 faker_locale 配置。

Laravel DatabaseServiceProvider

Laravel 源码中是在 DatabaseServiceProvider 中注册的国际化支持。

// vendor/laravel/framework/src/Illuminate/Database/DatabaseServiceProvider.php
 
protected function registerEloquentFactory()
{
    $this->app->singleton(FakerGenerator::class, function ($app) {
        return FakerFactory::create($app['config']->get('app.faker_locale', 'en_US'));
    });
 
    $this->app->singleton(EloquentFactory::class, function ($app) {
        return EloquentFactory::construct(
            $app->make(FakerGenerator::class), $this->app->databasePath('factories')
        );
    });
}

RESTful API 设计规范

Sun, 24 Jun 2018 13:41:48 GMT

本文是为大渝网 API 开发规范拟定的一个 beta 版，文章大量参考了目前比较常见的 RESTful API 设计。

为了更好的讨论规范带来的争议及问题，现已把该文档整理并开源到 GitHub，关于大家补充及提问。

关于「能愿动词」的使用

为了避免歧义，文档大量使用了「能愿动词」，对应的解释如下：

必须 (MUST)：绝对，严格遵循，请照做，无条件遵守；
一定不可 (MUST NOT)：禁令，严令禁止；
应该 (SHOULD) ：强烈建议这样做，但是不强求；
不该 (SHOULD NOT)：强烈不建议这样做，但是不强求；
可以 (MAY) 和 可选 (OPTIONAL) ：选择性高一点，在这个文档内，此词语使用较少；

参见：RFC 2119

Protocol

客户端在通过 API 与后端服务通信的过程中，应该 使用 HTTPS 协议。

API Root URL

API 的根入口点应尽可能保持足够简单，这里有两个常见的 URL 根例子：

api.example.com/*
example.com/api/*

如果你的应用很庞大或者你预计它将会变的很庞大，那 应该 将 API 放到子域下（api.example.com）。这种做法可以保持某些规模化上的灵活性。

Versioning

所有的 API 必须保持向后兼容，你 必须 在引入新版本 API 的同时确保旧版本 API 仍然可用。所以 应该 为其提供版本支持。

目前比较常见的两种版本号形式：

在 URL 中嵌入版本编号

api.example.com/v1/*

这种做法是版本号直观、易于调试；另一种做法是，将版本号放在 HTTP Header 头中：

通过媒体类型来指定版本信息

Accept: application/vnd.example.com.v1+json

其中 vnd 表示 Standards Tree 标准树类型，有三个不同的树: x，prs 和 vnd。你使用的标准树需要取决于你开发的项目

未注册的树（x）主要表示本地和私有环境
私有树（prs）主要表示没有商业发布的项目
供应商树（vnd）主要表示公开发布的项目

后面几个参数依次为应用名称（一般为应用域名）、版本号、期望的返回格式。

至于具体把版本号放在什么地方，这个问题一直存在很大的争议，但由于我们大多数时间都在使用 Laravel 开发，应该 使用 dingo/api 来快速构建应用，它采用第二种方式来管理 API 版本，并且已集成了标准的 HTTP Response。

Endpoints

端点就是指向特定资源或资源集合的 URL。在端点的设计中，你 必须 遵守下列约定：

URL 的命名 必须 全部小写
URL 中资源（resource）的命名 必须 是名词，并且 必须 是复数形式
必须 优先使用 Restful 类型的 URL
URL 必须 是易读的
URL 一定不可 暴露服务器架构

至于 URL 是否必须使用连字符（-）或下划线（_），不做硬性规定，但 必须 根据团队情况统一一种风格。

来看一个反例

再来看一个正列

HTTP 动词

对于资源的具体操作类型，由 HTTP 动词表示。常用的 HTTP 动词有下面五个（括号里是对应的 SQL 命令）。

GET（SELECT）：从服务器取出资源（一项或多项）。
POST（CREATE）：在服务器新建一个资源。
PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。
PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性）。
DELETE（DELETE）：从服务器删除资源。

其中

删除资源 必须 用 DELETE 方法
创建新的资源 必须 使用 POST 方法
更新资源 应该 使用 PUT 方法
获取资源信息 必须 使用 GET 方法

针对每一个端点来说，下面列出所有可行的 HTTP 动词和端点的组合

请求方法	URL	描述
GET	/zoos	列出所有的动物园(ID和名称，不要太详细)
POST	/zoos	新增一个新的动物园
GET	/zoos/{zoo}	获取指定动物园详情
PUT	/zoos/{zoo}	更新指定动物园(整个对象)
PATCH	/zoos/{zoo}	更新动物园(部分对象)
DELETE	/zoos/{zoo}	删除指定动物园
GET	/animal_types	获取所有动物类型(ID和名称，不要太详细)
GET	/animal_types/{type}	获取指定的动物类型详情
GET	/employees	检索整个雇员列表
GET	/employees/{employee}	检索指定特定的员工
GET	/zoos/{zoo}/employees	检索在这个动物园工作的雇员的名单(身份证和姓名)
POST	/employees	新增指定新员工
POST	/zoos/{zoo}/employees	在特定的动物园雇佣一名员工
DELETE	/zoos/{zoo}/employees/{employee}	从某个动物园解雇一名员工

超出 RESTful 端点的，应该 模仿上表的方式来定义端点。

Filtering

如果记录数量很多，服务器不可能都将它们返回给用户。API 应该 提供参数，过滤返回结果。下面是一些常见的参数。

?limit=10：指定返回记录的数量
?offset=10：指定返回记录的开始位置。
?page=2&per_page=100：指定第几页，以及每页的记录数。
?sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序。
?animal_type_id=1：指定筛选条件

所有 URL 参数 必须 是全小写，必须 使用下划线类型的参数形式。

分页参数 必须 固定为 page、per_page

经常使用的、复杂的查询 应该 标签化，降低维护成本。如

GET /trades?status=closed&sort=sortby=name&order=asc
 
# 可为其定制快捷方式
GET /trades/recently_closed

Authentication

应该 使用 OAuth2.0 的方式为 API 调用者提供登录认证。必须 先通过登录接口获取 Access Token 后再通过该 token 调用需要身份认证的 API。

Oauth 的端点设计示列

RFC 6749 /token
Twitter /oauth2/token
Fackbook /oauth/access_token
Google /o/oauth2/token
Github /login/oauth/access_token
Instagram /oauth/authorize

客户端在获得 access token 的同时 必须 在响应中包含一个名为 expires_in 的数据，它表示当前获得的 token 会在多少 秒 后失效。

{
    "access_token": "token....",
    "token_type": "Bearer",
    "expires_in": 3600
}

客户端在请求需要认证的 API 时，必须 在请求头 Authorization 中带上 access_token。

Authorization: Bearer token...

当超过指定的秒数后，access token 就会过期，再次用过期/或无效的 token 访问时，服务端 应该 返回 invalid_token 的错误或 401 错误码。

HTTP/1.1 401 Unauthorized
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
 
{
    "error": "invalid_token"
}

Laravel 开发中，应该 使用 JWT 来为管理你的 Token，并且 一定不可 在 api 中间件中开启请求 session。

Response

所有的 API 响应，必须 遵守 HTTP 设计规范，必须 选择合适的 HTTP 状态码。一定不可 所有接口都返回状态码为 200 的 HTTP 响应，如：

HTTP/1.1 200 ok
Content-Type: application/json
Server: example.com
 
{
    "code": 0,
    "msg": "success",
    "data": {
        "username": "username"
    }
}

或

HTTP/1.1 200 ok
Content-Type: application/json
Server: example.com
 
{
    "code": -1,
    "msg": "该活动不存在",
}

下表列举了常见的 HTTP 状态码

状态码	描述
1xx	代表请求已被接受，需要继续处理
2xx	请求已成功，请求所希望的响应头或数据体将随此响应返回
3xx	重定向
4xx	客户端原因引起的错误
5xx	服务端原因引起的错误

只有来自客户端的请求被正确的处理后才能返回 2xx 的响应，所以当 API 返回 2xx 类型的状态码时，前端 必须 认定该请求已处理成功。

必须强调的是，所有 API 一定不可 返回 1xx 类型的状态码。当 API 发生错误时，必须 返回出错时的详细信息。目前常见返回错误信息的方法有两种：

1、将错误详细放入 HTTP 响应首部；

X-MYNAME-ERROR-CODE: 4001
X-MYNAME-ERROR-MESSAGE: Bad authentication token
X-MYNAME-ERROR-INFO: http://docs.example.com/api/v1/authentication

2、直接放入响应实体中；

HTTP/1.1 401 Unauthorized
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 10:02:59 GMT
Connection: keep-alive
 
{"error_code":40100,"message":"Unauthorized"}

考虑到易读性和客户端的易处理性，我们 必须 把错误信息直接放到响应实体中，并且错误格式 应该 满足如下格式：

{
    "message": "您查找的资源不存在",
    "error_code": 404001
}

其中错误码（error_code）必须 和 HTTP 状态码对应，也方便错误码归类，如：

HTTP/1.1 429 Too Many Requests
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 10:15:52 GMT
Connection: keep-alive
 
{"error_code":429001,"message":"你操作太频繁了"}

HTTP/1.1 403 Forbidden
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 10:19:27 GMT
Connection: keep-alive
 
{"error_code":403002,"message":"用户已禁用"}

应该 在返回的错误信息中，同时包含面向开发者和面向用户的提示信息，前者可方便开发人员调试，后者可直接展示给终端用户查看如：

{
    "message": "直接展示给终端用户的错误信息",
    "error_code": "业务错误码",
    "error": "供开发者查看的错误信息",
    "debug": [
        "错误堆栈，必须开启 debug 才存在"
    ]
}

下面详细列举了各种情况 API 的返回说明。

200 ok

200 状态码是最常见的 HTTP 状态码，在所有成功的 GET 请求中，必须 返回此状态码。HTTP 响应实体部分 必须 直接就是数据，不要做多余的包装。

错误示例：

HTTP/1.1 200 ok
Content-Type: application/json
Server: example.com
 
{
    "user": {
        "id":1,
        "nickname":"fwest",
        "username": "example"
    }
}

正确示例：

1、获取单个资源详情

{
    "id": 1,
    "username": "godruoyi",
    "age": 88,
}

2、获取资源集合

[
    {
        "id": 1,
        "username": "godruoyi",
        "age": 88,
    },
    {
        "id": 2,
        "username": "foo",
        "age": 88,
    }
]

3、额外的媒体信息

{
    "data": [
        {
            "id": 1,
            "avatar": "https://lorempixel.com/640/480/?32556",
            "nickname": "fwest",
            "last_logined_time": "2018-05-29 04:56:43",
            "has_registed": true
        },
        {
            "id": 2,
            "avatar": "https://lorempixel.com/640/480/?86144",
            "nickname": "zschowalter",
            "last_logined_time": "2018-06-16 15:18:34",
            "has_registed": true
        }
    ],
    "meta": {
        "pagination": {
            "total": 101,
            "count": 2,
            "per_page": 2,
            "current_page": 1,
            "total_pages": 51,
            "links": {
                "next": "http://api.example.com?page=2"
            }
        }
    }
}

其中，分页和其他额外的媒体信息，必须放到 meta 字段中。

201 Created

当服务器创建数据成功时，应该 返回此状态码。常见的应用场景是使用 POST 提交用户信息，如：

添加了新用户
上传了图片
创建了新活动

等，都可以返回 201 状态码。需要注意的是，你可以选择在用户创建成功后返回新用户的数据

HTTP/1.1 201 Created
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Date: Sun, 24 Jun 2018 09:13:40 GMT
Connection: keep-alive
 
{
    "id": 1,
    "avatar": "https:\/\/lorempixel.com\/640\/480\/?32556",
    "nickname": "fwest",
    "last_logined_time": "2018-05-29 04:56:43",
    "created_at": "2018-06-16 17:55:55",
    "updated_at": "2018-06-16 17:55:55"
}

也可以返回一个响应实体为空的 HTTP Response 如：

HTTP/1.1 201 Created
Server: nginx/1.11.9
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Date: Sun, 24 Jun 2018 09:12:20 GMT
Connection: keep-alive

这里我们 应该 采用第二种方式，因为大多数情况下，客户端只需要知道该请求操作成功与否，并不需要返回新资源的信息。

202 Accepted

该状态码表示服务器已经接受到了来自客户端的请求，但还未开始处理。常用短信发送、邮件通知、模板消息推送等这类很耗时需要队列支持的场景中；

返回该状态码时，响应实体 必须 为空。

HTTP/1.1 202 Accepted
Server: nginx/1.11.9
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Date: Sun, 24 Jun 2018 09:25:15 GMT
Connection: keep-alive

204 No Content

该状态码表示响应实体不包含任何数据，其中：

在使用 DELETE 方法删除资源成功时，必须 返回该状态码
使用 PUT、PATCH 方法更新数据成功时，也 应该 返回此状态码

HTTP/1.1 204 No Content
Server: nginx/1.11.9
Date: Sun, 24 Jun 2018 09:29:12 GMT
Connection: keep-alive

3xx 重定向

所有 API 不该 返回 3xx 类型的状态码。因为 3xx 类型的响应格式一般为下列格式：

HTTP/1.1 302 Found
Server: nginx/1.11.9
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 09:41:50 GMT
Location: https://example.com

所有 API 一定不可 返回纯 HTML 结构的响应；若一定要使用重定向功能，可以 返回一个响应实体为空的 3xx 响应，并在响应头中加上 Location 字段:

HTTP/1.1 302 Found
Server: nginx/1.11.9
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Date: Sun, 24 Jun 2018 09:52:50 GMT
Location: https://godruoyi.com
Connection: keep-alive

400 Bad Request

由于明显的客户端错误（例如，请求语法格式错误、无效的请求、无效的签名等），服务器 应该 放弃该请求。

当服务器无法从其他 4xx 类型的状态码中找出合适的来表示错误类型时，都 必须 返回该状态码。

HTTP/1.1 400 Bad Request
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 13:22:36 GMT
Connection: keep-alive
 
{"error_code":40000,"message":"无效的签名"}

401 Unauthorized

该状态码表示当前请求需要身份认证，以下情况都 必须 返回该状态码。

未认证用户访问需要认证的 API
access_token 无效/过期

客户端在收到 401 响应后，都 应该 提示用户进行下一步的登录操作。

HTTP/1.1 401 Unauthorized
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
WWW-Authenticate: JWTAuth
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 13:17:02 GMT
Connection: keep-alive
 
"message":"Token Signature could not be verified.","error_code": "40100"}

403 Forbidden

该状态码可以简单的理解为没有权限访问该请求，服务器收到请求但拒绝提供服务。

如当普通用户请求操作管理员用户时，必须 返回该状态码。

HTTP/1.1 403 Forbidden
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 13:05:34 GMT
Connection: keep-alive
 
{"error_code":40301,"message":"权限不足"}

404 Not Found

该状态码表示用户请求的资源不存在，如

获取不存在的用户信息（get /users/9999999）
访问不存在的端点

都 必须 返回该状态码，若该资源已永久不存在，则 应该 返回 401 响应。

405 Method Not Allowd

当客户端使用的 HTTP 请求方法不被服务器允许时，必须 返回该状态码。

如客户端调用了 POST 方法来访问只支持 GET 方法的 API

该响应 必须 返回一个 Allow 头信息用以表示出当前资源能够接受的请求方法的列表。

HTTP/1.1 405 Method Not Allowed
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Allow: GET, HEAD
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 12:30:57 GMT
Connection: keep-alive
 
{"message":"405 Method Not Allowed","error_code": 40500}

406 Not Acceptable

API 在不支持客户端指定的数据格式时，应该返回此状态码。如支持 JSON 和 XML 输出的 API 被指定返回 YAML 格式的数据时。

Http 协议一般通过请求首部的 Accept 来指定数据格式

408 Request Timeout

客户端请求超时时 必须 返回该状态码，需要注意的时，该状态码表示 客户端请求超时，在涉及第三方 API 调用超时时，一定不可 返回该状态码。

409 Gonfilct

该状态码表示因为请求存在冲突无法处理。如通过手机号码提供注册功能的 API，当用户提交的手机号已存在时，必须 返回此状态码。

HTTP/1.1 409 Conflict
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 12:19:04 GMT
Connection: keep-alive
 
{"error_code":40900,"message":"手机号已存在"}

410 Gone

和 404 类似，该状态码也表示请求的资源不存在，只是 410 状态码进一步表示所请求的资源已不存在，并且未来也不会存在。在收到 410 状态码后，客户端 应该 停止再次请求该资源。

413 Request Entity Too Large

该状态码表示服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。

此种情况下，服务器可以关闭连接以免客户端继续发送此请求。

如果这个状况是临时的，服务器 应该 返回一个 Retry-After 的响应头，以告知客户端可以在多少时间以后重新尝试。

414 Request-URI Too Long

该状态码表示请求的 URI 长度超过了服务器能够解释的长度，因此服务器拒绝对该请求提供服务。

415 Unsupported Media Type

通常表示服务器不支持客户端请求首部 Content-Type 指定的数据格式。如在只接受 JSON 格式的 API 中放入 XML 类型的数据并向服务器发送，都 应该 返回该状态码。

该状态码也可用于如：只允许上传图片格式的文件，但是客户端提交媒体文件非法或不是图片类型，这时 应该 返回该状态码：

HTTP/1.1 415 Unsupported Media Type
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 12:09:40 GMT
Connection: keep-alive
 
{"error_code":41500,"message":"不允许上传的图片格式"}

429 Too Many Request

该状态码表示用户请求次数超过允许范围。如 API 设定为 60次/分钟，当用户在一分钟内请求次数超过 60 次后，都 应该 返回该状态码。并且也 应该 在响应首部中加上下列头部：

X-RateLimit-Limit: 10 请求速率（由应用设定，其单位一般为小时/分钟等，这里是 10次/5分钟）
X-RateLimit-Remaining: 0 当前剩余的请求数量
X-RateLimit-Reset: 1529839462 重置时间
Retry-After: 120 下一次访问应该等待的时间（秒）

列子

HTTP/1.1 429 Too Many Requests
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
X-RateLimit-Limit: 10
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1529839462
Retry-After: 290
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 11:19:32 GMT
Connection: keep-alive
 
{"message":"You have exceeded your rate limit.","error_code":42900}

必须 为所有的 API 设置 Rate Limit 支持。

500 Internal Server Error

该状态码 必须 在服务器出错时抛出，对于所有的 500 错误，都 应该 提供完整的错误信息支持，也方便跟踪调试。

503 Service Unavailable

该状态码表示服务器暂时处理不可用状态，当服务器需要维护或第三方 API 请求超时/不可达时，都 应该 返回该状态码，其中若是主动关闭 API 服务，应该 在返回的响应首部加上 Retry-After 头部，表示多少秒后可以再次访问。

HTTP/1.1 503 Service Unavailable
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 10:56:20 GMT
Retry-After: 60
Connection: keep-alive
 
{"error_code":50300,"message":"服务维护中"}

其他 HTTP 状态码请参考 HTTP 状态码- 维基百科。

版权声明

版权声明：自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）

建议参考

Let's Encrypt 泛域名证书申请及配置

Thu, 21 Jun 2018 15:26:19 GMT

Let’s Encrypt 在今年 3 月份就已经推出泛域名证书支持了，以前我一直是使用的单域名证书，加上站点开启了 HSTS 支持，当新增网站应用时不得不为其单独申请证书，十分不便。

目前比较常用的为 Let's Encrypt 生成证书的工具比较多，如

这里我们将使用 acme.sh 这个工具来安装 Let's Encrypt 证书。acme.sh 是一个非常优秀的证书生成工具，其官网更是有详细的中文文档支持。

安装

你可以通过下面的脚本来安装 acme.sh

curl  https://get.acme.sh | sh

该操作需要服务器支持 socat 及 curl 模块。（apt install socat curl）

安装成功后，会在当前文件夹下生成 .acme.sh 文件夹。

生成证书

acme.sh 实现了 acme 协议支持的所有验证协议，一般有两种方式验证: http 和 dns 验证。由于泛域名证书的解析目前仅支持 DNS 方式验证，下面我们将通过 DNS 方式来验证你的域名所有权。

acme.sh  --issue  --dns  -d godruoyi.com -d '*.godruoyi.com' --yes-I-know-dns-manual-mode-enough-go-ahead-please

这种方式会将相应的解析记录显示出来，然后你需要在你的域名管理面板中添加这条 txt 记录。并等待解析完成之后，重新用下面命令生成证书：

acme.sh  --renew   -d mydomain.com

注意第二次这里用的是 --renew，当然我们并不想这么麻烦，dns 方式的真正强大之处在于可以使用域名解析商提供的 api 自动添加 txt 记录完成验证。

根据你的域名服务商类型，选择对应的 DNS API。如

1、腾讯云

在这里申请 API Token，获取到 ID 及 Token 后执行：

export DP_Id="id"
export DP_Key="token"

2、阿里云

在这里申请阿里云 Accesskey

获取到 KEY 及 Secret 后执行下面命令：

export Ali_Key="sdfsdfsdfljlbjkljlkjsdfoiwje"
export Ali_Secret="jlsdflanljkljlfdsaklkjflsa"

3、生成证书

在配置好上述设置后，就可通过

.acme.sh/acme.sh --issue --dns dns_dp -d godruoyi.com -d *.godruoyi.com

来生成证书，注意这里第一个域名为顶级域名，后面个为泛域名。

这种方式将自动为你的域名添加一条 txt 解析，验证成功后，这条解析记录会被删除，所以对你来说是无感的，就是要等 120秒。

证书生成成功后，默认保存在 .acme.sh/你的顶级域名 中。

PS：如果你卡在 Getting domain auth token for each domain 这一步不动了，别担心，升级下你的 acme.sh 就好了。

.acme.sh/acme.sh --upgrade

配置 Nginx

下面我们来为 Nginx 配置 SSL 证书支持。

1、移动下列证书到 /etc/nginx/ssl 文件夹，若无该文件夹，自行创建。

cp ~/.acme.sh/godruoyi.com/fullchain.cer /etc/nginx/ssl/fullchain.cer
cp ~/.acme.sh/godruoyi.com/godruoyi.com.key /etc/nginx/ssl/godruoyi.key

2、新建 ssl-params.conf 并把它放到 Nginx 的 snippets 目录中。

下面的这些配置来自提高安全性的最佳 Nginx 配置，建议参考。

# /etc/nginx/snippets/ssl-params.conf
 
server_tokens   off;
 
ssl_session_cache        shared:SSL:10m;
ssl_session_timeout      60m;
 
ssl_session_tickets      on;
 
ssl_stapling             on;
ssl_stapling_verify      on;
 
resolver                 8.8.4.4 8.8.8.8  valid=300s;
resolver_timeout         10s;
ssl_prefer_server_ciphers on;
 
# 证书路径 绝对地址
ssl_certificate          /etc/nginx/ssl/fullchain.cer;
ssl_certificate_key      /etc/nginx/ssl/godruoyi.key;
 
ssl_protocols            TLSv1 TLSv1.1 TLSv1.2;
 
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
 
add_header Strict-Transport-Security "max-age=31536000;includeSubDomains;preload";
add_header  X-Frame-Options  deny;
add_header  X-Content-Type-Options  nosniff;
add_header x-xss-protection "1; mode=block";
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' blob: https:; connect-src 'self' https:; img-src 'self' data: https: blob:; style-src 'unsafe-inline' https:; font-src https:";

3、接下来在 Nginx 主配置文件中开启 SSL 支持

# /etc/nginx/nginx.conf

http {
    ....
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
}

完整的 Nginx 配置文件请参考我的 Nginx 配置

4、配置虚拟主机

# /etc/nginx/sites-available/godruoyi.com
 
server {
    listen 80 default_server;
    listen [::]:80 default_server;
 
    server_name godruoyi.com www.godruoyi.com;
    return 301 https://$server_name$request_uri;
}
 
server {
    # 注意我们设置该站点为默认站点，并移除了 nginx 默认的 default 配置
    listen 443 ssl http2 fastopen=3 reuseport default_server;
    listen [::]:443 ssl http2 fastopen=3 reuseport default_server;
 
    server_name www.godruoyi.com godruoyi.com;
 
    # 引入 SSL 及 PHP 配置
    include snippets/fastcgi-php.conf;
    include snippets/ssl-params.conf;
 
    root /home/godruoyi/websites/godruoyi.com/public;
 
    access_log /home/godruoyi/websites/godruoyi.com/storage/logs/nginx-access.log;
    error_log  /home/godruoyi/websites/godruoyi.com/storage/logs/nginx-error.log error;
 
    index index.php;
 
    # 当访问域名是不  godruoyi.com 强制跳转到 https://godruoyi.com
    if ($host != 'godruoyi.com' ) {
        rewrite ^/(.*)$ https://godruoyi.com/$1 permanent;
    }
}

再来看一个 admin.godruoyi.com 的配置

# /etc/nginx/sites-available/admin.godruoyi.com
 
server {
    listen 80;
    listen [::]:80;
 
    server_name admin.godruoyi.com;
    return 301 https://$server_name$request_uri;
}
server {
    # 如果多个域名配置在同一主机，这里只需要监听到 433 就可以了，
    # 不需要再添加 ssl http2 fastopen=3 reuseport default_server 之类的了
    listen 443;      
    listen [::]:443;
 
    root /home/godruoyi/websites/admin.godruoyi.com/public-admin;
 
    access_log /home/godruoyi/websites/admin.godruoyi.com/storage/logs/nginx-access.log;
    error_log  /home/godruoyi/websites/admin.godruoyi.com/storage/logs/nginx-error.log error;
 
    server_name admin.godruoyi.com;
 
    index index.php;
 
    client_max_body_size 20M;
 
    include snippets/fastcgi-php.conf;
    include snippets/ssl-params.conf;
 
    if ($host != 'admin.godruoyi.com' ) {
        rewrite ^/(.*)$ https://admin.godruoyi.com/$1 permanent;
    }
}

4、虚拟主机配置完成，接下来为其配置软连接测试成功后就可以重启 Nginx 啦。

sudo ln -s /etc/nginx/sites-available/godruoyi.com /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/admin.godruoyi.com /etc/nginx/sites-enabled/
 
# 测试配置是否成功
sudo nginx -t
 
sudo service nginx restart

以上所有配置你都可以在这里找到。

参考链接

腾讯云DNSPod API申请Let’s Encrypt泛域名证书

利用 Intervention Image 合成图片

Wed, 06 Jun 2018 02:02:11 GMT

在我们实际应用中，经常遇到图片合成的需求（比如合成一整用户信息 + 二维码图片，便于传播分享等），传统的做法是采用 GD 或 Imagick 库内置函数来完成。但估计你和我一样，对这些函数都不会很上心。

下面将采用目前功能全面的 intervention/image 库来完成这一操作。

使用

intervention 的安装这里不再论述，请移至官网。

初始化

你可以直接在原始 PHP 通过下述方式获取 ImageManager 管理对象：

require 'vendor/autoload.php';
 
use Intervention\Image\ImageManager;
 
$manager = new ImageManager(array('driver' => 'imagick'));

如果是在 Laravel 中，可直接通过 app('image') 或使用 Intervention\Image\Facades\Image 门面类。

 
use Intervention\Image\Facades\Image;
 
//或
$manager = app('image');

合成

 
// $image = $manager->make($bg);
// $image = Image::make($bg);
 
$image = app('image')->make($bg);
 
// 二维码图片
$qrcodeImage = app('image')->make($qrcodeurl)->resize(200, 200);
// 重置 头像 大小
$avatarImage  = app('image')->make($httpClient->request('GET', $avatarurl)->getBody())->resize(200, 200);
 
$image->text('Nickname', 376, 320, function ($font) {
    $font->file(public_path('fonts/SimHei.ttf'));
    $font->size(40);
    $font->color('#000000');
    $font->align('center');
    $font->valign('top');
});
 
$image->insert($qrcodeImage, 'bottom', 0, 360);
$image->insert($avatarImage, 'top', 0, 105);

上面的代码逻辑为：

初始化背景图片，后续的文字图片合成都基于该背景模板
插入 Nickname 文本到背景图，文本位置相对于背景图 X轴 376 偏移量、Y轴 320 偏移量。并设置字体文件位置、字体大小、字体颜色、字体水平对齐方式（left，center，right 默认 left）、字体垂直对齐方式（top，bottom，middle 默认 bottom）等。
插入一张二维码图片，并设置图片的插入位置为 bottom （下方，其他可用位置），图片位置相对应背景图 X轴 0 偏移量、Y轴 105 偏移量。

需要注意的是，在设置字体大小时，如果不指定字体文件位置，则设置的字体大小恒为默认值 12。并且中文可能会存在乱码情况，建议采用 Sim 字体。下载链接

关于这个站点

Mon, 07 May 2018 03:07:05 GMT

在看完 Laravel China 社区的两篇教程后，我决定基于该教程来写一个 Blog（刚好手头撸了腾讯云的羊毛）。

说明

~~博客是基于 laravel5.5 和 vue2.* 来搭建的；前台是 vue 的单页应用~~，后台采用的是传统的模板渲染（简单快捷）。由于自己样式表写得一塌涂地，前、后所有样式均来自于 laravel-news 及 Voyager。

更新

2021-08 你目前看到的博客运行在一个 1 核 2 G 的云服务器上；采用 Gin 框架快速搭建，静态资源全部放在 CDN 上

前台

前台的单页应用架构主要参考「抄」 @overtrue 和 @cjjian 一起写的项目一刻, 虽然该项目已经停止维护了，但大神的思路还是很值得去学习的。关于 yike 的更多信息可以去看看 @cjjian 的介绍贴 PJ Blog 升级 & Yike 项目介绍

贴两张博客截图

首页

文章详情页

后台

后台完全是基于 Voyager 快速搭建的。

最后附上 Blog 地址 godruoyi.com。:smile: :smile:

调整内心，写点东西

Thu, 03 May 2018 16:27:06 GMT

这个五一，我的老朋友结婚啦。那年都军训完才到学校报告并且还睡我上面的小伙，没想到是我们寝室最早结婚的。

当初脑子进水选的计算机专业，现在想起来其实并没有那么差。但要不是你的蛊惑，我也不会踏上这条不归路。

大学前 3 年都混过了，最后一年该养猪的养猪，该深造的深造，留下两个来自贵州小山村的我们，你在学习我在撸。终于看不下去的你发了一套马士兵老师的 java 教学视频，从此开启不一样的人生。

我是幸运的，一个多月的自学居然也能被录取实习（后面永哥说其实你很菜，只是在你身上能看到 少平 的影子）。更幸运的是，我在公司里找到了她！！

一晃你结婚了，再过几年儿子都要喊我叫干爹啦。当初一群大傻们信誓旦旦的说 25 才结婚。没想到你失言了，更没想到有的大傻可能现在还是处男。

朋友

记得一年多前厦门的聚会感觉都还是 老铁，一年后涪陵的聚会却感觉多了些什么，那可能是时间吧！刚分开的我们，总是有说不完的梗。而当同样的梗开始说上两三篇后，连超哥都不忍心再让他喝酒了！

目前的微信QQ群，打的火热的总是那么一两个，其实你那有那么忙，每条消息都看，只是不回。等再过一两年，群不再是交流的场所，而是为宝宝点赞、为微商产品打广告的乐园。

前两天高中的闺蜜难得的找我，但并不是叙旧，只是新开的微商需要流量！

家人

独在异乡为异客
每逢佳节倍思亲

更何况今天还是我的生日。一个人在外地，熟悉的老朋友一个不在，中学时代一起玩坦克大战的伙伴也越来越远。前端时间难得有个亲人过来看我，也被我 冷落。

其实当时一两句话就能说清楚的事，硬生生被自己给说糊了。谈话真是一门艺术啊。

愿你我的生活充满阳光，吧！

提高安全性的最佳 Nginx 配置

Sun, 08 Apr 2018 10:16:19 GMT

由于安全问题一直是重中之重，这里整理下 nginx 的安全配置。文章大部分参考了 Best nginx configuration for improved security(and performance). 及 Jerry Qu，更多关于 HTTP 安全及性能可前往 Jerry Qu 查看。

server_tokens

该响应头用于禁止 nginx 在响应中报文中包含版本信息。因为具体的版本可能会存在未知 bug。

server_tokens off;

X-Frame-Options

该响应头用于是否允许浏览器加载 frame、 iframe、 object 等属性。可以使用该功能来避免点击劫持

add_header X-Frame-Options SAMEORIGIN;

该指令用三个可用的配置

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
X-Frame-Options: ALLOW-FROM https://example.com/

当设置为 DENY 时，站点禁止任何页面被嵌入。

当设置为 SAMEORIGIN 时，只允许加载同源的 fram/iframe/object。

当设置为 ALLOW-FROM 时，只允许加载指定的源。

X-Content-Type-Options

在我们通常的请求响应中，浏览器会根据 HTTP 响应的 Content-Type 来分辨响应的类型。如 text/html 代表 html 文档。但当响应类型未指定或错误指定时，浏览会尝试启用 MIME-sniffing 来猜测资源的响应类型。

如通过精心制作一个图像文件，并在其中嵌入可以被浏览器所展示和执行的 HTML 和 JavaScript 代码。由于未关闭资源的类型猜测，浏览器将直接执行嵌入的 JavaScript 代码，而不是显示图片。

add_header X-Content-Type-Options nosniff;

用来指定浏览器对未指定或错误指定 Content-Type 资源真正类型的猜测行为，nosniff 表示不允许任何猜测。（Jerry Qu）

这个响应头的值只能是 nosniff，可用于 IE8+ 和 Chrome。

X-XSS-Protection

add_header X-XSS-Protection "1; mode=block";

该响应头是用于防范及过滤 XSS 的。可用的几个指令如下：

X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=

说明

0，禁用 XSS 过滤
1，开启 XSS 过滤
1; mode=block，开启 XSS 过滤，并且若检查到 XSS 攻击，停止渲染页面。
X-XSS-Protection: 1; report=<reporting-uri>，开启 XSS 过滤，并且若检查到 XSS 攻击，将使用指导的 url 来发送报告。

Content-Security-Policy

该响应头主要用于规定页面可以加载那些资源（css/js/img 等）。看一个简单的配置

# 定义所有资源文件的默认加载规则为self，表示允许
# 相同来源的内容（相同的协议、域名和端口）
add_header Content-Security-Policy: default-src 'self';

更多 Content-Security-Policy 的指令及规则及介绍可参考 Jerry Qu 的 Content Security Policy 介绍。

Strict-Transport-Security

Strict-Transport-Security，简称 HSTS。该响应头用于标识浏览器用 HTTPS 替代 HTTP 的方式去访问目标站点。

我们知道 HTTPS 相对于 HTTP 有更好的安全性，而很多 HTTPS 网站，也可以通过 HTTP 来访问。开发人员的失误或者用户主动输入地址，都有可能导致用户以 HTTP 访问网站，降低了安全性。一般，我们会通过 Web Server 发送 301/302 重定向来解决这个问题。（Jerry Qu）

我们可以使用下面方式启用 HSTH。

add_header strict-transport-security: max-age=16070400; includeSubDomains;

当用户第一次访问后，将返回一个包含了 strict-transport-security 响应头的字段。他将告诉浏览器，在接下来的 16070400 秒内，当前网站的所有请求都强制使用 HTTPS 的方式访问。即使用户手动输入 http://，浏览器也会强制使用 HTTPS 方式访问。

参数 includeSubDomains 是可选的，当指定了该参数，所有子域名将采用同样的 HSTS 规则。

可以看到 HSTS 可以很好的解决 HTTPS 降级攻击，但是对于 HSTS 生效前的首次 HTTP 请求，依然无法避免被劫持。浏览器厂商们为了解决这个问题，提出了 HSTS Preload List 方案：内置一份可以定期更新的列表，对于列表中的域名，即使用户之前没有访问过，也会使用 HTTPS 协议。（Jerry Qu）

如果你想把自己的域名加入这个列表，可通过 hstspreloa.org 查看是否满足申请条件。更多关于 HSTS 的配置，可查看关于启用 HTTPS 的一些经验分享。

目前 godruoyi.com 已成功加入 Preload List。

Mysql游标入门

Wed, 04 Apr 2018 07:43:48 GMT

MySQL检索操作返回一组称为结果集的行。这组返回的行都是与SQL语句相匹配的行（零行或多行）。使用简单的SELECT语句，例如，没有办法得到第一行、下一行或前10行，也不存在每次一行地处理所有行的简单方法（相对于成批地处理它们）。

有时，需要在检索出来的行中前进或后退一行或多行。这就是使用游标的原因。游标（cursor）是一个存储在MySQL服务器上的数据库查询，它不是一条SELECT语句，而是被该语句检索出来的结果集。在存储了游标之后，应用程序可以根据需要滚动或浏览其中的数据。

游标主要用于交互式应用，其中用户需要滚动屏幕上的数据，并对数据进行浏览或做出更改。

创建游标

创建一个简单的游标

create procedure simplecursor()
begin
	declare youbiaoName cursor
	for
	select name from user;
	
	open youbiaoName;  -- 打开游标
	-- //some code
	close youbiaoName; -- 关闭游标,释放游标使用的所有内部内存和资源
end;

定义了一个游标，使用declare 游标名 cursor for 来定义游标，该处查询用户表里的用户名，存储过程处理完成后，游标就消失（因为它局限于存储过程），并没有任何返回和输出。

create procedure simplecursor2()
begin
	declare tmp int; -- 定义局部变量
	declare youbiao2 cursor for select name from user; -- 定义游标

	open youbiao2;
		fetch youbiao2 into tmp;
	close youbiao2;
end;

该过程定义一个局部变量和游标，该游标返回了用户表得所用用户名组成的集合，即如下所示

name
admin
admin1
admin2
admin3
然后在游标开启-关闭内，用fetch遍历每一行，把得到的数据(即name的值) into 给局部变量tmp。此处只完成了这个流程，什么都没做。
注：该fetch并没有结束标志，调用时会一直遍历下去，当遍历完最后一行再继续遍历时，会出现错误，[Err] 1366 - Incorrect integer value:

改进如下

create procedure simplecursor3()
begin
	declare done boolean default 0; -- 定义一个循环标记默认值为false
	declare tmp int; -- 定义局部变量
	declare youbiao3 cursor for select name from user; -- 定义游标
	-- 当出现02000错误时把局部变量的值设为true
	declare continue handler for sqlstate '02000' set done 1; 
	
	open youbiao3;

	REPEAT
		fetch youbiao3 into tmp;
	until done end REPEAT;	-- 当done为true时结束repeat，
	
	close youbiao3;
end;

与前一个例子一样，这个例子使用FETCH检索当前name到声明的名为tmp的变量中。但与前一个例子不一样的是，这个例子中的FETCH是在REPEAT内，因此它反复执行直到done为真（由UNTIL done END REPEAT;规定）。为使它起作用，用一个DEFAULT 0（假，不结束）定义变量done。那么，done怎样才能在结束时被设置为真呢？答案是用以下语句：

declare continue handler for sqlstate ‘02000’ set done 1;

这条语句定义了一个CONTINUE HANDLER，它是在条件出现时被执行的代码。这里，它指出当SQLSTATE ‘02000’出现时，SET done=1。SQLSTATE ‘02000’是一个未找到条件，当REPEAT由于没有更多的行供循环而不能继续时，出现这个条件。

复杂一点的游标使用：创建一个新的表，把用户和该用户的所有订单金额存入该表。

create procedure myyoubiao ()
BEGIN
	declare done boolean default 0; --循环标记
	declare tmp int; -- 临时存储变量
	declare t DECIMAL(8,2); -- 同上
	
	declare myyoubiao4 CURSOR for select id from user;
	declare continue handler for sqlstate '02000' set done = 1;

	create table if not exists mytable -- 表不存在是创建， 存在时跳过
	(uId int, total decimal(8,2));

	open myyoubiao4;
	
	REPEAT
		fetch myyoubiao4 into tmp;
			call getTotalByUser2(tmp, 1, t); -- 根据用户id获取该用户总订单金额， 含税
			insert into mytable(uId,total) values(tmp,t); --插入新表
	UNTIL done end REPEAT;
	CLOSE myyoubiao4;
END

调用该过程时，会自动创建一张包含用户id和用户订单总额的表(若不存在)，再把遍历每一个用户，通过上一节创建的过程返回用户的订单总额，插入新创建的表中。

Laravel 管道流原理

Wed, 04 Apr 2018 07:39:04 GMT

Laravel管道流原理强烈依赖array_reduce函数，我们先来了解下array_reduce函数的使用。

array_reduce

array_reduce() 将回调函数 callback 迭代地作用到 array 数组中的每一个单元中，从而将数组简化为单一的值。

mixed array_reduce ( array $array , callable $callback [, mixed $initial = NULL ] )

array

输入的 array。

callback

mixed callback ( mixed $carry , mixed $item ) $carry包括上次迭代的值，如果本次迭代是第一次，那么这个值是 initial，item 携带了本次迭代的值

initial

如果指定了可选参数 initial，该参数将在处理开始前使用，或者当处理结束，数组为空时的最后一个结果。

从文档说明可以看出，array_reduce函数是把数组的每一项，都通过给定的callback函数，来简化的。

那我们就来看看是怎么简化的。

$arr = ['AAAA', 'BBBB', 'CCCC'];
 
$res = array_reduce($arr, function($carry, $item){
    return $carry . $item;
});

给定的数组长度为3，故总迭代三次。

第一次迭代时 $carry = null $item = AAAA 返回AAAA
第一次迭代时 $carry = AAAA $item = BBBB 返回AAAABBBB
第一次迭代时 $carry = AAAABBBB $item = CCCC 返回AAAABBBBCCCC

这种方式将数组简化为一串字符串AAAABBBBCCCC

带初始值的情况

$arr = ['AAAA', 'BBBB', 'CCCC'];
 
$res = array_reduce($arr, function($carry, $item){
    return $carry . $item;
}, 'INITIAL-');

第一次迭代时（$carry = INITIAL-），（$item = AAAA）返回INITIAL-AAAA
第一次迭代时（$carry = INITIAL-AAAA），（$item = BBBB），返回INITIAL-AAAABBBB
第一次迭代时（$carry = INITIAL-AAAABBBB），（$item = CCCC），返回INITIAL-AAAABBBBCCCC

这种方式将数组简化为一串字符串INITIAL-AAAABBBBCCCC

闭包

$arr = ['AAAA', 'BBBB', 'CCCC'];
 
//没带初始值
$res = array_reduce($arr, function($carry, $item){
    return function() use ($item){//这里只use了item
        return strtolower($item) . '-';
    };
});

第一次迭代时，$carry：null，$item = AAAA，返回一个use了$item = AAAA的闭包
第二次迭代时，$carry：use了$item = AAAA的闭包，$item = BBBB，返回一个use了$item = BBBB的闭包
第一次迭代时，$carry：use了$item = BBBB的闭包，$item = CCCC，返回一个use了$item = CCCC的闭包

这种方式将数组简化为一个闭包，即最后返回的闭包，当我们执行这个闭包时$res()得到返回值CCCC-

上面这种方式只use ($item)，每次迭代返回的闭包在下次迭代时，我们都没有用起来。只是又重新返回了一个use了当前item值的闭包。

闭包USE闭包

$arr = ['AAAA'];
 
$res = array_reduce($arr, function($carry, $item){
    return function () use ($carry, $item) {
        if (is_null($carry)) {
            return 'Carry IS NULL' . $item;
        }
    };
});

注意，此时的数组长度为1，并且没有指定初始值

由于数组长度为1，故只迭代一次，返回一个闭包 use（$carry = null, $item = 'AAAA'），当我们执行（$res()）这个闭包时，得到的结果为Carry IS NULLAAAA。

接下来我们重新改造下，

$arr = ['AAAA', 'BBBB'];
 
$res = array_reduce($arr, function($carry, $item){
    return function () use ($carry, $item) {
        if (is_null($carry)) {
            return 'Carry IS NULL' . $item;
        }
        if ($carry instanceof \Closure) {
            return $carry() . $item;
        }
    };
});

我们新增了一个条件判断，若当前迭代的值是一个闭包，返回该闭包的执行结果。

第一次迭代时，$carry的值为null，$item的值为AAAA，返回一个闭包，

//伪代码
function () use ($carry = null, $item = AAAA) {
    if (is_null($carry)) {
        return 'Carry IS NULL' . $item;
    }
    if ($carry instanceof \Closure) {
        return $carry() . $item;
    }
}

假设我们直接执行该闭包，将会返回Carry IS NULLAAAA的结果。

第二次迭代时，$carry的值为上述返回的闭包（伪代码），$item的值为BBBB，返回一个闭包，

当我们执行这个闭包时，满足$carry instanceof \Closure，得到结果Carry IS NULLAAAABBBB。

Laravel中的array_reverse

大致了解了array_reverse函数的使用后，我们来瞅瞅laravel管道流里使用array_reverse的情况。

我在Laravel中间件原理中有阐述，强烈建议先去看看Laravel中间件原理再回过头来接着看。

php内置方法array_reduce把所有要通过的中间件都通过callback方法并压缩为一个Closure。最后在执行Initial

Laravel中通过全局中间件的核心代码如下：

//Illuminate\Foundation\Http\Kernel.php
protected function sendRequestThroughRouter($request)
{
    return (new Pipeline($this->app))
        ->send($request)
        ->through($this->app->shouldSkipMiddleware() ? [] : $this->middleware)
        ->then($this->dispatchToRouter());
}
protected function dispatchToRouter()
{
    return function ($request) {
        $this->app->instance('request', $request);
        return $this->router->dispatch($request);
    };
}

正如我前面说的,我们发送一个$request对象通过middleware中间件数组，最后在执行dispatchToRouter方法。

假设有两个全局中间件，我们来看看这两个中间件是如何通过管道压缩为一个Closure的。

Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode::class,
App\Http\Middleware\AllowOrigin::class,//自定义中间件

Illuminate\Pipeline\Pipeline为laravel的管道流核心类.

在Illuminate\Pipeline\Pipeline的then方法中，$destination为上述的dispatchToRouter闭包，pipes为要通过的中间件数组，passable为Request对象。

public function then(Closure $destination)
{
    $pipeline = array_reduce(
        array_reverse($this->pipes), $this->carry(), $this->prepareDestination($destination)
    );
    return $pipeline($this->passable);
}

array_reverse函数将中间件数组的每一项都通过$this->carry()，初始值为上述dispatchToRouter方法返回的闭包。

protected function prepareDestination(Closure $destination)
{
    return function ($passable) use ($destination) {
        return $destination($passable);
    };
}
protected function carry()
{
    return function ($stack, $pipe) {
        return function ($passable) use ($stack, $pipe) {
            if ($pipe instanceof Closure) {
                return $pipe($passable, $stack);
            } elseif (! is_object($pipe)) {
                //解析中间件参数
                list($name, $parameters) = $this->parsePipeString($pipe);
                $pipe = $this->getContainer()->make($name);
                $parameters = array_merge([$passable, $stack], $parameters);
            } else {
                $parameters = [$passable, $stack];
            }
            return $pipe->{$this->method}(...$parameters);
        };
    };
}

第一次迭代时，返回一个闭包，use了$stack和$pipe，$stack的值为初始值闭包，$pipe为中间件类名，此处是App\Http\Middleware\AllowOrigin::class(注意array_reverse函数把传进来的中间件数组倒叙了)。

假设我们直接运行该闭包，由于此时$pipe是一个String类型的中间件类名，只满足! is_object($pipe)这个条件，我们将直接从容器中make一个该中间件的实列出来，在执行该中间件实列的handle方法（默认$this->method为handle）。并且将request对象和初始值作为参数，传给这个中间件。

public function handle($request, Closure $next)
{
    //......
}

在这个中间件的handle方法中，当我们直接执行return $next($request)时，相当于我们开始执行array_reduce函数的初始值闭包了，即上述的dispatchToRouter方法返回的闭包。

protected function dispatchToRouter()
{
    return function ($request) {
        $this->app->instance('request', $request);
        return $this->router->dispatch($request);
    };
}

好，假设结束。在第二次迭代时，也返回一个use了$stack和$pipe，$stack的值为我们第一次迭代时返回的闭包，$pipe为中间件类名，此处是Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode::class。

两次迭代结束，回到then方法中，我们手动执行了第二次迭代返回的闭包。

return $pipeline($this->passable);

当执行第二次迭代返回的闭包时，当前闭包use的$pipe为Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode::class，同样只满足! is_object($pipe)这个条件，我们将会从容器中make出CheckForMaintenanceMode中间件的实列，在执行该实列的handle方法，并且把第一次迭代返回的闭包作为参数传到handle方法中。

当我们在CheckForMaintenanceMode中间件的handle方法中执行return $next($request)时，此时的$next为我们第一次迭代返回的闭包，将回到我们刚才假设的流程那样。从容器中make一个App\Http\Middleware\AllowOrigin实列，在执行该实列的handle方法，并把初始值闭包作为参数传到AllowOrigin中间件的handle方法中。当我们再在AllowOrigin中间件中执行return $next($request)时，代表我们所有中间件都通过完成了，接下来开始执行dispatchToRouter。

中间件是区分先后顺序的，从这里你应该能明白为什么要把中间件用array_reverse倒叙了。
并不是所有中间件在运行前都已经实例化了的，用到的时候才去想容器取
中间件不执行$next($request)后续所有中间件无法执行。

这篇文章是专们为了上一篇Laravel中间件原理写的，因为在写Laravel中间件原理时我也不很清楚array_reduce在laravel中的运行流程。如果有什么不对的，欢迎指正。

使用预加载优化 Laravel Model 查询

Wed, 04 Apr 2018 07:34:04 GMT

原文译自eloquent-eager-loading，简化其前面~~构造数据~~部分。

介绍

对象关系映射（ORM）使数据库的工作变得非常简单。在以面向对象的方式定义数据库关系时，可以轻松查询相关的模型数据，开发人员可能不会注意底层数据库调用。

下面将通过一些例子，进一步帮助您了解如何优化查询。

假设您从数据库收到了100个对象，并且每个记录都有1个关联模型（即belongsTo）。默认使用ORM将产生101个查询; 如下所示：

//获取已发布的100条文章
$posts = Post::limit(100)->get(); //一次查询
 
$authors = array_map(function($post) {
    // 对作者模型生成查询
    return $post->author->name;
}, $posts);

我们在查询时没有告诉Post模型，我们还需要所有的作者，所以每次从单个Post模型实例获取作者的名字时，都会发生单独的查询。

array_maps时发生100次查询，加上先前一次查询，累计产生101次查询。

预加载

接下来，如果我们打算使用关联的模型数据，我们可以使用预加载将该101个查询总数减少到2个查询。只需要告诉模型你需要什么来加载。如下：

//获取已发布的100条文章  - 并预加载文章对应作者
$posts = Post::with('author')->limit(100)->get();//2次查询
 
$authors = array_map(function($post) {
    // 对作者模型生成查询
    return $post->author->name;//这里讲不在产生查询
}, $posts);

如果你开启了sql日志，你将看到上述预加载将只会产生两条查询：

select * from `posts`
select * from `authors` where `authors`.`id` in (?, ?, ?, ?, ?) [1,2,3,4,5]

如果您有多个关联模型，则可以使用数组加载它们：

$posts = App\Post::with(['author', 'comments'])->get();

接下来我们重新定义如下关系

Post -> belongsTo -> Author //每个文章只属于一个用户
Author -> hasMany -> Post   //每个用户拥有多个文章
Author -> hasOne -> Profile //每个用户只有一个简介

考虑下述情况：获取已发布文章所属作者的个人简介。

//获取所有文章 - 并预加载文章对应作者
$posts = App\Post::with('author')->get();//两次查询
 
//根据每个 `作者` 获取其简介
$posts->map(function ($post) {
    //虽然我们直接通过$author = $post->author不会产生查询，
    //但当调用$author->profile时，每次都会产生一个新查询
    return $post->author->profile;
});

假设上述App\Post::with('author')->get()有100条记录，将会产生多少条查询呢？

通过优化预加载，我们可以避免嵌套关系中的额外查询。

//获取所有文章 - 并预加载文章对应作者及每个作者对应de profile
$posts = App\Post::with('author.profile')->get();//三次查询
 
$posts->map(function ($post) {
    //不在产生新查询
    return $post->author->profile;
});

你可以打开你的sql日志看到对应的三条查询。

select * from `posts`  
select * from `authors` where `authors`.`id` in (?, ?, ?, ?, ?) [.....] 
select * from `profiles` where `profiles`.`author_id` in (?, ?, ?, ?, ?) [.....]

懒惰加载

有时候您可能只需要根据条件收集相关联的模型。在这种情况下，您可以懒惰地调用相关数据的其他查询：

$posts = App\Post::all();//一次查询
 
$posts->load('author.profile');//两次查询
$posts->map(function ($post) {
    //不在产生新查询
    return $post->author->profile;
});

查看您的sql日志，总共看到三个查询，但只有调用$posts->load()时才会显示。

结论

希望您更加了解有关加载型号的更多信息，并了解其在更深层次上的工作原理。 Laravel相关的文档已经很全面了，希望额外的实践练习可以帮助您更有信心优化关系查询。

FastCgi 与 PHP-fpm 之间的关系

Wed, 04 Apr 2018 07:32:25 GMT

原文分享自segmentfault @尹川的回答，搞不清FastCgi与PHP-fpm之间是个什么样的关系

我在网上查fastcgi与php-fpm的关系，查了快一周了，基本看了个遍，真是众说纷纭，没一个权威性的定义。

网上有的说，fastcgi是一个协议，php-fpm实现了这个协议；

有的说，php-fpm是fastcgi进程的管理器，用来管理fastcgi进程的；

有的说，php-fpm是php内核的一个补丁;

有的说，修改了php.ini配置文件后，没办法平滑重启，所以就诞生了php-fpm；

还有的说PHP-CGI是PHP自带的FastCGI管理器，那这样的话干吗又弄个php-fpm出来？

首先，CGI是干嘛的？

CGI是为了保证web server传递过来的数据是标准格式的，方便CGI程序的编写者。

web server（比如说nginx）只是内容的分发者。比如，如果请求/index.html，那么web server会去文件系统中找到这个文件，发送给浏览器，这里分发的是静态数据。好了，如果现在请求的是/index.php，根据配置文件，nginx知道这个不是静态文件，需要去找PHP解析器来处理，那么他会把这个请求简单处理后交给PHP解析器。Nginx会传哪些数据给PHP解析器呢？url要有吧，查询字符串也得有吧，POST数据也要有，HTTP header不能少吧，好的，CGI就是规定要传哪些数据、以什么样的格式传递给后方处理这个请求的协议。

当web server收到/index.php这个请求后，会启动对应的CGI程序，这里就是PHP的解析器。接下来PHP解析器会解析php.ini文件，初始化执行环境，然后处理请求，再以规定CGI规定的格式返回处理后的结果，退出进程。web server再把结果返回给浏览器。

好了，CGI是个协议，跟进程什么的没关系。

那fastcgi又是什么呢？

Fastcgi是用来提高CGI程序性能的。

提高性能，那么CGI程序的性能问题在哪呢？

“PHP解析器会解析php.ini文件，初始化执行环境”，就是这里了。标准的CGI对每个请求都会执行这些步骤（不闲累啊！启动进程很累的说！），所以处理每个时间的时间会比较长。这明显不合理嘛！那么Fastcgi是怎么做的呢？首先，Fastcgi会先启一个master，解析配置文件，初始化执行环境，然后再启动多个worker。当请求过来时，master会传递给一个worker，然后立即可以接受下一个请求。这样就避免了重复的劳动，效率自然是高。而且当worker不够用时，master可以根据配置预先启动几个worker等着；当然空闲worker太多时，也会停掉一些，这样就提高了性能，也节约了资源。这就是fastcgi的对进程的管理。

那PHP-FPM又是什么呢？

是一个实现了Fastcgi的程序，被PHP官方收了。

大家都知道，PHP的解释器是php-cgi。php-cgi只是个CGI程序，他自己本身只能解析请求，返回结果，不会进程管理（皇上，臣妾真的做不到啊！）所以就出现了一些能够调度php-cgi进程的程序，比如说由lighthttpd分离出来的spawn-fcgi。好了PHP-FPM也是这么个东东，在长时间的发展后，逐渐得到了大家的认可（要知道，前几年大家可是抱怨PHP-FPM稳定性太差的），也越来越流行。

好了，最后来回来上面的问题。

网上有的说，fastcgi是一个协议，php-fpm实现了这个协议

对。

有的说，php-fpm是fastcgi进程的管理器，用来管理fastcgi进程的

对。php-fpm的管理对象是php-cgi。但不能说php-fpm是fastcgi进程的管理器，因为前面说了fastcgi是个协议，似乎没有这么个进程存在，就算存在php-fpm也管理不了他（至少目前是）。

有的说，php-fpm是php内核的一个补丁

以前是对的。因为最开始的时候php-fpm没有包含在PHP内核里面，要使用这个功能，需要找到与源码版本相同的php-fpm对内核打补丁，然后再编译。后来PHP内核集成了PHP-FPM之后就方便多了，使用—enalbe-fpm这个编译参数即可。

有的说，修改了php.ini配置文件后，没办法平滑重启，所以就诞生了php-fpm

是的，修改php.ini之后，php-cgi进程的确是没办法平滑重启的。php-fpm对此的处理机制是新的worker用新的配置，已经存在的worker处理完手上的活就可以歇着了，通过这种机制来平滑过度。

还有的说PHP-CGI是PHP自带的FastCGI管理器，那这样的话干吗又弄个php-fpm出来？

不对。php-cgi只是解释PHP脚本的程序而已。

我的 Sublime text 插件配置

Wed, 04 Apr 2018 07:29:58 GMT

首先，我应该正确安装了 Package Control。

Material Theme

外观是最重要的，一个好的主题会让你爱上完美。这里推荐 Material Theme

Operator

是不是感觉字体不好看，咳不出来又咽不下去，试试这款吧 Operator，号称贵到灵魂出窍的等宽编程字体(@JokerLinly)，一套只需 $599.0。:smile: 我还是用我的默认字体吧！

Alignment

定义了一大堆变量，想让他们快速对齐怎么办！（强迫症患者福利）

安装完成后进入 preferences->Package settings->Alignment->Key Bindings-User 设置快捷键（我的是 ctrl+alt+0）

{ "keys": ["ctrl+alt+0"], "command": "alignment" }

AdvancedNewFile

你还在用鼠标创建和移动文件吗，看这里。

默认情况下安装成功后快捷键不是很好用且只有一个创建文件的快捷键(ctrl+alt+n)，建议你覆盖默认快捷键配置。

{ "keys": ["ctrl+n"], "command": "advanced_new_file_new" }, //快速新建文件
{ "keys": ["alt+m"], "command": "advanced_new_file_move" }, //移动文件
{ "keys": ["alt+delete"], "command": "advanced_new_file_delete" , "args": {"current": true}}, //删除当前文件
{ "keys": ["alt+."], "command": "advanced_new_file_copy" }  //复制当前文件的内容到一个新文件

EditorConfig

当项目涉及到多人开发时，定义一套 简单 的编码规范是必须的。

安装成功后在项目根目录下创建一个 .editorconfig 的配置文件，我的默认配置如下，查看更多配置细节

root = true
 
[*]
indent_style = space
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
 
[*.{js,py,css,vue}]
indent_size = 2
 
[*.md]
trim_trailing_whitespace = false

SublimeLinter-php

该插件是一个自动检查 PHP 语法错误的插件，安装前先要安装 SublimeLinter，默认安装成功后，ctrl+s 保存时将自动提示语法错误。

若你没有把 php 及 python 加入环境变量，你可能要在 SublimeLinter 的配置文件中指定 python 及 php 的执行路径。

Phpcs

关于 PHPCS的介绍及安装请戳这里

其他

All Autocomplete
ConvertToUTF8
DocBlockr
Emmet
Git
GitGutter
Laravel 5 Artisan
SideBarEnhancements

Laravel 队列优先级的一个坑

Wed, 04 Apr 2018 07:24:36 GMT

准确来说这不算是坑，但骚不注意就掉进去了。

在使用 laravel 队列时，有时候我们希望为他设定一个优先级，如：

php artisan queue:work --queue=high,low

这样，当我们的任务需要优先发送时，就可以通过指定队列名 high 来优先发送。

dispatch((new Job)->onQueue('high'));

但是当你后续任务没有指定队列名（high、low）时，你的队列任务永远也不会执行。（比如我们在发送消息通知时）

<?php
 
namespace App\Notifications;
 
use Illuminate\Bus\Queueable;
use Illuminate\Notifications\Notification;
use Illuminate\Contracts\Queue\ShouldQueue;
 
class YourNotification extends Notification implements ShouldQueue
{
    use Queueable;
}

你发现即使你按照文档说的，implements ShouldQueue 并且 use Queueable，该通知还是无法加入队列。

那是因为 config\queuq.php 配置中，指定了默认的队列名为 default，所以所有的队列任务，如果没指定队列名时，默认是 default。

但是我们在启动队列进程时，只指定了 high 和 low。当然不会生效。

解决办法： 1、修改config\queuq.php 默认队列名为 low 或 high 2、启动队列进程时添加 default（—queue=high,default,low）

Laravel 响应宏原理

Wed, 04 Apr 2018 05:09:16 GMT

我们在使用 Laravel 来写 API 时，经常需要返回一个 JSON 字符串或 JsonResponse 对象，通常的做法可能有：

在 BaseController 中定义一个返回 JSON 响应的方法，然后其他 class 继承该 BaseController，如：

// BaseController.php
 
public function json($data = null, $status = 200, $headers = [], $options = 0)
{
    return new JsonResponse($data, $status, $headers, $options);
}
 
// YourController.php
class YourController extends BaseController
{
    public function users(UserRepository $userRepository)
    {
        return $this->json($userRepository->allUser());
    }
}

这种写法确实方便快捷，大部分项目估计也是这样做的；然而当你要在其他地方也需要输出 JSON 响应时（如中间件验证失败），你根本无法复用该方法；针对这种情况：你或许可以直接返回一个错误的 JSON 响应：

public func handle($next, $request) {
    if ($request->user()->role_id != 1) {
		    return [
				    "code" => -1,
						"message" => "some error"
				];
		}
}

但这样写当前端小伙伴固定了返回格式或后续需要调整返回格式时，你不得不修改所有有可能要改的地方。

Response 宏

Laravel 提供了一个非常方便的 响应宏 来处理这一情况；

首先，我们需要先注册一个响应宏；在任意一个 ServiceProvider 的 boot 方法里，使用 Response Facade 注册：

 
/**
 * Bootstrap any application services.
 *
 * @return void
 */
public function boot()
{
		Response::macro('success', function ($data = [], $message = 'success') {
				return new JsonResponse([
						'code' => 0,
						'data' => $data,
						'message' => $message
				], 200);
		});
}

接下来，你可以再任何地方使用它；

//UserController.php
 
public function users(UserRepository $userRepository)
{
    return response()->success($userRepository->all(), 'success');
}

原理

在 ServiceProvider 里，作者是使用 Response Facade 来注册的 success 宏，先看看 Response 这个 Facade 的正真类是什么。

// Illuminate\Support\Facades.php
 
protected static function getFacadeAccessor()
{
    return 'Illuminate\Contracts\Routing\ResponseFactory';
}

该Facade返回了一个ResponseFactory接口，那该接口的具体实列对象时什么呢。

//Illuminate\Routing\RoutingServiceProvider.php
 
/**
 * Register the response factory implementation.
 *
 * @return void
 */
protected function registerResponseFactory()
{
    $this->app->singleton('Illuminate\Contracts\Routing\ResponseFactory', function ($app) {
        return new ResponseFactory($app['Illuminate\Contracts\View\Factory'], $app['redirect']);
    });
}

可以看到，该RoutingServiceProvider注册了一个Illuminate\Routing\ResponseFactory的实列给Response Facade。

我们在Illuminate\Routing\ResponseFactory的源码中可以看到，它引用了一个Illuminate\Support\Traits\Macroable trait。

namespace Illuminate\Routing;
 
use Illuminate\Support\Traits\Macroable;
 
class ResponseFactory implements FactoryContract
{
    use Macroable;
}

该Trait源码如下，看完源码就知道为什么调用response()就能正常访问success方法了。

trait Macroable
{
    protected static $macros = [];
 
    public static function macro($name, callable $macro)
    {
        static::$macros[$name] = $macro;
    }
 
    public static function hasMacro($name)
    {
        return isset(static::$macros[$name]);
    }
 
    public static function __callStatic($method, $parameters)
    {
        if (! static::hasMacro($method)) {
            throw new BadMethodCallException("Method {$method} does not exist.");
        }
        if (static::$macros[$method] instanceof Closure) {
            return call_user_func_array(Closure::bind(static::$macros[$method], null, static::class), $parameters);
        }
        return call_user_func_array(static::$macros[$method], $parameters);
    }
 
    public function __call($method, $parameters)
    {
        if (! static::hasMacro($method)) {
            throw new BadMethodCallException("Method {$method} does not exist.");
        }
        if (static::$macros[$method] instanceof Closure) {
            return call_user_func_array(static::$macros[$method]->bindTo($this, static::class), $parameters);
        }
        return call_user_func_array(static::$macros[$method], $parameters);
    }
}

其实该 trait Illuminate\Support\Traits\Macroable 在很多地方都有使用，包括 FileSystem、Database-Builder。

Response-macros文档---Laravel-China

连波的闲谈杂鱼

2025 年终总结

往年总结

许老三的腿断了

吐口水

葡萄架

最近更新

开始搭葡萄架

发芽了

开始结果了

变成紫葡萄了

葡萄架垮了

未完待续...

老丈人系列

2024 年终总结

Also Read

Some Pictures of 2024

如何快速搭建自己的博客网站

准备

如何部署

Deploy to Cloudflare 1 - Create a new Fork

Deploy to Cloudflare 2 - Build

如何发布文章

如何在线修改项目(可选)

如何在本地启动项目(可选)

如何自定义

自定义配置

自定义图片

自定义描述

自定义评论

将资源上传到 S3 加速访问

如何添加新功能

参考

没人抬

什么是发件箱模式

什么情况下引入的 Outbox Pattern?

什么是 Outbox Pattern？

这样做有什么好处？

这样做有什么弊端？

为什么不将数据都发送到 Kafka?

如何实现 Outbox Pattern

PostgreSQL Connector

如何配置 Connector 以捕获数据变更？

总结

参考

老爸的日记

美国

Lambda Connect RDS

Background

VPC

Create VPC

子网

路由表

Internet Gateway

NAT

Create VPC On AWS

RDS

Lambda

Security Group

Blog 的延续

截图

2023 年终总结

Life

Someting

Action

往年总结

办酒

为什么 Laravel 这么优秀

Introduction Laravel

Laravel Artisan

Make Model

Database Migration

Model Relationship

How to save data to database

Laravel Route

Create Course

Storage Helper

Testing

Update & Select & Delete

Abstract API