一开始，的确是觉得 ts 挺好的，甚至是惊叹，但的确随着开发的进行，有时候看一些库源代码的时候，看到里面那些天花乱坠的类型声明，完全没有可行性，加上自己写代码时候，经常也会被一些类型绑住手脚，的确自己也越来越在反省，自己用 ts 对还是不对，说实话，是想打退堂鼓了。至于 turbo 的这个事情，感觉和我们并没有直接的多大关系，从之前 coffeescript 的走势看，我自己的开发里面前端已经脱离了 rails。

vscode 在 ruby 上的确会比较头疼，插件都不知道怎么选，有几个感觉都不成熟，哪怕是 shopee 他们做的那些，说明都搞不清楚。

sublimetext 对 ruby 的支持要好一些，反正我觉得习惯很多，不过现在已经慢慢淡出 sublime 了

很遗憾，但的确如此，哎，所以一般来说，对于外接项目来说，接的主要是客户，不是项目，零散项目，不做也罢

应该怪我描述不到位，activestorege 提供的 DirectUpload 目的是帮你解决从前端 js 直接上传到后端 ruby 文件服务的问题，而是否用户选中文件以后就直接开始上传，这是咱们自己可以控制的事情，就拿 element ui 来说，它的 upload 组件就有一个auto-upload属性可以用来控制是否自动上传，不自动上传的话，自己 submit 就可以，submit 的时候调用 DirectUpload 的代码就可以了，而一般做好以后，切换自动上传和手动上传就是设置上传组件的事情，和 DirectUpload 无关，DirectUpload 只接管上传组件和 Ruby 文件服务之间的事情。

在我的项目里面，我写了一个 vue 的 mixin，代码如下，在需要的地方，使用这个 mixin，然后设置 el-upload 的http-request为 uploadByDirectUpload，设置 element-ui 上传组件的action为 rails 端的rails_direct_uploads_url，然后处理 upload 组件的事件就可以取得上传后的文件信息了，rails 的话，可以通过传回 signed_id 之类的信息，来做后续的文件绑定的操作。代码仅供参考，文件上传之类的事情就是这样，看着很烦，但一次做好以后，所有的地方都可以用了，用 form 有 form 的好处，但我其实后来感觉对于混合前后端来说，form 还可以，对于越来越多的前端完全分离来说，我更喜欢剥离文件和 rails form 之间的关系了。

import { DirectUpload } from "@rails/activestorage";

export default {
  data() {
    return {};
  },

  methods: {
    // 设置`el-upload`组件的`:http-request`为`uploadByDirectUpload`来实现选中文件就上传到服务器，上传成功的文件在`file-list`中会
    // 有`status`为`success`的状态，和之前已有的文件不同的是，新上传的文件会有一个`response`节点，里面包含有从服务器传回的信息，对于
    // rails而言，传回的信息为`blob`对象，里面包括`id`, `signed_id`等，其中`signed_id`可以作为key来赋值给对应的字段完成上传内容的赋值
    // TODO: 增加对`abort`的支持
    uploadByDirectUpload(option) {
      const directUploadDelegator = {
        // callbacks from active storage
        directUploadWillStoreFileWithXHR(xhr) {
          xhr.upload.addEventListener("progress", (event) => {
            const e = { percent: 0, ...event };
            if (event.total > 0) {
              e.percent = (event.loaded / event.total) * 100;
            }
            // console.log("Uploading process at: ", e.percent);
            option.onProgress(e);
          });
        },
      };
      const upload = new DirectUpload(
        option.file,
        option.action,
        directUploadDelegator
      );

      upload.create((error, blob) => {
        if (error) {
          // TODO
          console.error("Error occurred when upload file to backend: ", error);
          option.onError(error);
        } else {
          // console.log("File has been uploaded to backend: ", blob);
          option.onSuccess(blob);
        }
      });
      return upload;
    },

    // 检查el-upload的file-list对应的model字段，返回需要新attach上的内容, `isMultiple`表示该字段是否支持多文件
    //  - 对于支持多文件上传，返回非空数组包含有新上传blog的signed_id，返回空表示没有新上传的文件需要附加
    //  - 对于仅支持单文件上传的情况，返回当前新上传的blog信息，返回false表示文件保持不变，返回null表示清空单文件字段
    newAttachesFromFileList(fileList, isMultiple = false) {
      if (fileList == null || fileList.length <= 0) {
        return null;
      }
      if (isMultiple) {
        const newUploads = [];
        fileList.forEach((element) => {
          if (element.response && element.response.signed_id) {
            newUploads.push(element.response.signed_id);
          }
        });
        return newUploads;
      }
      if (
        fileList[0]
        && fileList[0].response
        && fileList[0].response.signed_id
      ) {
        return fileList[0].response.signed_id;
      }
      return false;
    },
  },
};

一直用的 direct uploads，没觉得有什么不妥，特别是你里面提到用户等待时间较长这点，用 form 上传，同样也是需要时间啊，direct uploads 也是可以控制的，可以在一个命令之后才开始上传，实现也很简单，不用话什么力气就可以和 element ui 等等的上传控件进行整合了

收藏了以后还是忍不住要回来说一句，受用无穷

那为啥中国版的 365 订阅没有 teams 啊....现在用的欧洲版的，小伙伴们经常抱怨消息发不出去啊....

sublime text 写 ruby 项目，vscode 写 python, flutter，或者纯前端项目，idea 写纯 java 项目，android studio 写安卓的 kotlin，goland 写 go, ios 用 xcode，不过最近 ios 做的少

present?本来就不是面向检查数据库记录是否存在而准备的，这是Object上的一个方法，按照说明：

An object is present if it's not blank.

换句话说，根本就不应该考虑使用这个来判断数据库记录是否存在，用的话，说明自己基础就不够扎实

180cm，100kg，14 年 4 月开始跑步，每天从 7km 到后面固定至少 45 分钟和至少 8km，每个月 220km 左右，10 月份的时候体重 73kg 了，现在还是这样，每天 2-3 小时的锻炼，其中 45 分钟/8km 的跑步，其它时间力量，每个月跑量维持在 180-200km，目前体重一直维持在 75-80 之间。跑步不仅仅是为了体重，更重要的是跑过后的那种快感......

lz 说的生酮饮食听着挺高深，不太懂，不过如果说低糖，和少淀粉摄入，这个我是举双手赞成，因为我是糖尿病患者，我一开始这么跑，也是因为糖尿病，本来每天要注射 40 个单位的胰岛素，还要吃药，早上空腹血糖还控制不住，现在通过跑步，我已经把药和针都停掉了，糖平时肯定是不吃的，淀粉摄入也自己有注意控制

内容不错，但的确是标题党了，k8s 和容器化的最佳实践搭不上边，跟着实际情况去选择最佳实践，不是按着最佳实践来压你的实际情况，这实际情况不仅包含场景需求，也包括团队能力，长期运营需求，等等，这个所谓的受害者不是最佳实践伤害的，是自己选型犯错而已，而且，这犯错其实也是一个宝贵的经验，看怎么去看待问题了

@Chorder Python 下也有不少非常优秀的 ORM，比如说 SQLAlchemy, peewee，等等

观点挺好的，也不是完全没道理，证明太差了，简直就是招黑

比较关心的是 break changes，居然没发现， #9 楼的看到怕了...

看看公司人数和规模，估计就是一个外包公司，为项目招人而已，最终面试可能都会是客户来面试，他们就是中间过一手，这种水平正常了

具体是怎么操作呢？选择 Restore 1.x，然后选择 Ohmystar1 的 app 么？

OhMyStar 1 老用户免费获得升级 Pro 1 年用户

这个是怎么搞的？

RocketChat

嗯，直接问客服，不过我就入坑了，本来在东京 1，他们开了东京 2，我测试了一下，ping 很好，就升级过去了，然后发现，ping 很好，但是实际速度不理想，接着坑就来了，无法挪回东京 1 了，一怒之下索性关了

过年 40，天天在写 ing

#6 楼 @yingce ecshop, iwebshop 据说也不错

#2 楼 @Trump 呵呵

jQuery 只是一个 lib，并不是框架，拿来和框架对比，本身就不对了

@hging 这倒是一个好办法，我前面说的 precompile，虽然在开发机上等，但终究服务器运算还是快，不过你刚才说的这个 gem 和楼上 @Trump 说的有异曲同工之妙，我太拘泥于 cap 的方式了，开发上的确 cap 还是上手快，不过我是可以继续尝试一下在 docker 上看如何借鉴二位说的方法了，多谢

#11 楼 @hging 但是这样的话，每次编译就会在开发本机上做，这当然不是说不可以，不过 compile 这个过程也是非常耗时耗力的，有时候还是希望扔给服务器。 其实除了这个点，还有另外的一些点，比如说，migrate，还有 bundle install，前者的问题是，跑的前提是 image 已经做好了，需要用一个新的容器来跑一下，后者的问题是，和 assets 类似，做不好，每次都是要重新安装，相对 cap 本身来说，速度会慢了很多

docker 在 rails 项目的应用上，我一直很纠结的是，怎么能用上 capistrano，尝试了几种方式，感觉都有点不舒服。

之前尝试的是放弃 capistrano，每次打包一个 image，再部署，这个缺点是，asset 和 bundle install 弄不好总是要全部重新写层，所以每次部署的时间都会很长。现在用的方式是，用 docker 开一个容器，然后对后开好 ssh，通过 capistrano 部署到这个容器中，部署路径用的是一个 data volume，这样换容器没有影响。

这样做，至少在开发阶段，部署的速度能和直接用 cap 一样了，但其实只是绕路了，和 docker 本身的意图有点背道。

不知道大家在 rails 项目上使用 docker 有啥可以借鉴分享的吗

lz，说几句不好听的，创业公司最怕的就是碰到你这样的了，也许你再磨几年，回头看看自己的经历，会有不一样的感想。

就谈 rails，用在你目前的项目上，碰到的瓶颈究竟是什么？是性能吗？在我个人的项目里面，感觉在前端资源的处理中，其他语言的处理还不见得有 rails 的 pipeline 来的完备，而且，rails 的 pipeline 等设计，包括开发模式和生产模式的一些处理，在我对其他语言其他框架的使用中，也总能找到各种影子，都是共通的。

我为什么说开头那些话，我的理解是，对于很多公司而言，上了套系统，性能上可能远没达到 rails 和 ruby 处理不了的时候，然后开发就风风火火地开始用另外一个新潮的框架去了，结果最后用很炫的语法做出来一套东西，存在着一堆的问题，维护还没人跟的上，至于性能的提升，恐怕只有一堆 hello world 的比较了。

当然如果在公司环境允许下，多尝试新的东西，这是绝对的好事，不过个人建言，慎言放弃，你可以不用它，但你更可以从中学到它的长处和短处

素质高的国企里面一般混不好，国企里面混得好的肯定不是素质高，情商高，人脉高才是最重要的

#39 楼 @lyfi2003

"最好"二字太过牵强，当然你要一定这么认为也是你的自由，只是我个人感觉，你给你的这个模板，冠上了太多的个人感觉而已