老哥地址填写的是 http 而网站是碰到 http 会跳转拿到 https 的？在帮助文档里有个群 可以加进去下 咨询

是的 我们倒是做了个 301 但是感觉可能很多地方不兼容 POST 301 的处理吧

免费是一次 20 分钟，每天最多不超过 2 个小时

redis 撑起了我的各种奇葩业务

啊？我是混用

但是用 unless 基本就是 return

类似 return unless xxx

哇 厉害！

撒花~ 能在郑州坚持下来，确实不容易

周末收拾家，又看见 元编程 这本书，被我收在柜子里，随手翻了下当年的笔记，百感交集，每次看都有新的收获

记得没错的话 gcp 是 0.24 usd / G 到内地

有些企业 gitlab.com 过不了审的

容器部署 + hk 区 0.04 USD / GB 瞬间闻到了航空站的味道

爱你一万年

不蛋疼啊，这种肯定是局部微调 style 用起来

人与人的差距 太大了 佩服楼主 用了这么多年 ruby, 真没研究内部的 C 的实现

所以 jsbundling 之后 就万变不离其宗了

😄我好像也没进 top 100

哦哦哦 那就是 买的 带宽吧 这种会不会 oss 把主机的带宽占满了呀

https://github.com/mbleigh/acts-as-taggable-on

其实 cdn 你也可以设置缓存时间，之后访问的时候如果用户之前访问过，就会单纯的 304。

如果用户没有访问过的话，无论是 cdn 还是 nginx 反代，都会走服务器的传输带宽（对应用户的下载），如果你的出口带宽是 弹性 ip 计费，则跟 oss 直接下载到用户是同价的

https://zh.lmgtfy.app/?q=alpine.js+with+turbo

或者

https://github.com/SimoTod/alpine-turbo-drive-adapter

正好我也研究过 alpine.js

个人感觉，alpine.js 最大的好处就是简单的令人发指的同时，js 文件又小巧

可以脱离 webpack, 脱离 node 环境，不需要额外的文件扩展名，直接引用一个 14k 的 js 文件，之后就可以在 html 里写东西了，单纯用浏览器跑起来就好，就拥有了现代前端的 state => ui 的能力。

只要是自己用 stimulus 自己实现一个可用的 modal 就知道，如果用 vanilla javascript 写 modal 的逻辑，还是有点累的。

alpine.js 于类似 react, vue 的还一个比较大的区别是，react，vue 虽然说也可以用在页面的局部，但是现在的风气是 react 或 vue 接管前端的一切，从路由开始接管，整个 html 代码恨不得就一个 body , 天然的倾向于做成 SPA。而 alpine.js 由于轻量化的设计，导致几乎所有使用方式都是页面局部的处理，不排斥后端渲染页面，可以轻而易举的嵌入已有的项目中去。

现在 alpine.js 继续发展的一个思路就是做通用组件库，组件设计好规定的动作逻辑和基础的 UI，用户自行丰富 UI 以及对逻辑动作进行扩展。他抽离除了几个常用的组件，如 modal, dropdown, accordion 啥的。其实还有一个类似的项目 叫 headless ui, 只不过那个的实现是用的 react 或 vue, 如果开发者不想或不方便在代码中搞类似 webpack 的工具，就不太方便了。

另外，因为 alpine.js 的低侵入性，它是可以和 stimulusjs +turbo 混用的，代价就是多 15k（14k core +turbo bridge 1k) ，只不过这个损耗在今天的前端世界，简直就是白送。

问： "总感觉深度融合前端，在一定程度上阻碍了框架的更流行？!!"

答：一定范围内，是的，rails 想做的事情太多，但是大多数人的耐心是有限的，或者职责是有限的，只不过对于创业者来说，rails 提供了一揽子解决方案。

问： “抛出问题：webpack 是前端打包工具，而 npm 安装的包又是运行在 node 上的 js 包。那么：npm 安装的包是不是经过 webpack 打包而来的？比如 bootstrap、JQuery、vue 等。”

答：webpack 是一种打包方式，npm 包不依赖 webpack，webpack 最本质的目的是为了处理不同 js 文件的互相引用问题。webpack 还有很多前辈或者同辈也在解决这个问题，例如 grunt. gulp 等。至于裁剪，压缩，顺带解 css 啥的，是他的附带业务，不是主业。

其他的内容 恕我语文不太好，没明白你的意思。

我光 editor 改造就不容易了 你们直接整了个 IDE 真大神！

嗯嗯 我就是利用的 iptables 弄的 google oauth

我的第一反应是业务规划，找出最核心的业务，依次保证

比如我拍个个脑袋：先保证礼物能送出，再保证礼物消息能推送到主播和金主，再保证其他用户能看到，再保证小时榜级别的更新，再保证其他的。

之后再拆到 礼物送出是需要保证 ACID 的，其他的 异步慢慢来，礼物推送到主播，最小消费一次推送，其他用户消息推出去就行。再就是榜单计算，比如 压力大的情况下，小时榜转化为 5 -10 秒一次结算，其他榜结算方式改为 5 分钟甚至 1 小时一结算降低压力。能放内存放内存，能不扔库不扔库。缓存 能分区域就分区域，redis 按地理区域划分，之后读的时候累加即可，不用做到原子性

当然这些都是基于我对直播粗浅的理解，在考虑技术实现成本的情况下想的一些皮毛，为大佬抛砖引玉。若有问题，还请别见笑

已更新到 rails7，对于我来说 最有用的是 multiple databases 在 has_one through 的时候，可以直接使用而不担心跨数据库了

还可以在 oss 上分 热资源 冷资源 继续压缩成本。。。

lol 出镜了，鄙人对各大厂商 cdn 花销这块还算研究的比较多，欢迎有想降低 cdn 成本，又对 cdn 质量有严苛要求的小伙伴找我做咨询哟，微信 atpking 注明 cdn 咨询

哈哈 很早就点赞的一个项目，算是同行

可以使用 tubro_stream 在第一级更新的时候 直接 stream.update 二级和三级 select

可以使用不同的 queue 之后 sidekiq 启动的时候 只消耗特定的 queue 即可