自己配! 别乱下载那些大集成.
如果最基本的文本编辑, 就加个加行号就 ok 了.

顶部美化技术... 感觉应该韩国比较强. :D
没用过 mind, 但是 xfce 在用, 无非就是修改 panel. 美化这个事, 其实没什么太大意义, 看顺眼了都一样.

抛出新看法观点很正常, 起码说几个论据, 和怎么论证的吧?

你在哪看到的 mm/dd/yyyy 格式? 终端? 什么命令? 你想改哪? locale 是可以改的.

pi4+aria2(rpc)

我会用 ascii code 的方法. 有兴趣可以看看 vim 实现的"~"

@nahcikuy echo 23333 | echo 将会输出一个换行.

I created this little script about 5 years ago. I use it with my README.md files on github.
You can have a look at it, if it helps:
https://github.com/sk1418/ghtoc

@UnknownR 我们也有不同 stages, 有 fallback database, 但是这个不参与平时正常的运行, 只有正常的出问题了, 才会切过去, 而且数据不是实时同步的.
一般能到 production deployment 的阶段都是经过了测试的, 我们有 dev, test and prod three stages.
@wd
我们没有专门的部门 /团队负责 release. 正如我前面所讲, 我们有 100 多个 apps, 但是项目会按照业务的不同, 分为多个 squads, 比如咱们的 squad 负责某项业务, 提供了 1-10, 10 个 apps. 那么咱们这个小团队就要负责开发, 测试,以及咱们自己 apps 的 release. 至于 release 的周期也是咱们自己决定. 我们不可能有一个专门的团队负责所有 release. 大部分 squads 采用 scrum, kanban or "scrumban"来开发, release 可能随时要求, 也可能集中要求, 各个 apps 的 release 需求还不同, 让一个专门团队负责 release 有点困难. 我们只有一些重要的 apps 在 prod stage 运行期间, 由另一个公司负责监控, 但相关的 squad 是可以直接 prod release 的.

@wd 补充一下, 当前我们采取的措施前面已经说了, 可以勉强应付, 但是人为手工干预因素比较多, 而且需要特定人直接在数据库上进行操作. 这些严格讲不符合安全规范, 因为开发团队不能直接操纵 production stage 的数据. 另外一个人工干预也会有出错的潜在可能, 以及具体人员的依赖性.
所以我说现在的做法虽然能将就, 但我感觉不是 solution.

@wd 这个问题的描述我觉得还是说清了... 看来我的表达能力还是不尽如人意.
简单再说一下, 希望能表述更明白.
我们的 app 启动是有 timeout 的通常是 2-5min.超出了的话, 会有 alert, 这些管理不由开发团队负责, 甚至是另一个公司来监控, 每次这种都是要付费. 因为保险安全缘故,我们不能把 timeout 设置成比如 2 小时, 3 小时, 这样有时候会隐藏真正的问题. 所以数据库变更语句执行的时间如果较长, 我们会有问题.这是问题 1.

问题 2, 如果有 table 结构 rename, delete, 按你分享的, database changes 跟 deployment 分离对于我们就不一定适合. 因为先行手工执行了 db changes, 这个时候, 还在运行的 apps 就会出问题, rolling deployment 就被打破了. 就有了 outage..

对于问题 2, 不一定非要在 app 启动时做 database change, 任何时候都可以. 但是要求当前运行在同一 database 的所有 apps 到新的版本 deployment 结束并切换之前继续正常运行, 因为新版本不论是 deployment 还是 starting up 一旦有问题, 不能影响当前产品提供服务. 大概这个问题的困难也是在这里.

@momocraft 感谢你的经验分享. 我们也有不多的 scala 应用. 大概 3-5 个. 还有一部分 python 的数据分析 apps.
我们的大体数据库存储结构是, 主要数据库是微软公司的 azure, 然后部分 apps 都 etl 到自己的 postgres, 我说的问题对于这些访问 postgres 的应用来说并不困难, 我写了相关的脚本, 基于 postgres 的应用目前可以 deploy 到跟 running pods 不同的 database schema. 因为 etl 的数据可以随时重新刷一遍, 只是时间问题, 然后再在 openshift 中切换 pod,or configuration 即可

但是如果是与根源 azure 数据库打交道的应用程序, 就面临我上面的挑战了.

题外话, 我们大部分 database experts 都是具备很强的 oracle 背景的, 在实际使用中, 他们常常对于 azure 嗤之以鼻. :-D

@wd 对不起, 可能我在以上之回复中没说明白, 让你误解了. 我想表达的是我们现在所做的对于我们面临的问题来说, 不是 solution.

我们这里, 找实习和学生工, 基本上是做一些机械性的工作. 当然要知道 java 是什么, 大概代码怎么回事.
或者是某些文件 parsing, transformation 这种一次性的开发工作. 这就会有要求会相关技术.
一般不会让他们参与正式项目开发.
当然, 有例外, 比如某些成员虽然是实习生或者学生工, 但是能力很好, 会交给正式开发任务.

@wd "数据库变更应该和 app 是无关的" it depends... 如果你看了我问题的内容, 就不难设想, 如若我 delete 一个 column, 那么当前运行的 app 就自然会有影响. 所以你说的"每次 release 先做数据库变更，再 release app" 就不成立. 这也是我们现在尽可能避免(原则上禁止)做结构删除 /renaming 的变更. 但这不是问题的 solution.

@monsterxx03 我们的项目里, 大概有 3,40 个 apps 是客户直接用的, 也就是说对人的, 剩下大部分都不是对人的. 而且几乎没有流量低谷的时候, 各个时区都会有来往数据, 其中一些吞吐量还挺大. 每次产生未预计的 out-age 或者 downtime 都算是大事故, 因为各个 apps 之间都有通信.
虽然现在手工干预也可以凑合, 但是隐患挺多. 整个项目一共 100 多个开发人员, 并不是所有都对 database 的变动后果很了解, 也许在自己开发环境, 几毫秒就过去的几句语句, 到了 production stage 会产生意外的效果. 我们只有几个 database experts, 如果休假, 或者病假等, 也是问题, 而且直接手工操作 database 总觉得是有些不保险. 常有 squads 反应此类问题. db changes 和 deployment 这个问题一直也没有比较好的解决方法. 所以来问问.

@learningman 显然是白话, "文言"一说从何而起?

@WispZhan 我基本能理解提问中的问题以及描述, 通览寥寥回答, 也明晓其意.
然而到您这个回答, 完全不知所云. 忙 google 求解.尚知充血, 贫血, 仍有一"领域模型"之译文由来.
不由掩面忍俊不禁.

@msg7086 感谢你的解惑.
即是 spotify 已购了所囊之影音的最大疆域授权, 所以可以在互联网范围内提供服务.

youtube 中个人上传的影视资源恐不能被版权问题涵盖, 因为并非 google 主动而为.

此次理解希望不谬.