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

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

  • 创业一年随想 at 2021年11月06日

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

  • 用这个能提升运行速度吗?

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

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

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

  • 111 at 2020年11月15日

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

  • 111 at 2020年11月13日

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

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

  • 111 at 2020年11月13日

    我就是外包程序员。我们公司 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 个月就能上手了。

  • Rails 并发问题 at 2018年07月12日

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

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

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

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

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

  • 请教一个 ruby 的问题 at 2018年02月10日

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

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

  • 量产型炮灰工程师 at 2017年05月24日

    所以大厂,谷歌,微软,Facebook 这些都喜欢考算法考基础原理那些。现在貌似有点明白为啥他们要这么面试了。

  • 北京面试所感 at 2017年04月16日

    才被拒绝了 3 家,不需要气馁。很多科班生毕业找工作都不知道被拒了多少次了。我研究生刚毕业的时候找工作也被拒了 3 次。说真的刚毕业的时候,刚从学校出来,私底下做了几个项目,也不知道用人单位到底需要什么,看重什么硬着头皮就去了。每次被问到不清楚不明白的地方才发现自己有很多东西不清楚,晚上就看书恶补。如果别人都说你理论知识不足,不妨先看看书。

  • Ruby worker 啊。Rails 4.1 Ruby 2.2.4

  • 今天忽然看到这个帖子。看了一下我们也是用 sidekiq,一天 800w 任务左右。一部 15G 2vCPU 的虚拟服务器就搞定了。开 12 个线程。

  • 跳槽? at 2017年03月10日

    我觉得得看做什么项目了。如果新公司的项目更有意思更有挑战可以考虑换。但是有时候能够闲下来也是很好的,这样才能有更多的时间去思考,更深入的去理解自己做的东西,开始各种折腾,寻找更好的方法去实现。

  • 发现一个 bug,加入购物车以后,点继续购物,右上角购物车里的数量没变

  • 谢谢分享。

    ps: 我们把登录用户的 log 也保存到数据库里的😄