• 再见啦,Ruby on Rails at September 16, 2023

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

  • 招聘远程 React Ruby Rails at August 07, 2023

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

  • 远程外包的坑 at August 04, 2023

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

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

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

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

  • 创业一年随想 at November 06, 2021

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

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

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

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

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

  • 111 at November 15, 2020

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

  • 111 at November 13, 2020

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

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

  • 111 at November 13, 2020

    我就是外包程序员。我们公司 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 July 12, 2018

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

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

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

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

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

  • 请教一个 ruby 的问题 at February 10, 2018

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

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

  • 量产型炮灰工程师 at May 24, 2017

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

  • 北京面试所感 at April 16, 2017

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

  • Ruby worker 啊。Rails 4.1 Ruby 2.2.4