SQLPro for Oracle,同样是走的 x86 模拟模式,目前Oracle 在 Apple Silicon 发布 4 年后还没出 instant client,真的劝退,注意避雷。
2012 年,SanDisk,闵行工厂要上自动表单(400 多种不同类型的表单,比如设备维护表,值班签到表之类的),发现 rails 的 generate 不错,从.NET 直接转了,基于 Rails 的定制表单做完了。
wordpress 最近在快速萎缩啊…… wp engine 和官方的干架只会导致两败俱伤
嗯,作者后面结尾还是圆了一下,不过标题其实还是反 web component 居多,Liskov’s Gun/Checkov’s gun,我理解的言下之意是既生瑜何生亮,总要留一个的话,还是 React。
这文章写的挺好的,大家可以用 AI 工具尽量反驳我了,毕竟我直接读的原文……
你说的 caniuse 肯定是对的,但是作者在文章还提到了 apple 的故意 slow-walk 改进 web,当然这些问题随着 v1 的发布似乎都解决了,而且作者还说一些小框架,特别是 solid.js 作者,很早就开始试图通过采用 web component 从 react 这边抢夺采用率,但是架不住这句:
This is the background that led Ryan Carniato, the author of SolidJS, to write his blog post Web Components Are Not the Future.
毫无疑问,跳反杀伤力最大的还得是曾经的支持者。
我当然对 web component 演讲没有 @Rei 那么深入,不过作为吃瓜群众,觉得这文章还是挺有话题性的,无论如何。。。
作者语气肯定没我说的那么直白,客气了很多,但是说了好几个论点
虽然 DHH 还是代表 rails 官方,但我觉得太多存量的 rails 应用似乎并没有啥特别大的理由用 solid 系列新 gem 替换已有的成熟方案,无论如何欢迎 rails 8 的发布。
这些现象都是事实,但是并不构成不做程序员的理由:
所以花了一半的篇幅你想说的就是插播一个 OD 华为的外包广告?
这句才是真理,我给开源项目提 PR,多了真的不敢提,合并不进去的。
嗯,我最近再用 cursor,慢慢过度,现在很分裂
我说一个点,Sublime Text 比 VSCode 好,就是它的全局搜索是可以直接产生一个 Text Buffer,然后双击可以去不同的地方,VSCode 似乎只能出现在左侧,面积好小,上下文看起来远没有 Sublime Text 方便,而且全局搜索对我来说真的是一个高频操作。。
实际上,用户得非常留意安装信息里面,才能看到这句;或者说很熟悉 homebrew,再去用 brew info ruby 重新获取。
这里告知你了。
而这一切默认你已经会了。新人不会被告知。 :(
做为开发人员(无论新旧),都应该留意 console 输出,无论你熟悉还是不熟悉,共勉吧。
先把 ruby 版本拉到 3.3.2 再说,看堆栈是 openssl 报错
开源还是纯粹一点比较好,项目管理软件我还是推荐Open Project
不收,本门一脉家中有别墅是硬性条件。
太贵了,也可能我太穷了,99 刀我就冲了
建议还是 rbenv 用的人多一点,其实 brew install ruby 挺好的,我一直用它,测试特别全面。
今天的聚会照片
搞 Rails 你要出海啊,楼主定价很合理,你赚的可是美金!
甚至 AR 的约定也不是必须的,现在 Rails 7.1 支持组合主键,数据库的单独 ID 主键本来就是可以配置的,字段名下划线也不是必须的。还有个 readonly 方法可以强制 AR 为只读(不过还是建议开一个只读帐号,省的后面扯皮麻烦)
module Edoc2
class ProjectInfo < ApplicationRecord
establish_connection :edoc2v5 unless Rails.env.test?
self.table_name = "eform_thape_projectinfo"
def readonly?
true
end
end
end
这套就是 Rails 抢地盘生存的吃饭法门啊!
眼光放长远点,靠这点工资能发财吗?人生翻身的真谛当然是积极地在市中心 social 遇到一个有钱的她。(逃
顶一下老东家~~
可能是全中国办公室最中心的 Ruby 公司!
12G 内存其实就够了,可惜没有这档云服务器。所以还是应该下云,其实现在物理服务器真的便宜了。
你说的也对 在这之前可能编译时间已经促使不得不分开开发前端页面项目了 不过文档硬要把锅推给巨石应用也算服气的 你说你框架就是不 scale 不就好了 大家都是技术人员 这种小心思有必要吗?字节至少还搞了 rust 的建构打包器 阿里真的是遇到问题绕着走啊!
我这里有 120 个页面的,差不多是 1G,其实现在技术趋势已经可以看出了,如果这条路可行,那就不用搞微前端了。
stimulus 主打一个驱动现成组件,比如这段 HTML DOM 显示出来了以后,开始初始化某个现成的组件,而不是做组件。React 的确可以做到前端用其他工具都做不到的复杂组件,但如果全站全用,甚至接管路由,感觉有点不尊重用户的内存了,比如今天试用的金山网盘,直接吃掉 1.6G 内存,其中当然有 Electron 的问题,但是前端代码无节制的使用内存所占比例也肯定不可缺少。Notion 这边就做的比较好,基本占用内存在 800 兆以内。
所以我觉得其实还是应该对现在的中后台网站设定一个内存占用指标,比如 1G 以内。毕竟不是所有用户的电脑都有那么大的内存。8G 内存的电脑还是很多的,尤其是经济下行了,更新电脑几乎也是 6 年以上了。React / Vue / Solid 前端框架在这方面其实从来没有考虑过,我倒是觉得应该考虑,手机电脑的内存永远是有限的,以后的头显设备内存就更加有限了。
听上去是个好主意