Docker
它藏在 /Applications/Docker.app 中，可以使用 find 命令查看： $cd /Applications/Docker.app $find . -name "docker" ./Contents/Resources/bin/docker 将 bin 目录拼接到 PATH 环境变量即可，一般可以追加到 ~/.bashrc ~/.zshrc 中。 export PATH=/Applications/Docker.app/Contents/Resources/bin:$PATH source ~/.zshrc 使环境变量生效，执行 docker 检查版本 $ source ~/.zshrc $ docker --version Docker
Posts
Grafana告警内容设置 告警内容分为：告警标题、告警说明、告警详情。告警标题和告警说明用来描述告警的规则。告警详情，描述告警的规则和具体的值。 告警详情 Description 设置 1. 打印所有的标签 {{ $labels }} alertname=High CPU usage, grafana_folder=CPU alerts, instance=server1 2. 自定义格式化打印所有的标签 {{ range $k, $v := $labels -}} {{ $k }}={{ $v }} {{ end }} alertname=High CPU usage grafana_folder=CPU alerts instance=server1 3. 打印单个标签 The host {{ index $labels
Go
哪些场景可以用到远程调试？ * Apple M1 M2 M3 不支持go 1.14 之前的版本 * Golang 部分依赖不支持 window 这两个场景推荐使用 Docker。 Debugging a Go application inside a Docker container | The GoLand BlogUpdated and validated on November 17, 2022. You can find more tutorials on how to use containers here. You may also refer to the Docker and
我们使用 git 进行版本控制，期间会触发很多事件，这些利用好这些事件做好自动化，能帮我提升效率。git hook 就是一个这样的工具，在特定的事件中执行特定的钩子。 ╰─➤ ls .git/hooks applypatch-msg.sample post-update.sample pre-merge-commit.sample pre-receive.sample update.sample commit-msg.sample pre-applypatch.sample pre-push.sample prepare-commit-msg.sample fsmonitor-watchman.sample pre-commit.sample pre-rebase.sample push-to-checkout.sample 设置钩子路径 git 仓库的钩子存放路径由 core.hooksPath 控制，默认是在项目的 .git/hooks。它不能使用版本控制
makefile 是一个文本文件，以下是一个子命令，包含： * 名称：支持英文、数字、连字符"-"和下划线 " _" * 注释：使用 "#" 表示注释，不支持 /*...*/。推荐写在名称的上一行 * 命令：任何可在 shell 执行的命令行语句。必须是\t 开头，否则报错 make: Nothing to be done for 'build'. * .PHONY：可选，命令声明了 .PHONY，执行时将不会输出具体命令到终端。在一些 CI 工具中可以起到过滤敏感信息的作用。 .PHONY: build # 编译构建 build:
一个项目能够快速迭代上线，肯定少不了测试环境。而开发如果要在本地切换使用测试环境的配置，一般是手动修改，还可能提交到生产环境，会非常繁琐。 因此一个“伟大”的工具诞生了：easyconf。
Chapter 1 发现告警 2023年3月11日，上午11点，这是一个周末，大壮正在刷七猫免费小说，一条告警赫然出现在飞书监控告警群里。大壮点开看一下，虽然平常也会有一些 5xx 出现，但是10%这么高占比的有点离谱。大壮顺手就在飞书群@了值班人员阿新。但是阿新一直未读，过了一分钟，新的告警又来了，5xx占比来到了15%。 Chapter 2 接警启动 大壮意识到问题比较严重，立即将最新的告警消息创建了话题，@了Teamleader 阿茂。同时根据《业务线负责人和值班文档》多维表格文档，确定了业务线 owner 小美为【快恢负责人】，在话题中@了他。值班人员阿新同时也是项目的专职【通讯员】之一，也在话题群里@了阿新。接着发起了和小美、阿茂、阿新4人的视频会议。 视频会议： 小美、阿茂上线，阿新依然不在线。大壮反馈了问题；Teamleader
简述 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. 响应成功，
简单聊一聊用户系统的密码存储设计 历史变迁 首先，最开始大家用的都是明文存储用户的密码，想着，反正存储在服务端，也只有服务端看得到， 但这些年这么多脱裤事件，终于意识到不能再使用明文了， 于是，大家改用 md5 等哈希算法，为用户密码“加密”，但数据库泄漏后，仍然可以使用 字典攻击 破解。字典攻击 是用一个字典文件，储存了单词、短语、常用密码和他们 hash 后结果。将密码与 hash 结果对比，就能破解。 为了解决这个问题，研发工程师又在密码的hash的过程中加 salt， salt是一串随机值，与 hash 后的密码一起保存在数据库。 这恐怕只能使用暴力破解了，但现在GPU的发展，使得暴力破解成为可能，如果被脱裤，则更容易破解。 同时期的 GPU 的计算单元比CPU多， L1/L2/L3缓存和控制器较少， 所以GPU非常适合做并行且无需内存参与的计算任务。 解决方案
常规的 git 授权有2种方法，ssh 协议对应的 ssh-key 和 https 协议的用户名密码验证。 git over ssh 我们使用 ssh-keygen 生成公私钥，输入 ssh-keygen 一路回车，ls -alth ~/.ssh 可以看到生成2个文件 id_rsa、id_rsa.pub 也就是密钥和公钥。 $ ssh-keygen ... $ ls -alth ~/.ssh -rw-------@ 1 brian staff 2.6K Jun 15 2020 id_rsa -rw-r--r--@ 1 brian staff 584B Jun 15
makefile 是一个文本文件，以下是一个子命令，包含： * 名称：支持英文、数字、连字符"-"和下划线 " _" * 注释：使用 "#" 表示注释，不支持 /*...*/。推荐写在名称的上一行 * 命令：任何可在 shell 执行的命令行语句。必须是\t 开头，否则报错 make: Nothing to be done for 'build'. * .PHONY：可选，命令声明了 .PHONY，执行时将不会输出具体命令到终端。在一些 CI 工具中可以起到过滤敏感信息的作用。 .PHONY: build # 编译构建 build:
一个项目能够快速迭代上线，肯定少不了测试环境。而开发如果要在本地切换使用测试环境的配置，一般是手动修改，还可能提交到生产环境，会非常繁琐。 因此一个“伟大”的工具诞生了：easyconf。
公司项目和个人项目不能耦合特别是发布到公开项目的“提交人”信息最好不要和公司一致； 但，难免忘记配置，需要重新刷； 推荐的方式是，放弃全局配置，每个项目独立配置 user.name user.email 步骤 1. 克隆bare项目 纯仓库 git clone --bare <https://github.com/user/repo.git> cd repo.git 2. 编写脚本 注意替换 OLD_EMAIL CORRECT_NAME CORRECT_EMAIL #!/bin/sh git filter-branch --env-filter ' OLD_EMAIL="old@
本文介绍了通过 Git 命令操作，文末有 Goland IDEA 的简便操作。 查看日志，找到需要合并的多个分支的上一个起点，比如 18a14636 $git log --oneline d1503601 feat(link_video):埋点统计 ad94a443 feat(bottom_ecmp_policy):策略名称唯一验证修复 043fa7de feat(bottom_ecmp_policy):策略名称唯一验证修复 32fae648 feat(bottom_ecmp_policy):策略名称唯一验证 80cee6b4 feat(bottom_ecmp_policy):按ecpm正序排序 f955a20e feat(bottom_ecmp_policy):新增策略类型'
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/
Chapter 1 发现告警 2023年3月11日，上午11点，这是一个周末，大壮正在刷七猫免费小说，一条告警赫然出现在飞书监控告警群里。大壮点开看一下，虽然平常也会有一些 5xx 出现，但是10%这么高占比的有点离谱。大壮顺手就在飞书群@了值班人员阿新。但是阿新一直未读，过了一分钟，新的告警又来了，5xx占比来到了15%。 Chapter 2 接警启动 大壮意识到问题比较严重，立即将最新的告警消息创建了话题，@了Teamleader 阿茂。同时根据《业务线负责人和值班文档》多维表格文档，确定了业务线 owner 小美为【快恢负责人】，在话题中@了他。值班人员阿新同时也是项目的专职【通讯员】之一，也在话题群里@了阿新。接着发起了和小美、阿茂、阿新4人的视频会议。 视频会议： 小美、阿茂上线，阿新依然不在线。大壮反馈了问题；Teamleader
大家都知道接口文档的收益很高，但是编写接口文档可能被认为是耗时且繁琐的任务，而且开发人员可能更愿意专注于实际的编码工作。 文档有时候也有它的主要问题，一般是不准确，并且往往是因为过时了。如果不能一直保持百分百正确的文档是不能被信任的。 文档界诞生了一个活文档的概念，并且有以下四个原则： * 可靠：无论何时，文档都是准确的，并且与所交付的软件保持同步。 * 省力：最大限度的减少文档的工作量，即使软件发生了变更、删减或者添加，也仅需少量的额外工作。 * 协作：活文档可以促进所有参与者之间的对话和知识共享。 * 有见地：活文档会将人们的注意力引导到工作的各方面，从而提供反馈机会并鼓励深入思考。 今天我想和大家探讨前两点：可靠和省力。 接口文档自动化 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 的新版本，但老版本同样需要支持。版本管理略麻烦，查下来有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. 响应成功，