@azhangbing #137 不是帝国主义亡我之心不死，打压国产吗

@azhangbing #25 这话好耳熟 如果没崛起降价的时候，话术是什么来着

外包加班吗？

可以仲裁的把

这个有点像风控的提示 多个控制点并发校验的场景

@adoal #24
我认为你的观点 “基础设施开发和业务开发应该是两个独立的领域，由不同的团队或个体负责，需要高效利用现有的基础设施软件和运维手段”是绝对正确的，解耦基础设施和应用组件非常重要，却存在现实困难。
---

对于"all in code"，我理解的是使用 gitops 的形式，使得基础设施能够以一个可预期的状态进行运行。这样的方式不仅提高了我们对系统状态的预测能力，也使得我们能够更容易地进行版本控制和回滚。我想你说的"code”应该是指编程语言，如果是指编程语言的话，的确是对于平台安全存在风险，应该更广泛的采用可靠的其他基础设施中间件，而不是自己开发。这个很像之前我做 devops 时的领导的观念，当时我还在 java 应用开发的角色上没有转换过来，对开源基础设施的文档的信心不足（因为 java 界开源文档质量不太行）
---
关于 spring 的 fat-jar ，我有些不同意见，就是我认为基于 springboot 的 fat-jar 应当视为一个应用程序级别的交付，将内部的 web 服务器基础设施当作应用的一部分，各个应用之间的 web 服务器应当隔离开，这样能在测试期间应用就具有更高的稳定性，同时也能提高平台的安全性。对于甲方的交付是按照应用交付的，而不是交付软件代码，还需要甲方的其他基础设施。

@yimiaoxiehou #16 我是没理解这个 coding 指的是什么 ，我主要是想了解类似 IaC as Code 这种形态是否会受到甲方偏见

@adoal #5 没听明白 老哥你是不喜欢全 in java 还是全 in coding ？ 如果是后者 我想问下为什么？

可以啊

不能上牌不要选摩托。没保险有风险。建议电动车。10 公里单程骑自行车也就 40 分钟，主要是一身汗 。

到了机场问工作人员怎么跳过安检这个步骤吧 感觉有点紧张 不是完全不行 但是晚点 30 分钟你就悬了

这个现象在心理学上被称为“通知疲劳”（ Notification Fatigue ）或“警报疲劳”（ Alert Fatigue ）。当用户接收到过多的通知，他们可能会感到厌烦或者不再注意这些通知，这可能会导致他们忽视了一些可能重要的信息。这种现象在各种情境中都可能发生，包括但不限于电子邮件、社交媒体、手机应用等。

@shyrock #34 不追涨杀跌的早就死透了 咋老有外行说追涨杀跌是韭菜呢 韭菜的最大问题是犹犹豫豫 进的不够快 出的不果断

@Shielber #13 你这贵的离谱 我用的是 200 一个月的 plus 号被封了包换新

@daley #1 app 监管之类的障碍太多了 不然谁开发小程序啊