有些企业 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 即可

不拿股份 不是说不行，但是从创业的角度上来说，不是个好事

项目初期还好，大家和和睦睦 等到了遇到瓶颈，需要花费与工资不匹配的时间，需要做超越的时候， 就怕核心认为 到哪里不是拿工资，走人

我认识一个做海外休闲游戏的老板，之前鏖战一沙雕游戏，苦了半年盈利了，但是分红没谈拢，技术怒而走人。创业公司人才梯队压根就没有，老板求神拜佛花了 4w 招阿里哥们补位，结果业务完全带不动，那哥们实在不好交差就上了个 k8s 后闪人了。

ruby 圈的盆友们都埋藏着创业的心 加油~

nginx 利用 HOST，转发到不同的端口

系统级的解决方案还是有意义的。一招鲜，吃遍天。可以同样适用与 sidekiq，或者其他服务的日志。就类似 弄明白 systemd 之后，就跟 进程自己的 daemon 模式说 byebye 了

注册了一个 看了下管理端 不愧是 oracle 数据库就只有 oracle 自家产品

CC 都好办 最麻烦的还是 ddos 直接不给你操作的任何机会，直接进黑洞

简单的搞法就是 通过 CDN 来隐藏服务 IP

我记得上次看到类似这个内容 好像是搏一搏，单车变摩托的故事线 也不知道那个老哥上岸了没

说实话 成年人 向来是全都要

脑子里冒出了滑板鞋的歌词：有些事我都已忘记但，我现在还记得