@Jooooooooo 还是一样的问题，自动化算不算运维的事情。自动化没啥尽头，不然大家也不会忙着搞 AIOPS，很多配置要参考经验的成分。

@di94sh 这个分工感觉还是需要的，人的精力有限，就比如 MYSQL，开发者到底要搞到多深呢，CNCF 的东西普遍简单还算好，以前 apache 的中间件一个比一个复杂，精力更不上

@gargar 咋说呢，我感觉 CNCF 的东西和开发靠的有时候太近了的，比如说，我们做一个告警的集成，就要和 alertmanager 写 webhook，但是出了问题就要开发去检查配置对不对，运维说我让他跑起来就可以了，对于这个应用的设置感觉还是属于开发的，很讨厌这种用软件的工作内容。

推荐看看 CSAPP

B 站目标不一直都是做 Youtube，只不过之前都是二次元的声音比较大吧。。

赞同楼主，我有一年从 wiz 迁移到 有道，我就已经受够了，这种笔记类型，你如果觉得自己需要保存 10 年以上的话，还是用最基础的文件保存吧。坚果云备份一下即可。

太正常不过了，我们家那的毛坯房也没有预先通，都是强电改造的时候让师傅一起做弱电，因为这种需求本身就很少有人要，开发商只需要满足 90%的客户。

也就是 HTTP 和 GRPC 选一个咯，觉得 HTTP 不好用，就 GRPC 嘛，自己定数据格式都是在作死的边缘疯狂试探。

@amwyyyy 有没有那种可以快速查阅的参考表，benchmarks 需要跑一边，有时候单机还不够，一套走下来时间有点久。

@hantsy 上帝归上帝，凯撒归凯撒。SQL 归 XML 管，代码逻辑归 JAVA 管，认可这个才有后面用 Mybatis 的共识。

@sagaxu 单纯说的 SQL 语句，这个 XML 表达能力 和 JAVA 差不多平级，SQL 本身就是一串文本，不需要什么类型之类的东西。 对于我来说，我觉得放在 Java 里面本身就是一种污染，因为那部分我的逻辑我认为归属于 SQL 的范畴，不是 Java 所编写的业务系统的范畴，我更倾向于把 SQL 查询作为一个黑盒看待。

@hantsy 以前我也这么用，JOOQ 之类的也是如此，但是有一些很麻烦的点，比如经常需要判断 null，然后确定是不是要进行增加查询条件，这一部分代码我认为是对代码逻辑的污染，就有点像注解太多对代码的理解产生了干扰，不如把这一些东西都扔到 XML 里面，在业务层只是增加 @notnull @nullable 来确定是否可以为空给调用者警示即可。

另外，HQL 生成的 SQL 非常的啰嗦，复杂查询并不是很友好，尤其是需要 DBA 帮助优化 SQL 的时候还需要 DBA 先简化。JOOQ 这点做的就挺好，所见所得。

分层 + 模块化
-----

分层：把相对独立的一层当成一个黑盒处理，比如写 Java 的时候，你可以认为操作系统那是一个黑盒。先把最大的分层搞出来，每个分层里面还有自己分层，俄罗斯套娃。

模块化：每次就讲一个小模块，分层之后里面总是有几个模块，分开讲，模块很复杂的话，里面再分层+模块。

@hantsy 早期 JDK 不支持多行 SQL，写 native 很恶心，不如直接 mybatis 写 xml 里面。复杂查询的 hql 也不是很好用。 总之连接数据库的操作都不太爽。

Jooq 好一点也好不太多，Mybatis 就和写 Sql 没啥区别，Jpa 复杂 Query 还不如写 SQL 。
总而言之，都不太爽。

同样有肾结石做过输尿管软件的前来报道，不过有几个事情还是值得注意的：
1. 我是肾脏憩石（也就是结石在肾脏的肉里），软镜取不干净（上海市一做的，也算是顶级了），其实平时跑步什么的也不会疼（从来不疼，体检才知道的），我自己架不住烦的去做了，结果取了一部分还有一部分取不出来，为了取那一部分还割了一点肉，如果有类似的情况其实可以不用做，效果不明显。

2. 做完肾结石手术之后复发率还是很高的，住院期间我和病友都沟通了下，70%以上都是二进宫了。我查了下论文也有部分论文认为手术会导致后续发病率提高。

3. 喝水效果有限，但是不喝水那是万万不能。指望喝水喝出来是不太现实的哈。

4. 手术最疼的是最后一次无麻醉取软管，不过和肠镜比起来，我还是觉得有痛肠镜更疼。

@653513754 以前我也这么想，后来改观了，造零件也造了几年了，这些零件背后还有数控机床，还有冶金技术吧，无穷无尽。

@azuki Nice 。