为啥大家觉得工程质量和钱没啥关系呢，写好写坏都一样拿钱呢？
在一个比较正规的公司，你写的代码质量不达标，就过不去 code review 和 ci 这关，会影响你的代码合并入产品的速度，影响你的绩效。

你对代码质量和好的工程实践没有概念，如果你做工程经理，你的团队的效率就会差，迭代的速度大幅减慢，欠一屁股的技术债直到代码无法维护。那公司怎么放心给你升职做经理呢？


除了平时的工作，你也没法参与开源社区，不懂如何给社区贡献一些高质量代码，那怎么学习和提高自己的水平呢？

工作大部分时候都是个团队协作的过程，保持代码质量，方便自己，也方便别人，提升团队的工作效率何乐而不为

> 大哥，你是个程序员，你连自己写的代码是怎么跑的都不知道的话，转行好吗？

在公司干，或者去开源社区，大部分代码其实都不是自己写的。。这个时候少个类型系统你就知道有多难受了

了解一下： https://skaffold.dev/

端口转发 + 自动容器 rebuild+部署 + 代码同步 + 日志转发，我用着感觉不错。

#3 不错。特别是一些有状态，分布式的组件，跑在 k8s 还是需要很多专业知识的。如果能对开源社区贡献一些 operator 的更好了。
还有一种路径是，是做 k8s 生态的运维工具，这块东西还比较新，类似 weaveworks 搞的那些工具

老铁，这是个经典的背包问题。你希望商品总价值为 19.7 * 400 = 7880 。
随后动态规划可解之

这个叫代码实时协作，不叫代码审核吧？ code review 一般是 async 的，他弄完找你看，你给评论和建议之后，他再回去改。

不纠结于一定用 intellij 的话，可以试试带协作功能的 webide，例如： https://replit.com/

很好奇老哥你们是做什么产品的

有了 deadline，有了合同，保证你天天忙的顾不上打游戏。

这个观察多半是错觉，数量肯定还是 java 不成比例的多。
但如果真是去拿 go 搞 crud，这个和 java 搞有啥体验上的本质区别？
如果是拿 go 去搞后端基础件开发，补的东西就不光是学个语言这么简单了，都算换了一个方向工作了。

arm 的数值计算有什么技术进展吗？指令集带来的差异，下层的库能拉平性能差异么？求科普

What I cannot build is what I cannot understand. 用起来，做东西。

1. kubectl 提交 yaml 后，首先客户端验证，验证 yaml 的定义是否正确；如果正确的话，生成发给 kube-apiserver 的 request
2. kube-apiserver 收到 client 发来的 request 之后，进行一些列的 client 认证和鉴权，确保 client 有权限创建资源。
3. request 被一些列 adminssion controller 拦截，进行一些额外计算和默认值计算，例如设定初始资源需求（如果 client 没有指明的话）。
4. 创建资源对象，存盘到 etcd
5. 资源对象存盘后，deployment controller 开始控制 loop，创建 replicaset
6. relicaset controller 开始创建 pod 资源； pod 对象存入 etcd，进入 pending 状态
7. scheduler 开始介入，开始检查各种 scheduling 限制（例如 taint，affinity ）和资源需求，然后找到可以满足这些条件的 node 。找到 node 后，创建一个 binding 对象，发还给 kube-apiserver，pod 进入 scheduled 状态。
8. node 上的 kubelet 会定时查询 apiserver，收到 pod 创建事件后，开始在 node 上启动 pod 的准备工作。这里过程包括，准备存储，拉去 image pull secret 等。
9. kubelet 通过 CRI 通知容器运行时（例如 docker ）启动一个父容器。这里的容器会处于暂停的阶段（直到所有设置完成）
10. kubelet 通过 CNI 设置容器的网络
11. 所有设置完成后，开始创建真正的应用容器，包括 init container 和用户指明的其他容器
12. 完成工作。

我的理解是，这个整个过程有点像是个状态机。

参考文献： https://github.com/jamiehannaford/what-happens-when-k8s

一般都是弄个脚手架开始撸。
我之前用过 kubebuilder，跟着教程走一边就熟悉基本功能了

https://book.kubebuilder.io/

可以放在 serializer 里面 override create 和 update 方法。
或者放在 model 层，override model manager 的类型。

两个都可以，第二个方案代码更干净一些。

因为 aws 实在太复杂，所以才会有 digitalocean 这样的厂商的生存空间。
中小型企业上 DO 的船也是挺多的。我的个人项目也喜欢用 DO 。

aws 的 vendor lockin 又很严重，一些 managed service，虽然都是基于开源改的，但是夹带私获很多，例如最近撕比的 elastic vs opensearch 。一旦用上了，再往外挪就不是那么容易了。

可以把你的博客个人项目什么的全部迁移过去，最常见的几个服务 EC2, RDS, S3, CloudFront 用用，注意别破产。。
其他的服务实在是多如牛毛，基本只有真的用到的时候，才会去查文档去看怎么用，个人项目很少使用到。

还有一种方法就是出来创业，被逼着没办法只能研究 aws 怎么回事。之前有两段创业经历，熟悉了 EMR, EKS, ECR, Athena 这类个人不太用的服务