因为有饭吃是能写代码的前提啊。

我就喜欢订阅制。订阅制保证作者有饭吃有计划来更新新功能和维护，而不是在被迫刷版本收费升级和饿死之间两难。

为什么好用的工具容易死？因为赚不到钱，订阅还被骂，人不吃饭，就会死。

至于你现在能免费用到的好用的东西，要么是有别人（或者企业）出了更大的价钱养起来了，要么是其实根本不需要维护，凭早期作者靠爱发电的累积就行

假设你说的几个小时是两三个小时，那么算上沟通、测试和交付，就算是配合默契的人也至少一个工作日，两万块月薪的程序员一天的成本是 2000 块（外包时薪翻倍 /公司雇佣要交金税行政 hr 等）

elk 能做这个事情，但如果你已经说完整你的需求没啥别的坑的话过于复杂了，直接 prometheus 就行，要 kibana 那种完备的节目的话上 grafana

云程序员来了！
首先我没用过 echo （略

golang 的 struct 不是 class，不要试图带入基于 class 的 oop 的范式

一般而言，要复用用组合，要多态用 interface，要封装分 package 用 unexported type/field 完事儿

//要泛型等 go2

osx+chrome 77 没有这个问题，跳了完整地址以后选区符合预期

- 包容低信息量，低效率的沟通方式短期看也许是“包容” “新人友好”，长期看来就是不利于社区发展。解答问题的人的时间就是比提出问题的人的时间更宝贵，求助方就是有义务花更多的时间来攥写问题。你说这里主流是前端我表示怀疑，但我愿意相信这里赞成黑客文化的人的比例是中文社区当中非常高的，就是排斥低效沟通

排斥低效沟通的意义就是净化社区提高所有人的沟通效率，只要对事不对人，就没有问题

- 互联网也好 B 端业务也好，OLTP 也好 OLAP 也罢，确实对 SQL 有非常不一样的考量的角度，那么没讲清楚背景信息还不就是原帖楼主的锅么？所以不用浪费时间讲统计如何如何，实时如何如何，索引如何如何，楼主自己不讲业务不讲背景，与其自己树靶子打，不如把时间留给更宝贵的事情上，把树靶子的人当靶子打更无聊

未经优化 php5 都比 java 快，正常操作
上了 laravel php7.4 比裸 php5 慢，正常操作
上 spring 慢多少我没概念

合理的优化过后，什么 php5 还是 7，java 还是 python，laravel 还是 spring 全都不是瓶颈

github 还用着 RoR 呢啥时候性能有问题了

要服务欧盟用户就要，形式可以一定程度上自由 （比如如何提供数据导出功能，处理删除数据的周期，数据的保留期等）

这个法案争议点之一就是实行困难，监管方法不透明，潜在的选择性执法等

但是用户按 GDPR 给你发 request 你没有及时回应的话，就可能被送上法庭的，你什么都没做的话，打官司肯定打不赢

关于坑的话，一个坑就是你又得按 GDPR 删除数据，又不能真的立刻物理删除（否则执法部门来调取证据又拿不出来），得有一个数据保留期。还有就是自己业务的关联性数据、属于多个用户的数据等情况的处理了

反正公司有法务就全听法务的，没法务就自己找 GDPR 的规定和相关资料按自己的理解做

所有用乘法预估时间的，到我这里都过不去，你可以拆分出，新建项目仓库半天，自测改 bug 一天，也可以预计开会浪费一天，甚至是太累了估计要请假半天也行，但用乘法的别想过我这关

拆分任务
至少到半天的精度（也就是子任务时间不超过半天）

如果拆分不出来，那就预估一下你需要多久才能把这个拆分做出来

十个工作日的项目，花整整一个工作日用来拆分和估时间是很合理的，也是能保证项目进度可控必须的工作

我也挺常用这个功能的，看了 chromium.org 相关的 issue 讨论，还是理解了

作为替代，现在能用的操作有 2 种：往下拖出新窗口，关闭老的窗口 or 拖到最左，然后用关闭右侧功能

未来扩展会有接口能力自定义这里

是否有影响影响多少用户多少时间取决于你们的部署流程是否正确
能否观测、监控到这种影响取决于你们的基础设施是否完善

一个很基本简单的方法论：如果你要修复或者改进一个问题，就必须先确保你能够观测、重现或测量它，否则你做的一切改进都是没有意义的。在建立了观测手段以后，减少更新代码对用户的影响这种属于常规基础的问题，找一些实践跟着做就行，很容易降到 0 或者可以忽略的程度的。

基于你其实并没有说你们的情况，所以这里即使说了一些实践做法的人也都只是随意说一些常见的可以做的事情而已

试了一下，用作编辑器用太重太骚了，但给 terminal 用还行

改表名难道不是毫秒级的暂停么？

id 是自增或者趋势递增的么？你测试用 asc 测试和业务只用新数据是矛盾的
如果是 uuid4 这类分散的，更没有理由 order by id 了

你自己贴的链接里答案写的很清楚了

馊主意

这和写一个巨大的 main()处理所有业务有什么区别呢，等客户端发版了不能改了，产品需求又改了，你这个接口就得 if 插入 A 表记录 {一坨业务} if 删除 B 表记录 {另一坨业务}

业务上是不同的对象操作就应该写不同的接口，如果你写一组朴素的 CURD 的接口还觉得费劲，那你要做的是做或者加强你的框架来减少这类接口的开发成本，而不是写一个通用的接口然后等着需求迭代把他变成怪物

加相机贵两千有人买单，你觉得加相机不值，但市场（或者是平均消费者）不认同你的观点

我坐飞机不托运行李，为什么没人生产不带货舱位置加大的飞机？
我用笔记本从来都是外接屏幕用，为什么没人生产不带 A 面的笔记本？

先 nsfwjs 之类的开源方案初筛，可疑度高的扔收费服务复查，这样能兼顾整体性能、准确度和费用