简单应用 Docker 可以胜任。复杂应用，配置管理类平台会可靠得多。

#6 楼 @masterqing 单独一个账户专门装，是服务器的安全考虑。Mac 上直接当前用户装，而且，macOS 你常用的账户就是管理员权限的，只是非 root 而已。

#11 楼 @huacnlee 哦，我再看了下你的配置，是我误解了。你并不是打算让 ngx_http_image_filter_module 根据请求参数，生成任意大小的缩略图。

这种方式在实际应用时，最大的风险是遇到不断请求各种大小，短时间内塞爆 cache 的恶意请求。不知道这个 module 对此有没有防御手段。

让需求方到大硅谷看看

#2 楼 @guxiang 你发一段 Ruby 代码计算出 Email 地址的，就能防 spam，并且在 ruby 圈看得懂了

#18 楼 @oth IKEv2 路由国内外分流的，已经搞好了，但是考虑到发布出去要对所有用户负责的，所以内部还打算再测试几周。

这次的方案比之前给 PPTP/L2TP 的更灵活，后续可以扩展支持很多场景。

目前还是有少量大网站用了 StartCom 证书的（不知道他们当时怎么想的），所以，现在标记为不信任，可能会有少量网站打不开的，比较纠结。

#6 楼 @easonlovewan 视频放在 YouTube 应该是目前最好的选择了，长期可用，转码质量好，各种设备都能看。 至于要翻的问题，其实做开发本来就有很多资源要翻的，算基础设施啦。 硬广 => 云梯

#1 楼 @huacnlee 是因为多人管理，Twitter 以安全理由封了？ 好像只要不是太严重的原因，都可以找 support 处理的。

果然是节日，今天 Github down 了，居然各大社交网络几乎无讨论。

如果抛去情绪部分，看楼主写了一家这样的公司：

老板只会发鸡汤 拿钱不做事的老员工为非作歹

但公司居然能盈利 36,000,000 元/年，感觉是躺着赚钱的业务啊。

昨天今天看到花椒吃完了很有趣，没想到今天盖楼已经盖到这么高啦？

#3 楼 @huacnlee PHP 给人 outdated 的感觉，所以觉得没有 concurrency 方面的支持是正常的。

Python 要支持 concurrency，到底是在 2 上面实现，还是 3 上面实现呢？如果 3 实现了，但是没人用 3 怎么办呢？

#14 楼 @Peter 嗯，现在非 retina 的都不能看了。

concurrency 的确是有需求但 Ruby 短板的方面。

#12 楼 @Peter 2012 款是 rMBP 第一代吧？

#12 楼 @bianjp

我觉得国内 CA 不值得信任的一个重要原因是在天朝没有任何机构敢于对抗 ZF（ZF 要你签个假证书，你敢不签？）。

一语道破！

从信任机构列表删掉 WoSign 和 StartCom 的影响倒是不大。

用 StartCom 的主要是个人小站，它们正在大批转移到 Let's Encrypt。 WoSign 倒是有国内比较 low 的小商业网站用，不过技术圈的人碰不上那些网站。

嗯，Wosign 2015 年就悄悄收购了 Startcom，后来自称签发假 Github 证书是技术问题，无论是有阴谋的（技术问题是敷衍），还是真正的技术问题，能签发假的大网站证书的，都是非常可怕的。太容易让安装了它的证书的设备被中间人攻击了。

很多 CA 的背景不透明，Wosign 作为中国的 CA，背后的 Big brother 是谁，没有人知道。

(which was built for Mac OS X 10.12)

看起来 RVM 认错了版本了？

之前我是非常不建议用 16.04 的，因为连 apt 源里面很多 16.04 的包都和 16.04 不兼容。 但是，现在 16.04.1 发布了，或许可以试试看，按照以往，.1 基本稳定可用了。

首先刷新页面，如果 OK 了，那看看能不能在某个操作下再次重现，然后去看那个页面引入了什么样的 JS 代码。 如果不理解 Turbolinks 的原理，很容易写出被 Turbolinks 多次加载或没有正确加载的 JS 代码。

#2 楼 @cqcn1991 Basecamp 慢主要还是网络原因，小公司用 CDN 只能解决静态资源加速，大公司用多数据中心独立部署，把用户数据直接放在最近国家的数据库，才真正解决了“大陆以外”的网络速度问题。

个人建议简单 App，如果会 OC/Swift/Java 的，还是开发原生 App 吧，体验真的好不少，而且代码和逻辑非常符合各平台自己的习惯。 如果 App 业务逻辑非常复杂，做 Hybrid App，用 Web 实现业务最复杂最经常变化的那些部分，嵌入到原生 App 中。

恕我直言，第一条的真正门槛不在英语 😂

除了并发优势外，NodeJS 在互联网应用场景并没有优势，劣势倒是很多：

• 生态成熟度低，很多通用场景都要自己造轮子
• 代码可靠性相对低，经常踩坑
• Javascript 从程序语言设计角度来说，是一个既不适合工业化，又不能让开发者写得开心的语言

曾经因为前后端能用同一种语言，几年前给某创业者推荐尝试 NodeJS，后来该创业者踩了 1 年的坑后，回到了 Ruby。

有些东西不是看起来好就是好的，当然 NodeJS 社区的营销能力的确胜过 Ruby 社区。

不太建议新手用 docker。 vagrant 或直接在 Linux 虚拟机里面开发更少遇到问题。

#15 楼 @martin91 空格是说话激动到哽咽时，需要停顿一下