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

不要改，管理后台，"全局设置" 里面有很多可以直接配置 HTML 或插入 CSS，JS 的方式

话题排序是按照 last_active_mark 来排列的，它存在的意义是让一定时间范围内有新回复的主题可以排到前面。

所以你导入数据的时候，需要把创建时间转为 Unix Timestamp 存入 topics.last_active_mark 字段

发 Response Header 截图呗，这样说不清楚

@bill997603 没说清楚

Rails 控制台的日志输出和 Gem 没关系，是内置的

@iamdbc #3 楼 跟这个没关系

React 做的话，需要有复杂的 JS 生成 HTML，哪怕是用的是 SSR，这样意味着功能结构复杂，不利益优化，前端渲染的方式是把 HTML render 的动作放到前端了，看似 response time 很少，实际上用户端也需要一定时间的运算才能达到结果，并且前端渲染的方式难以做缓存，有缓存也无法所有用户通用。

实际上以我经验来看，像 Ruby China 这类以内容为中心的网站，用 React 或 Vue 这类前端架构实现出来效果，相比纯后端渲染会差一些。

因为这类内容为主的网站很多地方可以依靠 Fragment Cache 来优化渲染速度，减少没有复杂的前端/后端 HTML 生成部分的计算，大约 90% 的访问都是缓存命中，命中缓存简单拼装直接返回。

目前 Homeland 对大多数的 HTML 渲染结果有 Fragment Cache，并且经过多年的优化页面缓存已经做得很极致了。当然用 React / Vue 也可以优化到这样，仅限于 SSR 的方式。

Homeland 的页面缓存已经做到和用户无关，你可以分析看看，以目前这个页面的回帖列表为例，登录和不登录，登录的不同用户是有不一样的界面表现的（编辑权限、删除权限等等，跟当前用户优化），Homeland 的实现让 HTML 生成的数据无法，利用一些技巧来实现分权限的效果。这样在缓存的角度，回帖列表所有访问者的 HTML 输出都是一致的，于是我就可以直接把这个回帖列表的 HTML 直接缓存下来，除非有新增/删除/修改回帖，那么这个列表的缓存是一只有效的。

你可以简单理解，从物理的角度，计算少（HTML 生成复杂度），速度必然更快。Homeland 的实现或者说 Rails Views 这套设计理念就是减少 HTML 生成的复杂度，从而提升渲染速度。

实际上我目前的所在的公司，我们团队在大量的使用 React 和 Vue，React 是结合 Rails 开发，实现复杂前端功能，我也很认可这个方案，它能让我们从容应对产品提出的复杂交互需求，但仅限于做 App 类的应用，而不是 Web 应用（Web 应用或许可以做，只是目前我还没有能优化到 Homeland 这么极致响应的经验）。

当你网站被 Google 认为是高质量的，Google 就会给你构建这个出来。

去给公司说明原因，申请安装，如果说清楚了还不给你安装，那你可以考虑离职了。

有时候哪些所谓的限制，仅仅是因为 IT 能力不够，所以搞的一刀切。

Ruby 标准库有 SecureRandom.alphanumeric

p SecureRandom.alphanumeric(16) => "5Ov39BS5Ve0n4CET"
p SecureRandom.alphanumeric(24) => "CabSW7ijP9Hg1CojBziVajP9"

Rails API 里面有个 Base58

https://api.rubyonrails.org/classes/SecureRandom.html#method-c-base58

p SecureRandom.base58 # => "4kUgL2pdQMSCQtjE"
p SecureRandom.base58(24) # => "77TMHrHJFvFDwodq8w7Ev2m7"

如果你不希望有大写字母，可以用 Base36

https://api.rubyonrails.org/classes/SecureRandom.html#method-c-base36

p SecureRandom.base36 # => "4kugl2pdqmscqtje"
p SecureRandom.base36(24) # => "77tmhrhjfvfdwodq8w7ev2m7"

以上有重复概率，在插入的时候处理唯一错误，重试

可以传 SVG 了

今天是 rubygems.org 故障了，现在已经恢复了

gems.ruby-china.com 是用 CDN 的方式来做的，所以，如果官方有故障（当然这个是少有的），Ruby China 的镜像也会坏掉。

这个考虑是要看你怎么看待用户。

Homeland 的设计包括 Ruby China 的管理方式，都是宽容的方式，我们首先是假设绝大多数人都是善意的。

用户的发帖是自己的东西，我认为每个人可以删除自己发布的清理，甚至全部清理是应该的（我也认为每个网站应该提供），谁都有犯错的时候，应该允许大家纠正错误（有纠正的机会），而不是那么严格的规矩。

就算某些时候某些人言论不当，也有可能过段时间他想通了，所以我们应该给机会让他纠正这个错误，而不是揪着他之前的错误不放。也有一些情况是我们需要修正错别字、补充讨论细节等等需要再次修改内容。

或者换句话说你在 Twitter 上发布的 Tweet 你觉得是自己的还是 Twitter 公司的？用户发布的内容，用户当然有权利可以删除。

所以那种发帖以后无法修改的，我是不赞同的，看似简单的限制删除和编辑，实则是假设大多数都有恶意。

好了

修复了

https://github.com/ruby-china/homeland/issues/1153

这点问题都搞不定，怎么维护好项目，大胆点，有点魄力啊

换 RuCaptcha

一直不想上这个 想查出来解决掉来着 结果拖这么久

还是内存泄漏问题

不是这个问题 是 Puma 进程内存过大

这个暂时没找到原因，有个东西有内存泄漏

后台首页点击“重启”临时解决一下

或者你可以使用 3.2.x 版本的 Docker Image

去掉 admin_emails 前面的 # 号，然后重启

用 Public Read Bucket

还是内存泄漏，前天又升级到了 CarrierWave 2.0，这回应该确定问题就是它了。

https://github.com/ruby-china/homeland/commit/ca2e56dfb36895c1cf4a10ada6ac37e7e8a5c587 https://github.com/ruby-china/homeland/commit/52d827d1f95fd404dac954e62456325889529193

看这个

https://ruby-china.org/topics/39130

你查一下垃圾信箱，我刚才尝试了一下，找回密码是好的，能收到邮件