Posts
1. 使用命令导出覆盖率文件明细列表 go test -coverprofile=coverage.out ./... cat coverage.out codeup.aliyun.com/xy/freebook-commerce/bookadv/cmd/service/adv_service.go:1178.18,1180.13 2 0 codeup.aliyun.com/xy/freebook-commerce/bookadv/cmd/service/adv_service.go:1184.23,1186.18 2 0 codeup.aliyun.com/xy/freebook-commerce/bookadv/
Posts
Chapter 1 发现告警 2023年3月11日，上午11点，这是一个周末，大壮正在刷七猫免费小说，一条告警赫然出现在飞书监控告警群里。大壮点开看一下，虽然平常也会有一些 5xx 出现，但是10%这么高占比的有点离谱。大壮顺手就在飞书群@了值班人员阿新。但是阿新一直未读，过了一分钟，新的告警又来了，5xx占比来到了15%。 Chapter 2 接警启动 大壮意识到问题比较严重，立即将最新的告警消息创建了话题，@了Teamleader 阿茂。同时根据《业务线负责人和值班文档》多维表格文档，确定了业务线 owner 小美为【快恢负责人】，在话题中@了他。值班人员阿新同时也是项目的专职【通讯员】之一，也在话题群里@了阿新。接着发起了和小美、阿茂、阿新4人的视频会议。 视频会议： 小美、阿茂上线，阿新依然不在线。大壮反馈了问题；Teamleader
Posts
大家都知道接口文档的收益很高，但是编写接口文档可能被认为是耗时且繁琐的任务，而且开发人员可能更愿意专注于实际的编码工作。 文档有时候也有它的主要问题，一般是不准确，并且往往是因为过时了。如果不能一直保持百分百正确的文档是不能被信任的。 文档界诞生了一个活文档的概念，并且有以下四个原则： * 可靠：无论何时，文档都是准确的，并且与所交付的软件保持同步。 * 省力：最大限度的减少文档的工作量，即使软件发生了变更、删减或者添加，也仅需少量的额外工作。 * 协作：活文档可以促进所有参与者之间的对话和知识共享。 * 有见地：活文档会将人们的注意力引导到工作的各方面，从而提供反馈机会并鼓励深入思考。 今天我想和大家探讨前两点：可靠和省力。 接口文档自动化 protobuffer + protoc 插件 + openapi ，我认为是这一个“银弹”。 我们可以使用 proto 原型文件 + 插件 protoc-gen-gin-http 生成接入层的接口路由代码。还可以使用 proto 原型文件 + 插件 protoc-gen-openapi 生成 openapi 文件。 P
对比2个分支的差异，导出并写入到新的分支 git checkout master git diff master..feature/old-branch > my_change.patch git checkout -b feature/new-branch git apply < my_change.patch rm my_change.patch git commit -a -m 'commit message' 使用场景 时间较久的分支经过多次合并master之后，又经过多次修改，commit log 已经有点混乱了，非常推荐使用这个方式优化提交记录。
Go
新项目多采用 Go 的新版本，但老版本同样需要支持。版本管理略麻烦，查下来有4种方案，有的已不再维护了。 * brew switch * goenv * gvm * 自己编写简单的 Shell 脚本 前两个都不在维护；gvm 需要下载Go源码编译，时间略长。 看来自己编写 Shell 脚本可能是目前最好的方案；要做到 2 件事。 1. go 要指向正确的版本； 2. 正确的 GOROOT 环境变量； 第一种写法，修改软链，使用 gsed 变更 .zshrc 配置文件。（gsed 是 gnu 版本的 sed 与link 参数保持一致，brew install gsed 即可）。 gov18.
Git-Flow是什么 Git 诸多命令就像一个个零件，代码管理是够用的。但是工程化代码管理尤其是团队协作的工程化，就需要这些零件整合起来，形成一套工作流。Git Flow 就是这么一套工具。 http://danielkummer.github.io/git-flow-cheatsheet/index.zh_CN.html 安装 brew install git-flow-avh 初始化项目 git flow init # 然后一路回车 Which branch should be used for bringing forth production releases? - main Branch name for production releases: [main] Branch name for "
简述 1. 基于较为流行的谷歌 json 风格 google json style 1. 英文 https://google.github.io/styleguide/jsoncstyleguide.xml 2. 中文 https://github.com/darcyliu/google-styleguide/blob/master/JSONStyleGuide.md 2. 所有字段驼峰命名，接口使用：get post 1. get 获取数据 2. post 更新数据 3. post：请求 body 数据使用 application/json, 不使用 FormData; 4. 响应成功，
切换 host 之后，清除 dsn 缓存 访问链接 chrome://net-internals/#sockets 点击 Flush socket pools 一次，其他都不用点击了。 搜索引擎设置 访问搜索引擎设置页面 chrome://settings/search 管理搜索引擎和网站搜索-网站搜索-添加 1. cmd/ctrl + L 定位到浏览器链接输入框， 2. 输入 dict 按下 Tab 3. 输入想要翻译的单词 4. 按下 Enter 看似四步，简单上手后一气呵成！ 多搜索引擎管理 不同的搜索内容，应该使用不同的搜索引擎，就像你不能在 baidu 搜索技术关键词一样。 你可以设置，google搜索，输入 goo 按下
第一步 生成RSA密钥 $openssl OpenSSL> genrsa -out app_private_key.pem 2048 OpenSSL> pkcs8 -topk8 -inform PEM -in app_private_key.pem -outform PEM -nocrypt -out app_private_key_pkcs8.pem OpenSSL> rsa -in app_private_key.pem -pubout -out app_public_key.pem OpenSSL> exit 经过以上步骤，
-- resolve 指定ip访问 curl --resolve demo:443:127.0.0.1 https://demo/api.json
简单聊一聊用户系统的密码存储设计。 历史变迁 首先，最开始大家用的都是明文存储用户的密码，想着，反正存储在服务端，也只有服务端看得到， 但这些年这么多脱裤事件，终于意识到不能再使用明文了， 于是，大家改用 md5 等哈希算法，为用户密码“加密”，但数据库泄漏后，仍然可以使用 字典攻击 破解。字典攻击 是用一个字典文件，储存了单词、短语、常用密码和他们 hash 后结果。将密码与 hash 结果对比，就能破解。 为了解决这个问题，研发工程师又在密码的hash的过程中加 salt， salt是一串随机值，与 hash 后的密码一起保存在数据库。 这恐怕只能使用暴力破解了，但现在GPU的发展，使得暴力破解成为可能，如果被脱裤，则更容易破解。 同时期的 GPU 的计算单元比CPU多， L1/L2/L3缓存和控制器较少， 所以GPU非常适合做并行且无需内存参与的计算任务。 解决方案
文字中的空白到底是tab和空格？ 开发测试过程中，我们可能需要构造各种tab分割的文本数据，然而默认配置下，输入tab，就被转化成了4个空格，为了避免这些坑，我们来尝试做些处理。 显示空白 设置中搜索renderWhitespace，设置为all 这个时候，就能看出空白到底是tab还是空格，如图： 这一步操作不仅能显示tab和空格，而且区分了 tab 和 空格 * 拷贝文本，保留tab * 输入文本，替换tab为4个空格