• Rails 最佳实践 - 定时任务 at 2017年1月19日

    #10楼 @kgen 大家对于移植和运维的理解不同吧

  • Rails 最佳实践 - 定时任务 at 2017年1月18日

    #7楼 @kgen crontab当然很可靠,但是不用的理由请看原文:

    1. crontab 方案每一条任务都是独立的,都需要完整加载整个Rails运行环境,而Rails运行环境相对是比较耗资源的。想象一下每次几十个、上百个定时任务不停的启动停止,系统的负载可想而知。
    2. crontab 本身是系统的组件,这种方案需要依赖于系统的组件,在很多 production 环境下可能没有 crontab 组件,比如运行在 heroku 上,比如运行在 docker 上。

    另外,通过把定时任务转换成 scheduler 来使用,尽量避免把cron任务变成一个『高强度』的东东。

    当然,最终用什么还是要根据自己的需求和实际情况来就行了,每个方案都有自己的优劣吧

  • Rails 最佳实践 - 定时任务 at 2017年1月18日

    #3楼 @Rei crontab当然是最健壮的~ 主要还是挑选适合自己的方案吧,这种最佳实践也都有局限性,『没有银弹』

  • Sidekiq 定时任务的尝试 at 2017年1月18日

    #13楼 @gihnius 这个看起来很不错

  • Sidekiq 定时任务的尝试 at 2017年1月17日

    #11楼 @lithium4010 还是看具体的使用场景

  • Sidekiq 定时任务的尝试 at 2017年1月17日

    #6楼 @lithium4010 哦,我们并没有使用 perform_in ,我们使用 crono + Job

  • Sidekiq 定时任务的尝试 at 2017年1月17日

    #4楼 @lithium4010 我们现在系统就是这么做的,回头写篇文章解释一下。主要好处就是可以利用Job本身的重试机制、错误处理机制,而Cron本身很简洁,只是一个触发器。

  • Sidekiq 定时任务的尝试 at 2017年1月17日

    不推荐这么做,还是用应该更合适的工具做适合的事情。推荐的做法是用定时任务(crontab、rufus-scheduler、crono)来做一个调度器,具体的事情还是有 Job 系统来完成

  • Rails 最佳实践之配置管理 at 2017年1月17日

    #2楼 @huacnlee 敏感信息还是很有必要使用 ENV 来管理的。应用配置的话方法管理方式很多

  • Rails 最佳实践之配置管理 at 2017年1月17日

    #7楼 @hiveer 主要是敏感信息使用 Env 有一些好处,至于 Settings还是自己写一个initializer确实区别不大

  • 一直在想有什么 topic 是对社区的小伙伴们有帮助的,大鱼的系统主要是基于 ruby on rails 的,我们用到了很多有意思的技术,有的相对也比较深入了,但是都比较散,讲起来大家可能也不是很感兴趣,所以准备讲一下如何维护一个时间超长的 rails 项目,里面也会穿插讲一些创业过程中的问题。

    报名主题演讲:如何维护一个4年的 rails 项目?

    内容包括:

    • 一个 rails 项目4年的不断变得复杂的发展过程;
    • 发展过程中遇到了哪些问题;
    • 这些问题是如何被解决的?

    大概内容主要包括自动化测试、service、项目分拆、代码审查 等等~

  • 免费赞助场地,三元桥大鱼咖啡~ 欢迎各位来坐坐

  • Rails 如何写测试 at 2016年4月04日

    @nainc stubs和mock那段写的不错,但是感觉还没有抓到本质的点~回头我也看看

  • 关于乐观锁的重试 at 2016年3月27日

    赞! 感觉 retry 的时候调用的 record 可能还是老的对象,得再测试一下~

  • #5楼 @ruby_sky 当然,如果当做 module 的话,按正常的ruby way使用用就行了;rails 的 concern 一般 用于 model 间的业务共享;而且用 module 并不能解决 view-model 的问题,完全两码事~

  • #1楼 @qinfanpeng 多谢~

  • #2楼 @ruby_sky concern 主要用来在 model 之间共享逻辑,跟这个要解决的是两个问题。另外,concern 本身也是不推荐大量使用的,concern 采用了 mixin 的方式,一旦代码量增大,也容易导致不少问题。

  • Ruby 异常处理最佳实践 at 2016年2月28日

    #2楼 @coderek 其实 ruby 的也算轻量了,不然可以看看 java 世界,还要区分 checked exception 和 unchecked exception,直接晕掉。 异常最重要的是合理使用,不能过度,也肯定避免不了不用

  • Ruby 异常处理最佳实践 at 2016年2月28日

    #1楼 @taojay315 rails 里面是这样的,一般用 rescue_from 来统一捕获部分异常然后进行处理,不过这个不是这篇文字讲的重点。 异常当然不应该抛给最终用户,抛异常的时候关心抛出合适的异常即可,至于是谁来捕获,就需要来看具体的业务逻辑了,一般是上层捕获下层的异常,直接处理掉或者进行转译再抛出。

  • 没有测试过,简单示例一下,后端起 unicorn 在不同的ip 或者端口均可;

    upstream first_app{
       server 10.0.0.1:8888;
    }
    upstream second_app {
      server 10.0.0.2:8888;
    }
    
    server {
      listen 80;
      server_name test.example.com;
    
      location /first_app {
       # 根据需求,可能需要 rewrite,比如
       rewrite ^/first_app/(.*)$ $1 break;
       proxy_pass http://first_app;
     }
     location /second_app {
      # 根据需求,可能需要 rewrite,比如
      rewrite ^/second_app/(.*)$ $1 break;
      proxy_pass http://second_app;
     }
    }
    
    1. 你遇到的 assets 的问题的解决方案一般是把 assets 挂载到独立的域名下,直接由 web server 来提供资源,比如放到 static.example.com 下面,走不同的子域名;
    2. rails url helper 产生的路由跟 nginx 会不一致,这个需要修改 routes.rb ,用你上面的方法就行
  • 非常棒的文章!

  • #12楼 @luikore 说的确实是一些基础的东西~~ 我的意思是用任何数据库跟使用锁是不冲突。如果你熟悉 postgres,可以大概讲讲它是如何解决这类问题的,让大家了解一下~

  • 科班出身,本科硕士都是计算机,创业后正式开始写 ror

  • #9楼 @pathbox 还是看具体的业务场景吧。乐观锁在竞争较少的情况用比较合适,而且需要自己处理冲突的情况。悲观锁会堵塞其他进程,不利于并发,但是程序写起来容易