• 导航栏不会显示 Team

  • ... 1 楼、3 楼在误导人

  • S3 Storage (1038.9ms) Checked if file exists at key: variants/Ef3kRjSHxoqNw86TTNDPz8DC/10d4e6731e902108be27818bfbb7b760bac6df85d9578ddb35096d2102c0bd89 (yes)
    

    缩略图的使用,如果直接用 self.avatar.representation(variation_key).processed.service_url 这种机制,会在每次使用的时候有网络 IO

  • 你可以看看 activestorage-aliyun 的实现,README 上有说明,用 service_url  的方式生成,可以直接是 CDN 地址

  • 服务器上的那几步可以预先打好 Docker Image,AWS 之类的云平台他们有私有的 Docker Registry 服务

  • 每次 macOS 一发布新版本,这类问题就来了

  • Ruby China 7 岁生日快乐 at 2018年10月28日

    🍢 🍗 🍧 🍬 🍬

  • 你的需求是需要记录每一次点击,才能统计出来

    如果没那个实力存储和维护这么多点击数据,你可以用 Google 分析之类的三方工具

  • 可能是验证的 Bug,我看看

  • 结合昨天凌晨和今天凌晨的问题分析了一下,怀疑是服务器内部的备份动作导致的,出现问题的时间点(4:00)和备份点切合,今天关掉,晚上看看是否还会出现。

    但从 UCloud 的流量统计图上来看还有入口流量,备份应该都是出口流量。

    已经联系 UCloud 先给我们恢复,我关掉那个备份动作,观察看看。

  • 楼主一天到晚朝三暮四的寻找替代 Ruby 的语言,怎么可能学得会

  • 不能把 vendor/bundle 加进去,gem 安装的时候和系统有关

  • 你的 Dockerfile 可以改进一下,先 ADD Gemfile Gemfile.lock 进去,然后 bundle install,然后再将源代码 ADD 进去。

    这样一来,Gemfile 没改变的时候能利用 Docker build cache 减少重复安装花费的时间

  • 你都要禁用 Assets Pipeline 了,为何还有 stylesheet_link_tag ?

  • 可以忽略它,各种各样的扫描器天天在扫描

  • 富文本编辑器 Trix at 2018年10月05日

    我们做文档管理平台的时候,早期正文都是存在主表里面的,后来发现那个表因为大量正文越来越大,而主表又时常因为业务调整,调整结构(加字段、调索引之类),由于表大,DDL 特别困难,后面也是将正文拆成了一个独立的 contents 表。

    这样主表只有我 meta 信息,尺寸小了很多。而 contents 表结构固定,设计好以后几乎不会再调整。

    另外,查询主表列表,关联查询之类不需要正文的场景也不再需要排除正文字段了。

  • 你在 volume 的地方加上

    • public/packs
    • tmp/cache

    两个路径,这样之前 Webpacker 的编译结果就有缓存可以重复利用了

  • 试试把 tmp/cache 目录设置 Docker Volume

  • 你可以读读 Ruby China 的实现,原理是用户名的 DOM 有标记,@ 的时候取出来去重即可

  • 关键点找出来:

    • Upgrade early and upgrade often The closer you are to a new version of Rails, the easier upgrades will be. This encourages your team to fix bugs in Rails instead of monkey-patching the application or reinventing features that exist upstream.
    • Keep upgrade infrastructure in place There will always be a new version to upgrade to, so once you’re on a modern version of Rails add a build to run against the master branch. This will catch bugs in Rails and your application early, make upgrades easier, and increase your upstream contributions.
    • Upstream your tooling instead of rolling your own The more you push upstream to gems or Rails, the less logic you need in your application. Save your application code for what truly makes your company special (i.e. Pull Requests), instead of tools to make your application run smoothly (i.e. concurrent testing libraries)
    • Avoid using private API’s in your frameworks Rails has a lot of code that’s not private but isn’t documented on purpose. That code is subject to change without notice, so writing code that relies on private code can easily break in an upgrade.
    • Address technical debt often It’s easy to think “this is working, why mess with it”, but if no one knows how that code works, it can quickly become a bottleneck for upgrades. Try to prevent coupling your application logic too closely to your framework. Ensure that the line where your application ends and your framework begins is clear. You can do this by addressing technical debt before it becomes difficult to remove.
    • Do incremental upgrades Each minor version of Rails provides the deprecation warnings for the next version. By upgrading from 3.2 to 4.0, 4.0 to 4.1, etc we were able to identify problems in the next version early and define clear milestones.
    • Keep up the momentum Rails upgrades can seem daunting. Create ways in which your team can have quick wins to keep momentum going. Share the responsibility across teams so that everyone is familiar with the new version of the framework and prevent burnout. Once you’re on the newest version add a build to your app that periodically runs your suite against edge Rails so you can catch bugs in your code or your framework early.
    • Expect things to break Upgrades are hard and in an application as large as GitHub things are bound to break. While we didn’t take the site down during the upgrade we had issues with CI, local development, slow queries, and other problems that didn’t show up in our CI builds or click testing.
  • 如果无法掌握,用 Docker 的方式安装

  • 你 Docker 理解错了,你不能 docker exec -it 263fc /bin/sh 进去修改文件,修改没有效果的。

    上面的修改过程都是没有任何作用的。

    homeland/homeland 这个 Docker Image 里面已经处理好权限的,/var/tmp/nginx 这个路径是 app 用户的权限,Nginx 的配置也设定好用 app 用户来执行的。

    我刚才用 homeland-docker 拉下来启动验证了一下,上传是没有问题的。

  • 看看 log/nginx-error.log

  • Docker 打包,用 Docker 来执行