个人看法：你与别人讨论一个问题的时候，不应该说你的观点来自哪本书， 因为这没有任何说服力。
看书是为了让你看到更多的想法，成为自己的思想，为自己所用。所以，你与别人讨论时，应该把你的逻辑用严谨的话表达出来，才能说服人。说某个观点来自某本书没有任何意义。

是两只手都关节炎吗？
我曾经使用 mac 的触控板，导致右手关节炎。所以就再也不用了。

两个方案都各有优缺点，很多大厂使用的是方案 1 ，我现在使用的是方案 2 。

方案 2 优点
无论团队大小, 既然是微服务, 那肯定会为每个服务指定负责人, 而不会交错负责.
1. 每个人只需要关注自己负责的服务的代码.
2. 小团队,可以避免团队内有人随意修改他人负责的代码. 大团队,只开负责的代码仓库的权限.
3. IDEA 中只打开自己负责的代码, 搜索代码什么的都很方便.
4. CI/CD 方便
5. 版本管理方便, 减少代码冲突.

方案 2 缺点
1. 需要搭建 maven 私仓, 对所有的公共技术模块进行严格的版本管理, 在 base-pom 中对版本进行统一管理.
2. 降低开发者维护公共技术模块的意愿. 因为修改公共模块,哪怕只修改一行代码,都需要升级版本, 然后对很多 git 仓库进行代码提交. 服务发布前,还要把相关模块的版本从 SNAPSHOT 改为 RELEASE, 有点麻烦.

方案 2 的优点就是方案 1 的缺点.整体来看,我觉得方案 2 的优点更多更好.

Java 项目 在用 maven ，没有更换 gradle 的任何理由

当一个个体引起众怒的时候，大众不会去细究它哪些是好那些是坏，只管打倒它。我是支持这种行为的，矫枉必须过正。
辩证与客观只能存在于小团体。

如果还没有找到原因，那就用笨方法：控制变量，一个个尝试。
列出所有可能导致该问题的原因， 每次改变一个，观察执行结果。

既然用微服务了，那就可以异构微服务。
迁移原则是：仅在必要时或极低成本时迁移，C 代码以保留为主，迁移为辅。

* 在 nodejs 前再加一层，用于兼容微服务间调用方式，如 http 。
* 老代码以保留为主，分离为辅。
* 如果 1 个模块功能已经比较完善，那就不必要用 java 重写，直接 http 调用
* 如果 1 个模块在未来需要大量开发，那就用 java 开新服务。这样 1 个模块既有 java 代码，也有 c 代码。这个模块内部，需要功能间方法调用，如果功能简单，则可以直接以 java 重写，如果功能复杂，则 http 调用。


Dubbo 支持异构微服务，其他的技术栈你可以再找找。

Oppo k10

红米 k20pro 小屏+全面屏，没有可代替的新机，准备一直用下去

过敏性鼻炎 + 湿疹，阳的第六天。
原本我妈感染了一周，我都没一点事，后来被我老婆传染了。估计是距离她太近，病毒量太大了

switch 有氧拳击，每天 30 分钟。
我觉得对于不愿运动而且没有毅力坚持运动的人来说， 这个很合适。原因是：有氧拳击在各方面的负担都很低。
不愿运动的人，要想动起来，首先不能定一些需要付出努力才能实现的目标，比如每天室外 5 公里。有氧拳击可在任何地方任何时间使用任何设备进行。只需要 2 平米，一个显示设备，打开 B 站有氧拳击的视频，跟着练就可以了。每天只需要 30 分钟，就可以出很多汗。如果觉得时间长，每天可以只做一半，15 分钟。如果担心吵到其他人，可以带上蓝牙耳机。拳击动作还可以发泄压力。

关于为什么要跟着 B 站视频练，而不是使用 swtich ，我个人的原因是：买了有氧拳击后，发现节奏感很差，1 是两脚的前后摆动很别扭，2 是手柄的出拳触发不是很准，这导致我玩不下去。所以就跟着视频，用我自己的节奏来打，效果很好。

快贴 全平台

不会，因为 mac 与 windows 键位不同的根本不在于 command 与 control, 而是快捷键的理念不同，导致各种系统快捷键和三方软件的快捷键都不同。即使改了，也会有些快捷键的冲突，导致无法完全覆盖我常用软件的所有快捷键。
索性不改了，用的久了，就自动适应了，在 windows 多用鼠标点击，反正 windows 用的少，以 mac 为主。

正在使用，不错。

用了几次， 来反馈下。
搜索结果大部分都不是我想要的，与 mvnrepository 的搜索结果差距较大。建议把 usages 加入权重。

我最近也遇到了这种业务场景，由业务人员维护少量简单逻辑，来实现快速变化。最后的方案是让他们写 JXEL 。
事实证明，知识水平和智商正常的业务人员，半小时的简单培训后，就可以用代码写出基本逻辑。
所以，业务人员只是不懂语言特性而已，但人家是懂逻辑的，人家是有辑思维能力的。

每天，会用笔和纸简单辅助思考。想好后，再详细到文档