怎样才算企业级的 gem 呢？其实不要迷信什么企业级框架。企业用了就成为了企业级。企业用了也不代表是好用的。你在你的企业项目里用。出了问题你有能力解决就行了

代码风格这种东西不应该放到具体的一个 PR 里去讨论。要是我的话，对代码风格有追求非常好，麻烦走流程，跟相关的 decision maker 去沟通好了。只要公司层面统一了，我改就是。把这些东西推给领导层就好了。如果这个人是真的对代码风格有追求的话，他就会层层的申请，然后说服团队的领导者采纳他的想法，如果他是搞事的，自然就知难而退了。

用 ROR 作为主要后端开发创业的第 11 个年头了。公司主要做外包项目。因为也接收别人做的项目，现在主流的框架基本都有在做。说实话个人觉得还是 ROR 更适合初创公司。

很多项目即使做到后期，融资扩张其实也没啥问题，设计得合理千万级别的用户级别也都轻松能扛住。博主说得很对的就是，一个项目或者产品你要想一下怎么为用户创造价值才可能成功。遇到很多没有商业头脑的程序员天天炫耀用的技术框架多么牛 B，但是让他做点复杂点的功能，要么就花好几倍的时间（成本高），要么就是这个不好做（技术壁垒高）。扯来扯去没办法为用户创造价值多好的框架都是扯蛋。

当然创业也好做项目也好，你肯定是用自己最熟悉的技术。用最适合自己的技术才是最重要的。

作为主要开发人员，换个语言，别人内部讨论好了，直接执行，又不影响使用有啥问题？为什么要失望？苹果公司推出新产品改了好多设计也没跟你商量，苹果的管理是不是也让你失望了。

按照楼主这个薪资水平，年薪也接近 20w 人民币了。也算不上割韭菜了吧。别的招聘也很多是这个价位的。在另一个帖子里，感觉楼主说的话还是蛮有道理的。不妨听听别人的意见，从不同的角度看下问题。

做了 10 多年的外包。一开始自己做后来带团队做。谈谈个人感受。楼主这种情况遇过非常多。主要还是要做好沟通工作。一个项目前景不明朗不想投入过多的资金，这个可以理解。客户觉得很简单，不要觉得他是冒犯了你的技术，他就是想要一个很简单的实现而已。你可以根据他的理解来试着实现一下，如果是一些前期的产品，或者是一些几个人用的小系统，有瑕疵有问题可能他们都是可以接受的。你可以怎么简单怎么来。很多程序员总是会考虑的尽善尽美，所以忽略了成本。 举个一个例子，我给我家搭个围墙，我就想有个外墙可以把前院围起来这样隐私好点。砌砖的话需要 8 万，而做那种泡沫墙只需要 1 万。砖墙有很多的好处我都明白，但我只需要一点隐私而已，外墙不是拿来抵御外敌所以不需要那么坚固，所以我最后选择了泡沫墙，工人打了几个水泥桩然后搭上泡沫块，2 天就弄好了，我也很满意。并不是我觉得砌砖人的工作不够辛苦技术不够扎实，只是泡沫墙满足了我的需求同时我能负担得起。

我觉得没那么复杂，就是因为 Ruby 早期对 window 支持不好的缘故。我记得我因为学校当时要做 ruby 项目，专门把我的本本格了装上 linux。很多同学最后就放弃了。

感觉国内的程序员都对外包公司有偏见。我觉得还是环境照成的。之前关注几个国内做国外外包的公司还是蛮厉害的。我觉得不是外包公司不行，而是环境不行

感觉写代码的时候喝酒不太好吧。如果医生上手术台前也小酌一下，病人有啥感想呢！

感觉股份真的还是得一早就谈好，程序员老实人比较多一上来不好意思谈股份就容易吃亏。我遇过好多类似情况的人了。公司没做起来也就算了，做起来后没得到相应的回报会让你更难受

用这个能提升运行速度吗？

如果真的是 bloat tuple 的话，不需要 pg_repack 吧。你 VACUUM ANALYZE 应该就能解决了。 还有就是信息量很少，不好分析。数据库怎么配置的，什么版本，数据库有多大啥的都没说

我们也遇到类似的情况，测试要跑很久，所以 CI 里开多几部机器来跑。我们用的是 Bitbucket Pipeline。一开始我们开了 8 个并行，但是我后来发现每个环境其实都是一个 4 CPU 的环境，然后我们就结合了 parallel_tests，结果果然跑得更快了。现在只需要 4 个就能达到以前 8 个并行的效果。

Ember 感觉不太跟得上了，相比 React，他的插件少的多了，好多都需要自己重头实现

我说的是 Rails，不是 Ruby。这是不一样的，但看语言的话可能是相差无几。

你的例子我明白，我们大部分 API 都能做到 100ms 以下的，而且这个 API 不是 RPM 最高的，我们也有 RPM 非常高的 API，但业务没这个复杂。单就内容来说，有 400kb 的 JSON，按照标准的 JS 格式的话有 11,000 多行，返回的数据量也大。说实话用别的框架或者 Java 来做，同样的业务会不会更快这点不好说，因为没有试过。

这个 API 的瓶颈也不在数据库，所以只要多加服务器都是没问题的，不会因为流量过大挂掉的问题，但不改 API 的结构这个返回时间在现有框架上是没办法下降了，除非利用多核并行的去计算生成 JSON

我就是外包程序员。我们公司 13 年成立至今，帮客户做了不少成功的项目。有的已经实现了小目标。其实外包项目也能做得很好的，最重要的是能帮客户赚到钱，很多客户我们帮他们从 0 开始打造他们的产品到他们做得很大，还一直在合作。

生产力是杠杠，但我觉得 Rails 的性能还是要差些，当项目做大了以后，比如我们的一个 API，用 Rails 5.2 + Jbuilder。500 左右的 RPM，在缓存全中的情况下服务器响应时间还是要 400ms 左右，JSON 内容有 400kb 左右。我们对缓存做了很多的扩展还搞了这个 jbuilder_reopen (https://rubygems.org/gems/jbuilder_reopen) gem。定时把所有的内容都读到缓存里，但 400ms 的响应时间还是不太理想。

Airbrake 还是很有必要的把，几千个异常过来，不好管理吧

我们也是这么用的，exception_notification 自带了 slack 的 notifier 的啊https://github.com/smartinez87/exception_notification/blob/master/docs/notifiers/slack.md 不过我们自己扩展了一下，多加了些参数。

没注意是 15 年的老帖子了😂

我觉得 stimulusjs 把 JS 代码组织好了，再来个量身打造的测试框架就完美了

感谢分享。但是我看 YouTube 上面的视频明明显示是有 10 个小时的，但是打开却只有最后的两个小时的视频。是不是 YouTube 最多只能 2 个小时的啊

以前也觉得这个问题无非是钱的问题，但根据这几年的经历，我觉得不光是钱的问题。

举个我们自己遇到的例子，我们的一个 API request，业务很复杂，如果不中缓存的话大概要 4 秒才能返回，光是服务端，还没算上网络传输啥的 overhead。中了缓存的话 200ms 就行了。加机器是能确保流量大了，服务不会挂掉，但是用户第一次 request 需要等上 6，7 秒才能看到数据对用户太不友好了。我们也花了不少时间去优化，从 NewRelic 上看瓶颈不在数据库，而是在 Rails 这边。当然我们可以把这个 API 拆分成几个小的 API 一步步的 load，但这样的话需要前端去配合 iOS，Android 还有 WebApp，这样的话 Rails 的开发效率优势又没那么明显了。

总的来说 Rails 的开发效率确实很高，但性能确实还是需要多去优化。

其实自己培训没有你想象的难，特别是能力强的新人。你要是找一个几年 Java 或者 PHP 经验的去转 Ruby，一开始他可能会天天跟你抱怨，但是刚毕业的孩子反倒是更容易接受新的语言。我们公司一开始就我一个程序员，再加一个设计师，现在已经有 10 个 Ruby 开发了，加上这几年跳出去的人也超过 20 人了，都是自己培训的。期间也招过一个有经验的 Ruby 开发，但那人跑过来干了没满 1 个月就又跳了

我在一个很小的城市，面临跟楼主一样的问题。为什么不考虑招些能力强的应届毕业生来培训一下。能力强的人 2，3 个月就能上手了。

用 top 很难看得出啥。装个 New Relic 啥的看看瓶颈在哪嘛

我对 JS 不太熟悉，不过 Date 应该是 JS 原生的。当然针对不同浏览器应该是有点区别。不如你具体说一个你觉得会产生的问题出来大家探讨一下？

早都用 Google Doc 来写文档了。公式图表一点问题都没有的

最害怕就是跟楼主这种做事风格的人交流。一般遇到技术问题，直接把问题描述出来，再不行直接上代码。而楼主几乎每次留言（包括正文），总是东拉西扯，泛泛而谈，感觉就是跟你耍太极。我大胆猜测一下楼主估计是有个绝好的 idea，不敢透露细节，但苦于能力还没办法实现，先来摸摸大家的底细。

如果猜的不对请见谅，主要是我遇过太多这样的人了。

是 local scope 的问题。想明白了。非常感谢

这几天项目突破 1 千万用户了。PG 处理起来非常得轻松，5k 的 RPM。平均数据库相应时间 10ms 左右。