我也掉了一下,不过我爬出来了,webpacker 6.0.0.rc1 + webpack 5.0,终于吃上了!
内容细节不够,我怎么感觉只完成了 30%。。。还是感谢楼主分享
起初没有示波器就不能拍 Maker 视频,后来做不出小电视就不能拍,再后来得 17 岁高中才能拍,现在得撑起 Open Source 才行了么?
很少写类型判断,都是从数据库,从 json 格式上都解决类型问题,或者本来写的就是多类型通用的。
这个问题基本等于问你的月薪是否超过 18000。
ruby 不适合做大规模企业级开发。
其实 ruby 不适合做大规模企业开发的原因是,你很难招到 500 名 rails 开发,github 也不行。
面基面基!
大而全的保姆式框架,虽然面面俱到,你刚开始会用的很爽,但是对你的束缚也是真真切切。我们应该明白,任何一个软件、程序都有设计目标,功能范围。如果你在他的设计目标里使用就会如鱼得水,但是如果你超越他的设计目标,你就不得不要和这个技术框架做对抗。要去 hack 他的设计,组件。最终你会碰钉子—— 你会发现还不如从头自己来。
这两年我一直在试图突破 Rails 的设计,但我发现手头的项目好像没有啥独特的设计需求。。最近用了u-case,倒是不错,是 Rails 体系的一个好补充。
一出来就用了,但是当 Ruby 2 用的。(和我类似的点赞即可。。)
具体感觉,嗯,内存占用变大了一点点。。。🤦♂️
Web 复杂性越来越高是可见的,浏览器能力越来越强也是可见的,但是简单页面前后端一体的确是在总开发时间上是省的,但奈何现在有些 Web 应用的有些单页复杂性往往会非常高,在这种复杂度下,用一个好的前端框架,后端出 API 的整体复杂度相对可控一点(至少可以完全拆成两组人一起干)。
所以大前端的方向没有错,我觉得有错的是想把所有网页都用一个前端框架搞定,这即使是可行的,内存也太容易起飞,放弃用户切换页面就重新载入的后端路由后,也有较大概率导致浏览器内存泄漏,采用这样的架构不是很明智。
我:很棒!终于可以快乐的写代码了,哎,等等,我不是为了不写代码才用你这个系统的吗?现在我居然要沦落到为一个无代码系统手写一个 bcrypt 自定义函数?不写不写,专业的程序员肯定是用默认值,记下用户的密码啦!
用户:MMP,这啥破系统!居然明文记我的密码!
hashType: '', //【可选】密码哈希方式,可以是:md5, sha1, sha256, sha512, rmd160 或不填表示无哈希。
我没全看懂,但我大受震撼。难道 password 加盐 hash 不是专业开发者的选择吗?难道bcrypt做错了吗?我看来只能是业余开发者了。。。😭
那楼主能解释一下为啥你的头像出现在这个链接吗?实际上用 google 真的能查到好多。
这项目有点意思。
爬虫可以看看这个,另外让他们直接服务器上跑呗,或者树莓派,C 嵌入 ruby 其实并不是你的需求。
年轻人入 Elixir 还是不错的,我也想入了。
感到学 Rails 太费劲的往往是相对优秀的同学,如果不求甚解的用,其实不要太好用,但是很多优秀的同学喜欢刨根问底,那肯定会经过一段迷茫期的。
现在不用躲避了,新的 mimemagic (0.4.2, 0.3.9) 都是 MIT License 了,社区处理这个问题比那艘船的快多了!
最新的 0.3.7 和 0.4.1 版本暂时解决了污染问题,回归 MIT 了,当然,必须先有一份Freedesktop.org shared-mime-info database,好在很容易获得,Linux 基本都内置了。
主要也是工作忙。。
所以我的理解是,在修复之前,如果用了 MimeMagic 0.3.6,那么就是违反了 GPL?除非开源并且 GPL 你的代码?
gem content tests
先看一下安装上了没有。
挺有趣的例子,我也知道 Ruby 慢,所以一般遇到瓶颈,必然还是要准备一下直接上 C 语言的,花了一小时,写了我的第一个 C 扩展 gem fibc。
Fibc.fib_pure(4) # processing time: 0.000034s
Fibc.fib(4) # processing time: 0.000030s
Fibc.fib_pure(40) # processing time: 15.568888s
Fibc.fib(40) # processing time: 0.511246s
嗯,共有两种,如果不填 type,就随机。
IRB.send :easter_egg, :logo
IRB.send :easter_egg, :dancing
Sublime Text 4,我的配置,solargraph + tabnine 都用了。
因为要和 React 对标,怎么能用 webpacker 呢?必须自己写啊!
@dsh0416 我 evt 已经装好了,就等你指导怎么跑分了。
你问 Rails 社区前端微服务怎么做,是认真的嘛。。
其实我不喜欢 user->role->permission 这样的模型,因为根据过去经验,role 会爆炸,配置到后面也会超级麻烦,特别是如果用户可以有多个 role,一个 role 可以有多个权限,再来一个 role 可以嵌套 role 以后,你都不知道用户是怎么拿到这个权限的。。。
不过我尝试过直接根据业务规则直接写控制权限逻辑后发现,有时候用户又需要一个用户能访问的某个权限的名单,所以我现在感觉,直接 user->permission 这样的数据模型其实最方便,扩展性也最好,也简单。嫌配置麻烦的话,写一段自动生成 user_permission 的代码就好了。
rails 生态只看文档肯定是不行的,还要看代码,pundit 代码很干净,就一层 policy 抽象,scope/action 权限确认。