• 另外,我看了一下你的 Gem,太多了

    时间精力有限,你这样拉太长战线难以把细节做好。可以考虑把精力放在重点的几个(5 个以内),专注先做好他们。

  • 成都有没有兴趣来,我们这儿还有个湖南的,上周刚买房要定居。

    我们在做 长桥,你要有兴趣可以邮件联系我。

  • S3、DynamoDB 这种架构复杂,不利于构建通用组件。这类需求实际上可以基于目前的方式在自己的项目中扩展。

    实际上更简单的方式是将这个数据存储到非业务系统的库里面,比如我们的场景,Audit Log 是存储在后台特有的数据库里面,和业务系统隔离的。

  • 楼主说的问题靠测试覆盖能很容易解决。

    不过鉴于这个,顺带说说 Rails 某些问题只会在 production 环境发生,哪怕你测试覆盖够了。

    某些特定复杂场景,在 test、development 环境是没法重现的,我们可以用 config.eager_load = true 模拟 production 的加载机制来启动,才能还原 production 的场景。

  • 可以的,A 等待网络响应的时候,B 可以使用 CPU 的,能起到一定的并行效果

  • 增加一个 /status

    server {
      location /status {
        access_log off;
        add_header Content-Type text/plain;
        return 200 'OK via Nginx';
      }
    }
    

    然后用 HTTP 访问 http://localhost/status 来验证

  • CDN 到 Google 的服务, icons.duckduckgo.com

  • 什么城市,什么网络?

    正确的应该是这样:

    > ping gems.ruby-china.com
    PING nm.aicdn.com (183.131.200.72): 56 data bytes
    64 bytes from 183.131.200.72: icmp_seq=0 ttl=54 time=36.204 ms
    64 bytes from 183.131.200.72: icmp_seq=1 ttl=54 time=41.636 ms
    64 bytes from 183.131.200.72: icmp_seq=2 ttl=54 time=43.136 ms
    64 bytes from 183.131.200.72: icmp_seq=3 ttl=54 time=36.743 ms
    64 bytes from 183.131.200.72: icmp_seq=4 ttl=54 time=41.633 ms
    64 bytes from 183.131.200.72: icmp_seq=5 ttl=54 time=36.132 ms
    64 bytes from 183.131.200.72: icmp_seq=6 ttl=54 time=36.460 ms
    ^C
    --- nm.aicdn.com ping statistics ---
    7 packets transmitted, 7 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 36.132/38.849/43.136/2.889 ms
    

    从你截图来看,是走的 IPv6 的,这个我倒是没试过

  • 已经修复了,现在可以修改了

  • 你 ping 一下 gems.ruby-china.com 截图给我看看呢。

    > ping gems.ruby-china.com
    

    或者如果有 dig 命令执行一下 dig

    > dig gems.ruby-china.com
    

--