每月的最后一个周六上班

如果是 EF 的 Code First ，你可以贴下模型是怎么映射的。

有一些小技巧的，
比如，打包是移除掉运行时不需要的，例如 devDependencies ，通过`npm i --production`可以只安装 dependencies 包；
还有发布时压缩成 zip 包，可以把大小减少到 40-60MB ，如果压缩成 7z 包，可以减少到 30MB 。

这人素质好低

@mathgl 看来上班时还得试试扩大 limits ；
不过 socket.io 不仅仅是 websocket ，有一些封装和 trade off ，项目代码也有一些业务逻辑，实际跑起来不一定能达到理论上的极限。

@lujiajing1126 那个进程的 limits 里大部分值是 unlimited ，最小的数字是打开的文件描述符数， 65535 ，所以，恐怕瓶颈不在这里。

@rwecho 是啊

合同，我感觉是你签了，但对方上级没签，这样合同就不是有效的了。

object -> for...in
array -> for...of

if 是 HR/面试官说的 {
return 你要的多了 || 我们不要那么厉害的 || 茴字的四种写法都写不全，竟然要这么多 || 降低点期望怎么样 || 我们有更初级的职位，要不要考虑下
} else {
return 就是说说而已
}

have you tried turning it off and on again?


上面是玩笑，认真的说：
要不你重装下系统？
要不你在 postman 里发送个 http 请求，看看请求和响应有什么异常？

一般会等的。
但是我也遇到几个公司不等的，这样一般来说不靠谱，最好直接放弃。

@otakustay 确实很悲惨。
如果只有硬件够了，也不行，模型的缺陷也会有影响，可能连脏的方式都没有，例如你写 java 时就没办法内嵌汇编、在 web app 中没办法使用 native 系统接口

当现有模型的缺陷越积越多，会有新的模型出现的，逐渐替代现有的模型，可能是语言、框架、思想、模式、系统，技术就这样逐渐进步了。

你贴的链接的意思是，阅读源码可以更好地理解编程模型、思想、抽象、所调用的接口，没有提到优化。
不读源码的话，也可以通过阅读相应的文档来获得这种理解。
软件工程是对的，确实不应该依赖模型未定义行为，也不应该依赖未公开的接口（私有 API ）。
这样之后，如果还是遇到性能瓶颈，或者不能实现的功能，这算是所用的模型的缺陷。
这时最好换模型，不得已的话，读源码，用一些比较脏的方式来实现。