• 应用了元编程,开心哦 at 2017年09月11日

    好了,你可以去学 Elixir 了

  • 难道不是去旁边万达包场看刀剑神域……

  • 作为一个 Elixir 程序员,也是这样的感受😂

  • 开源爬虫 1.0 了! at 2017年09月01日

    😂 我就是看到了 “high performance”

  • 开源爬虫 1.0 了! at 2017年09月01日

    有性能测试没?

  • 查一下 nginx server_name 的文档就能解决了。。

  • 来玩 Elixir 吧。debugger 也有官方支持了,虽然我没用过😁

  • 生态赶上倒不至于,但很多轮子已经够用了,实在不行自己造一个也不难。关键是语言和框架的优势在那里摆着,可以试试

  • 当然是 Elixir 的 Phoenix 啊,Rails 完全没有可比性

  • Elixir 的 doctest 不只是文档,还是测试

  • 你如果坚持 Ruby 的 method_missing 是合理的话,那就无话可说了

  • 是啊,不过作为一个“前" Ruby 程序员,还是心系 Ruby 的嘛😂 而且不管对哪个后端语言,都是一个理

  • 我只是想说,如果想做一个好的 Ruby 程序员,应该少研究前端,一点没否认前端本身的价值和重要性。如果要转前端就专注在前端,不要再说自己是 Ruby 程序员。

  • 我也没有说 Ruby 的不好啊,只是在陈述 Elixir 的好而已。也不打算拿 Ecto 跟 AR 比语法,毕竟这方面的优势也不是很明显,其他方面优势也已经够多了😜

    但不可否认的是,为了支持运行时元编程,确实拖累了 Ruby,参考 http://rubykaigi.org/2016/presentations/shyouhei.html 。 更不用说 method_missing 这种根本不应该存在的东西了。

    撇开性能问题,Ruby 元编程带来的难维护性也是不可忽视的。

  • Ruby 模仿:|> at 2017年08月04日

    在 Ruby 里用这个意义不大啊。。

  • 元编程还是 Elixir 好,完全在编译时完成,几乎不会带来性能损耗,甚至可以把一些计算挪到编译时完成。跟楼上说的 Lisp macro 一脉相承,但语法更加友好。

    Ecto 的语法感觉比 AR 的要好用和灵活,基本就是 SQL(毕竟 SQL 是最好的语言)。

    query = from p in Post,
    join: c in Comment,
    where: p.category_id == 1 and p.inserted_at <= ^datetime,
    group_by: p.id,
    select: [p, count(c.id)]
    
  • Elixir 入门书:Joy of Elixir at 2017年07月31日

    作者还是之前 ruby 社区的大牛 ryanbigg

  • 我说的是他这个场景下的问题。那也比 Redis 不加连接池,一上来就等着好吧,而且连接池比线程数多就可以规避这个问题了。

  • 加连接池不是为了解决 Redis 慢的问题,而是为了解决竞争的问题吧。Newrelic 比较新的版本,Redis 应该不会把太多 Ruby 的时间算进去

  • 嗯,我也跟 Kevin 有过几面之缘,很靠谱,也知道一些 launchschool 不错的学生,觉得 launchschool 已经是同类中很不错的了。真的是那句话,“修行靠个人”,你个人一定要找准目标和方向。

    不知道的话就去了解就好了啊,比如考虑一个实际的后端问题和前端问题,解决完之后看你更喜欢哪个。我印象中 launchschool 的课程应该是一些实际项目吧,这样就很好啊,只是你需要的是更多深度,而不是很多重复的劳动。也可以和 Kevin 聊聊看,我相信他应该会给你很多不错的建议的。

    我们招人有自己的要求,你如果感兴趣的话,可以邮件聊一下。

  • 我觉得你有两个问题,一个是目标大小,一个是目标太大。

    目标太小是,“就是为了学rails的”。不管 @knwang 办 launchschool 的目的是不是这个,但我觉得你个人不能把这个当做目标,而应该是”学编程“、“学后端或前端开发“、”成为软件工程师“ 这类大一点的目标,而 Rails 只是通向这个目标一种途径,或者说能帮你找到工作的途径。人人都可能很快学会 Rails,但真正能够做实际项目、解决实际问题、抗住流量、做优化等等才是你应该想办法去掌握的。

    目标太大是,你涉猎太广了。”全栈“工程师并不是那么容易做的,真正好的全栈工程师我很少见到。而且你也觉察到学很多东西比较吃力,特别是你还没有编程基础。我觉得你应该通过 launchschool 的课程快速找到自己想要专注的事情,然后钻研地越来越深入。如果你喜欢做用户交互方面的、喜欢调整各种页面,那你可能适合做前端;你如果更喜欢和数据打交道、喜欢研究底层网络、操作系统等等,那你可能更适合做后端。如果你都不喜欢,或者不能坚持下来,那你可能不适合做这一行。

    另外,关于 Rails/Ruby 的问题,我个人观点是,学习一下还行,但你如果想用来做比较大项目的话,那千万别用。但是考虑到你的情况,如果你想做后端,最好还是坚持以 Ruby/Rails 为途径,更深入学习后端开发,然后找个不错的公司做做实际项目。等你已经比较熟悉了,再看看其他语言。等你能认识到 Ruby/Rails 的不足,知道怎么去解决,但知道有些很难解决的时候,你应该已经是个不错的后端工程师了。如果你想学前端,那就丢掉 Ruby/Rails 吧,这不是前端范畴的,你应该去看看 JS/React 等等,但前端也有很多工程上的问题,性能的问题要去解决。

    至于公司的话,如果你愿意来上海,可以考虑我们公司,虽然比不过很多大公司,但起码有真实用户的线上流量和很多实际问题,而且 Ruby 还是在整个服务中发挥了很重要的作用,应该可以帮助你成为一个不错的后端工程师,而不仅仅是 Rails 工程师。 https://www.liulishuo.com/job-detail.html?id=4&entity=3

  • Rails 还需要“唱”衰吗?

  • Redis 没加 connection pool 的话,肯定有问题啊,其他啥都不用看,先把这个改了看看再说。而且楼主说了 "非数据库非redis的底层占用时间巨大",应该就是 "Ruby" 的时间,这个很大概率就是锁了

  • 我估计你卡在 Redis 的锁了,Redis 默认没有加连接池,为了线程安全,几乎所有的地方都会用锁 https://github.com/redis/redis-rb/blob/master/lib/redis.rb#L93 特别是像你这种并发这么高的情况下,线程极度繁忙,锁个几百毫秒应该很正常

    用这个吧 https://github.com/mperham/connection_pool pool size 设成线程数量就好

  • 用的什么 web server? puma 还是 unicorn? 这个不说清楚,光看框架一点用都没。另外看看 CPU 跑满了没,没跑满的话,应该还有优化空间