致力于分享有关软件开发和技术创新的见解和经验。
在搜索时使用英文关键词，提高结果质量。尽量使用 google.com 以下搜索引擎技巧在 google.com 进行测试，效果都很好，前三个非常常用且强烈推荐。 使用精确搜索 * 建议： 使用双引号 "" 搜索完全匹配的短语，避免无关结果。 * 示例: * "Java NullPointerException" fix * 场景： 找到错误信息的精确解决方案。 利用站内搜索 * 建议： 使用 site: 限制搜索范围到特定网站。 * 示例： * site:stackoverflow.com "TypeError: undefined is not a function" * 场景： 搜索 Stack Overflow、官方文档或技术博客的特定内容。 一些关键词 * 建议:
开启代理后，部分应用的网络请求也不会使用代理。比如终端，一些代理程序提供 export http_proxy=http://127.0.0.1:1087; export https_proxy=http://127.0.0.1:1087; export ALL_PROXY=socks5://127.0.0.1:1080; docker 也需要作此修改。 docker 设置代理 Settings - Resources - Proxies 打开 Manual proxy configuration，填入 http://127.0.0.1:
重构不必谈之色变。 它也不是洪水猛兽，而是开发过程中持续进行的优化过程。让我们开始学习这个主题，重新认识它的价值。 🌟整洁代码 重构的主要目的是消除技术债务。它将混乱变成整洁的代码和简单的设计。 * 对于其他程序员来说，整洁的代码是显而易见的。 我并不是在谈论超级复杂的算法。糟糕的变量命名、臃肿的类和方法、魔法数字 - 等等，所有这些都会让代码变得混乱和难以理解。 * 整洁的代码不包含重复。 每次你需要对重复的代码进行更改时，你都必须记住对每个实例进行相同的更改。这会增加认知负担并减慢进度。 * 整洁的代码包含最少数量的类和其他活动部件。 代码越少，脑子里需要记住的东西就越少。代码越少，维护工作就越少。代码越少，错误就越少。代码就是责任，保持代码简短。 * 整洁的代码通过所有测试。 如果只有 95% 的测试通过，你就知道代码不整洁。如果测试覆盖率为 0%，你就知道你完蛋了。 * 整洁的代码维护成本低！ 🗑️技术债（What） 每个人都尽最大努力从头开始编写出色的代码。可能没有程序员会故意编写不干净的代码，从而损害项目。但是干净的代码在什么时
排查1个异常接口，学到一个降本和接口提速的新思路。另外找到1个charles的"bug" 现象 测试同学反馈在iOS13设备上请求接口报错，将请求复制为 curl 命令。分别导入 apifox 和 在终端执行： * 在 apifox 请求正常 ✅ * 在终端请求失败 ❌ curl: (56) Failure when receiving data from the peer 测试同学又反馈另一个手机支持请求接口返回正常。 定位 有了正常和错误的请求curl，那直接对比二者差异就很简单了。对比发现，在终端执行失败的请求中多了一个较大的Cookie: app_token。按历史经验基本能确定是因为 Cookie 这个 header 条目太大，超过服务器的限制。 找云平台确定相关配置： ELB http1: header头限制 128KB，body 限制一个10G http2:
1. 编辑 kube-proxy 配置 编辑 kube-proxy 配置以启用 ipvs 模式。您可以使用以下命令编辑配置： kubectl edit configmap kube-proxy -n kube-system 在配置中，找到 mode 字段并将其设置为 ipvs。例如： apiVersion: v1 kind: ConfigMap metadata: name: kube-proxy namespace: kube-system data: mode: "ipvs" 保存并关闭配置。 2. 重新启动 kube-proxy 重新启动 kube-proxy 以应用新配置： kubectl rollout restart daemonset kube-proxy -n kube-system
K8S 为什么需要 Service？ 1. Pod 的 IP 不是固定的； 2. 一组 Pod 实例之间有负载均衡的需求； 上机操作 以下使用 minikube 作实例： # 安装 brew install minikube # 启动 minikube start # 创建 ~/.kube/config 请注意先备份 minikube update-context # 进入宿主机 minikube ssh 集群启动后，创建 Deployment 和 Service apiVersion: v1 kind: Service metadata: namespace: default name: nginx-svc spec: type: NodePort selector:
1 docker 是什么，解决什么问题？ * docker 将要程序和环境一起打包成一个镜像，可保证环境一致性。 * docker 容器启动速度非常快，快速部署和扩容。 * 每个镜像有独立的版本，可以用于快速回滚。 还有依赖管理、资源隔离、可移植性等特点。 2 镜像 2.1 基础镜像是什么？ docker 是由多层(layers)组成的，每一层代表镜像的一次变化，这些层叠加在一起，形成一个完整的文件系统。基础镜像是构建容器镜像的起点。可以在其上安装和配置应用及依赖项，就是叠加层。 基础镜像有： alpine (https://hub.docker.com/_/alpine) busybox（https://hub.docker.com/_/busybox） 2.2 Dockerfile 有了基础镜像还不够，还需要安装必要的依赖。我们公司选择的基础镜像是 alpine
我们使用 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。它不能使用版本控制
它藏在 /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
CSV 格式 RFC 4180 完整说明：引号规则、转义、Go/Python 示例、常见陷阱