打 bash 回车试试？

promise 没学明白就拿 async await 来写代码就这样了

用 new promise 来包别的 promise 已经是反模式了，还再加上 async await

这代码没治了，从头重写吧

什么不仁不义的没意义，你要做的是收集更多的情报、证据和法律知识，结合自己的情况来看下一步，而不是在有一百种更好的做法的时候就直接考虑双输的报复性手段

公司对你没有高要求，不代表你就不能用更高更好的技术来完成公司的项目

都工作两年了还觉得自己是个学生？你已经是个成熟的社会人了，该学会自己成长了

所以你觉得不想要看书的建议，但你现在也就自己看看书？你觉得看书对你成长足够了，那就继续看书；觉得不够，那要么别钻在书里，要么好好想一下为啥看书成长不起来

https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution

上传包给 apple 签名，或者等作者发布更新

又是一个不遵守 semver 的项目

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

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

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

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

假设你说的几个小时是两三个小时，那么算上沟通、测试和交付，就算是配合默契的人也至少一个工作日，两万块月薪的程序员一天的成本是 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 或者可以忽略的程度的。

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