卧槽,老哥你不说我还没注意。。楼主就是那个连载多年赌海浮沉的大兄弟,难道真清掉债务重启人生了??而且工资还不错勒。好想听听后续啊
调 ChatGPT,最智能
末尾排版乱了啊
hook method 是个 stub 方法,相当于一个占位符,通常是在其他方法内部调用。比如 included 这个 hook 会在执行 include 中调用,respond_to_missing?在 respond_to? 中调用。通常 hook method 的默认实现都十分简单(respond_to_missing? 的默认实现就是直接返回 false),或者根本就是个空方法。它真正的业务意义是调用者自己通过 override 实现的。
大致来说,就是方法封装者留出一些空间,让方法调用者自己去注入自定义的逻辑。感觉就像是个模板模式
我们之前的实践是,在 rubymine 设置 sdk 的时候选择 docker 或 docker-compose 的环境,整个项目都是跑在 docker 里的,不需要单独为 gemfile 的内容再起一个容器
没记错的话,rubymine 支持 docker 环境,会同步 container 中的 gem 代码到本地,依然支持代码提示和跳转
只有职位够高才有机会在需求层面就解决问题呀 。
能在需求和设计层面解决、缓解问题是最好滴。如果客户非要在技术层面去实现,俺们一般就三个字:“得加钱”
核心业务还在,哪里会发不起工资嘛 。这个折腾也算是带薪学习了
生活中没怎么见过文章中所批判的那种人,不过如果真的有那种“遨游在技术海洋,巴不得越学越多,尽可能触及技术天花板”的人,俺们小公司巴不得招一个。。。
赞。之前一直困惑应用日志为啥和 cloudwatch 日志的时间戳不一致。。。
流批了,ActiveRecord 快了 60% 勒
有空交流啊,微信发你邮箱勒
我其实已经找到了部署问题,就是没有充分利用 github action 的缓存,导致构建镜像太慢,暂时没时间去实验。
很早之前我就用过 alpine 的版本来做基础镜像,最终构建出来的镜像能比基于标准版的镜像小接近一半。不过由于 cto 的轻微反对,加习惯使用 ubuntu 了,就又切回去了
除非客户明确提出性能有问题,不然我们一般不会先上缓存。。。
命中缓存时日志会有提示的。 如果是说页面缓存的话,需要使用 cache 方法,像这样
<% @products.each do |product| %>
<% cache product do %>
<%= render product %>
<% end %>
<% end %>
如果是底层缓存,需要使用 Rails.cache.fetch。
还得构建镜像,推送镜像 。我们用 github action + AWS ECS, 部署时间通常要几分钟的。暂时没空优化,不知道有没有老哥有这方面的优化经验分享一下
俺们用 docker 部署就不怎么担心这个问题,每次部署都是个新的容器,缓存文件会被清掉。。。缺点是部署时间较长
流批,CTO 都有时间写博客,我等楷模
赞!域名是固定的不?
很好。俺们用 ferrum 来操作无头浏览器。都是基于 CDP 协议,不知道与 puppeteer 有何高下
一楼老哥其实想问的应该是“前后台(前台和管理后台)是否分开部署”,而不是”前后端分开部署“
上 WSL、docker 或者虚拟机
fiber ?
放在一个队列,然后只给一个线程执行这个队列?
很好,我选择 steam
Wish!
我感觉这种方式几乎是直接把后端的模型暴露给了前端
它实际是多抽象了一层(GraphQL 里叫 type,JSONAPI 里应该叫 resource)。由于可以使用框架命令根据 DB schema 来生成这一层的内容,所以看起来像是暴露了模型。然而实际在项目里必然会更改这些生成的代码,删除大量的 meta data 字段,重新定义字段
跟传统 API 的区别在于,传统 API 返回的某些字段可能是后端计算之后返回的,也就是说返回的 JSON 结构跟后端模型结构并不是完全一致的
拿 GraphQL 举例,type 中的字段逻辑是可以自定义的,当前端想要 full_name, 而数据库只有 first_name 和 last_name,完全可以在对应的 type 中定义一个 full_name 字段。前端想要日期格式的 created_at, 而 DB 只有 time 格式的 created_at, 也可以在对应的 type 中转换。甚至你也可以完全定义一个不对应任何模型的 type 出来。所以只要后端肯干,完全可以不把业务逻辑交给前端。
Graphql 就把当前问题搞大了点,相信楼主没有时间去改造框架,也很难短时间说服前端去用 Graphql。
感觉这个问题主要看前后端谁是主导地位,前端主导的话,估计就要单写个聚合接口了(面向 UI 设计接口)。后端主导的话,如果其他几个接口没有互相依赖的话,可以酌情复用接口。前后端谁也说服不了谁的时候,于是就出现了数据中台。。。但是一般小公司也不会有中台
不需要这么复杂,直接用宿主机的 ip 地址即可,在 zshrc 中加一段脚本设置代理地址
host_ip=`tail -1 /etc/resolv.conf | cut -d' ' -f 2`
export ALL_PROXY=$host_ip:7890