我总是能在各种地方见到橘子大大。。

@mooncakejs 不存在什么变成是坑，它已经是坑了，前人没文档，我起码还写文档，我走了总不会比这更坑。现代化工具不一定是指对项目代码做破坏性变更，搭些 api 管理平台，做些 ci 方面的工作，风险总不高

一样啊。。哎，刚进一家传统公司，待遇不错，然而技术栈老旧项目代码耦合严重，正想着怎么重构
楼上老哥们都觉得可以摸鱼，然而我觉得做需求的时候在一堆屎山中遨游也是很累的。。明明各种现代化工具可以极大提升效率，然而你有劲使不上，原本一天的需求得做三天
我想我还是先重构掉才能有时间摸鱼吧，不然被人为地强行拉低效率也很痛苦，时间久了心态会炸

你去游泳，他给你一个保险柜钥匙，你下次拿钥匙开保险柜，只认钥匙不认人

@azh7138m emm, 好像也是...那就这样吧
只是想自己拿着 koa 照着 egg 撸一下, koa 不帮我加载路由咯

@menyakun
@VDimos
是 Node 环境, 其实我就是想扫描一个目录下的 router 注册下

@azh7138m require 的话会丢失类型吧, 需要手动 as 吗? 这个路子好像可以...

普通人靠静态类型的类型检查和单元测试, 巨佬靠形式化验证...

除了不是 ts 写的，其他还挺好的，今天看到对 ts 的支持也有所提升了

城中村和公寓随便租吧，不过公寓通常也是城中村改造。。搞不好还有甲醛，小区一房一厅的房型比较少吧，3000 可能也不容易

自从以前玩 wow 打 pvp 精心设计了 100 多个键位，左手已经能够覆盖 1/3 个键盘，yhn 左边的任意组合键都感觉还算方便。。

puppeteer

@azh7138m 关于 callback 是同步异步调用的, 因为楼主看了 You don't know JavaScript 总结的(非贬义), 这部分也基本上和原书的意思差不多
大意是很多人看着 callback 的 API, 就想当然认为这个 callback 会是异步执行, 于是自己的代码依赖于这样的执行顺序, 导致可能结果不符合预期. 但其实我们都知道, 一个 callback 是同步调用还是异步调用从 API 的签名是看不出来的, 即我们不能信任 /依赖 API 对 callback 的执行顺序, 这个执行顺序是不可靠的, 也是书中提到信任问题的一部分.
书中认为这一问题的原因是各个库之间对于 callback 的调用时机缺乏统一的规范, 而 Promise 作为一个规范提供了信任背书, 明确赋予了 callback 异步调用的含义, 所以解决了之前的信任问题, 让人可以看到 API 的签名返回 Promise 就可以确定这是异步 API.
大概是这么个意思...但是可能因为楼主是总结精简了一些, 导致理解产生了一些偏差...

我觉得楼主的附录里还应该包含一个 You don't know javascript 的 Promise 章节。。

toml+1
yaml 三十行以内还行

@Cbdy "可以认为 CORS 是对早期 HTTP 协议的一个补丁"
-------------
前面我们说的是同源策略, CORS 只是同源策略的一部分, 并不能代表整个同源策略, 而同源策略本来就只是浏览器才有的概念, 同源策略中很多东西和 HTTP 半毛钱关系都没有, 比如 Canvas 的跨域, LocalStorage 的跨域, 也就 CORS 和 HTTP 有那么些关系, 所以我不懂为什么从同源策略又缩小范围到 CORS, 姑且就认为之前是想表达 CORS 而不是同源策略吧
特地又去确认了一遍 HTTP 的 RFC 文档和同源策略, 不然我以为自己以前看了假的文档. 事实上 HTTP 里从来没提过 CORS, 不知道为什么这个"补丁"不写在 HTTP 规范中?
事实上 CORS 只是在 Fetch 的规范中定义了, 包括那些相关的头部, 而不是什么"HTTP 安全的一部分", 而关于 CORS, 原文是这么说的
It is layered on top of HTTP and allows responses to declare they can be shared with other origins.
也就是 HTTP 上层的约定 /协议, 不可否认 CORS 解决了一些安全问题, 但是这只是针对浏览器的, 上层协议专门为浏览器打的补丁也要算作 HTTP 的补丁, 不合适吧? HTTP 作为更通用广泛的协议, 浏览器的特定需求不该由他来考虑吧?
参考
https://fetch.spec.whatwg.org/#http-cors-protocol
https://www.w3.org/Security/wiki/Same_Origin_Policy
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
https://tools.ietf.org/html/rfc7231
https://tools.ietf.org/html/rfc2616
如果有误还请指正.

现在扯得偏离楼主问题有点远了, 我来整理下, 没理解错的话
楼主的问题是 PUT, DELETE 等 HTTP Method 是否存在安全问题(范围应该 HTTP 协议)
你给的(有安全问题的)论据是 PUT 等 Method 在 CORS 下存在区别(范围缩小到 CORS, 浏览器范围)
以及"如果这个请求是 PUT、PATCH 等，这个请求可以在预检阶段就拦下来，避免跨域请求对服务器的产生未预期的影响。这本身是 HTTP 协议安全的一部分"
我只想指出这两个论据存在问题并不能推导出"PUT, DELETE 等 HTTP Method 是否存在安全问题", 至于 HTTP 本身安不安全, 明文的还指望多安全, 要加密上 HTTPS, 要防止资源被跨域读取上 CORS, CSP, 而问题本身, PUT, DELETE 并不会比 GET, POST 更不安全(协议上来说, 至于举例 XX 服务器因为 PUT 导致漏洞那是具体实现的事情)
所以我想我们不应该偏离主题太远, 不然给人感觉像外交部发言人答记者问

学其他东西大家都会看好几本书，然而 CSS 就像养生，每个开发都觉得自己一下子就能掌握。。
其实也需要些资料系统学下，虽然这东西和其他东西比起来简单很多，但是通常没几个人愿意系统学。。
完全不会的可以从 Head first 系列开始
会一点的就可以上 CSS 权威指南，虽然这本书很旧了，不过看完还是可以做到基本的布局不坑的，反正这本看完花不了一星期
之后 MDN CSS Guide，和 CSS Reference 刷一遍，也可以跳过权威指南直接看这两个，有兴趣顺着 MDN 里每个 CSS 属性的 W3C 规范点进去看一下，基础就已经好过大部分人了
有了基础，技巧性的看起来就完全没压力了，可以看 CSS 揭秘或各路博客中的技巧
抱着一周就能学很好的心态肯定是不现实，不过一周能写不太坑还是没问题的，CSS 总的来说比其他知识还是简单很多就是了

@Cbdy 所以到底同源策略是"HTTP 安全的一部分"还是"弥补协议的安全性"的？以及简单请求是否也会对服务器产生"未预期的影响"呢？
不然令人替广大移动端应用感到担心不是，毕竟他们没有同源策略的保护

自行车可能并不能帮你起到锻炼效果，反而可能令你的痔疮爆炸。。身边真实案例(并不是我