My new Sequoia 15.3 seems not loading C++ standard library headers and lead several native gem failed to compile:
|
Below is the correct solution:
|
My new Sequoia 15.3 seems not loading C++ standard library headers and lead several native gem failed to compile:
|
Below is the correct solution:
|
Sometime, it is easier to debug the Rails program if nginx can record the user’s post body and here is how to.
|
Warning: It’s not compatible with .NET apps, detail not yet check so recommand only enable during debug.
|
|
|
|
|
|
|
|
|
|
The puma file which will lauch puma via system service.
|
|
|
任何一门劝人入坑的文章大家都要注意背景,比如有些 Google 的雇员,因为要推广 Flutter,会把 Flutter 的能力写的花好稻好,然后最近直接团队被裁员,只留下误导新人的一篇篇文章,当然,我也得承认我写的这篇肯定也存在误导,但是我可以发自内心的表示,我至少绝对不是有意为之,我书写本文的目的因为我本身比较喜欢 Ruby 的自由,还有 Rails 的高开发效率。另外从 2012 年全面转向使用 Ruby on Rails 编程以来,它也给了我一份相对不错的工作。
有钱上 Mac,直接 brew install ruby,然后安装 rails,没钱用 Ubuntu 的 omakub,当然我也知道用 Linux 的用户绝对不会按照我推荐的 omakub,尽量不要在 windows 上搞 Rails,不是不行,坑太多,实在要搞,用 WSL 和直接用 ubuntu 类似。
此快速入门不会导致后期的练功反噬,请放心学习。
请直接阅读官方的guide 最新版本开始,中文的手册版本到 Rails 5.1,还是推荐英语。
官方手册是最快速最正统的导览,后端的功能基本上都提到了,原先可能还需要阅读一下《The Rails Way》,目前是第七版,不过这个是可选。
快速入门阶段最好不要过于扣细节,比如belongs_to
和has_many
是从哪里来的,是方法的话,在哪里定义的之类的框架细节,尽量将 Rails 作为一种 web 应用的定义语言(只是它恰好可以让计算机运行和发布成 web 应用)使用。
官方 Guide 没有提及任何的自动测试内容,这是对的,但是若您接下来就要接手或者开始维护,开发一个真实的 Rails 应用,《Rails Tutorial 6th 6.1.3.p1 中文版本》推荐一读,因为真实的应用多多少少都有一些 TDD 的内容,不过这只是可选。
另外的一个选择是《Agile Web Development with Rails 7.2》,也是半官方的教材,内容更加深入一些,已经不单单是一个入门教材了。
当没有完成 Guide 的整个流程前,请不要深入 Ruby 学习,因为这样会不必要的减少您学习 Rails 的时间。
当您开始对诸如1.day.ago
之类的 Rails 调用感到惊奇时,您可以考虑学习一点 Ruby 语言的知识,注意 Ruby 语言语法比 JavaScript 还要复杂,所以不要过于钻牛角尖,《Ruby 基础教程》第四版就是很好的入门。
权威性的 Ruby 教材是《Programming Ruby 3.3 5th》,只有英语版本。
不必深入 Ruby 也可以进行以下任意方向的学习
Rails 主要是一门后端框架,核心是 Active Record,还有一些 MVC 架构的约定,入门的定义是对这些已经掌握了,但是 Rails 毕竟是一种全栈的 Web 开发框架,相比后端,在前端的选择是非常非常多的。
抛去目前被废弃的 rails-ujs,Rails 出场自带的前端框架是 turbo / stimulus,若您没有任何的前端经验,推荐学习这套。
Rails 也同时支持Webpack 集成(顺带也支持了 React/Selte/Angular),Rails 也有Vite/Vue.js的支持。
若您有传统的 JSP/ASP.net MVC 程序员背景,更喜欢比较成熟的框架,Bootstrap 的支持也有现成模版,注意这个模版是笔者维护,并且使用了 coreui.io 的扩展,若您喜欢纯官方的,也可以自行封装。
《Modern Front End Development for Rails 2nd》也有助于对整个 Rails 前端生态有更多了解,但是这已经不是入门内容了。
Rails 支持 Restful 类型的 API,OpenAPI 3.0 规范 或者 GraphQL。
入门后若要进行 API 书写,推荐直接使用官方的 jbuilder 即可,OpenAPI 3.0 需要学习 grape,GraphQL 需要学习 gem graphql。
传统的 VPS 笔者还是推荐 capistrano,若您对 docker 有偏好,可以使用 kamal 2
Active Cable 基于实时双向的交互值得学习,想更深入也可以看一下 AnyCable,Bug 较多,但是性能更好。《Advanced CableReady》一书可以阅读
一些高阶的 Postgresql 数据库的特性也值得学习,Active Record 虽然非常强了,但是直接裸写 SQL 有时候更加方便。《High performance Postgresql for Rails》推荐。《Pganalyze Efficient Search in Rails with Postgres》也可以阅读。
《Ruby Science》by thoughtbot 可以阅读,不过我还是劝您不要花时间在这里,ruby 是很自由的语言,搞一下 standard 的代码风格检查已经做的有点过了。
Original from reddit
Go to chrome://flags/ and look for “Default Browser Prompt Refresh” and set that to Disabled. I believe that will turn that off.
今年的公司读书会的第二本书,我是从头翻到尾的读了一遍了,读完才发现被骗了,这书的中文标题就是错的:“流程圣经:让流程自动管理绩效”,我是读到最后一页才意识到被骗了,因为最后一个章节是“译后记”,译者总算在最后良心发现,提了一嘴我一直没主要到的细节,这书的英语名字是“Improving Performance: How to manage the white space on the organization chart”,这书出版于 2014 年,那时候还没 AI 和 GPT,不过我似乎已经找到了 2024 年的 AI/GPT 弱智根源,看着这英语书名,能翻译成“流程圣经:让流程自动管理绩效”,怎么说呢,完全突破了我的想象力,让我大受震撼!
本来我打算看完一遍就开始写书评了,但是看到最后一页这个英语书名和中文书名,让我有了很大的去读原文的冲动,毕竟,如果全书的翻译水准和书名的翻译一样水准的话,我就算再看一遍这本中文版的流程圣经,又有何意义呢?等等,圣经!译者想暗示这英语版就是骗人的吗?我不禁又一次陷入了沉思…
但我手头也没有英文版,但是我只能小心翼翼的,仔细读了译后记,果然发现了更多的问题,这书号称从 250 个成功实施的项目中总结而来,历经惠普,3M,壳牌石油和花旗银行等一众 500 强企业,具有实操性,所以,这就是这 10 年来,惠普蟑螂门,3M 沦落到 PDD 卖胶水,花旗银行,我一个好友供职的公司对华银行业务全关的真相?译后记还提到了“最系统,最科学,最完整”的流程方法论,嗯,可能 2014 年新的广告法还没有实施?译者知道这样写最,最,最,现在连拼多多的垃圾货也不会用这样的广告词啊!
吐槽结束,让我们在仔细看看这本书,第一章作者提出了一个很好的问题,就是直接画出类似苹果的组织图的企业是危险的,因为没有显示企业为客户提供价值的流程,从研发到生产到销售的过程。
嗯,我们姑且不论苹果是不是近年来最成功的公司,先看一下作者提到的几个核心主流程(第 50 页,流程层绩效):
坦白说,我认为,无论你如何设计流程,前面 5 个主流程都是困难的,而且是各个企业不同的,甚至这根本不是流程的问题。
我疑惑了,我又一次读了“译者导读”:“这套方法论能切切实实的为为数众多的中国企业带来绩效回报,尤其在劳动力缺乏,劳动力成本升高的今天,对企业压缩成本,提升效率,改进绩效的实践活动有着立竿见影的帮助”,我悟了,这书的前提有问题,错把结果当原因,绩效只是一个系统运行后的评价结果指标,流程是不可能自动管理绩效的,最多最多就是节省点思考时间,节省点人力,节省人力是有用的,节省思考时间是危险的,不可能把业务开发这样的高难度高灵活性高优先级的活动流程化,还是要靠人,最多最多,企业的这样的流程不造成阻碍作用,能帮助业务开发人员节省点时间就上上大吉了。
我其实重点是想做绩效,这个的确是流程的衍生,因为绩效总是想做的更客观一些,尽量排除主观的因素,读了第12章,绩效测评与管理体系设计,第250页,写到:“展示了绩效管理的3大构件,以岗位层为例:步骤1,为每个岗位设定产出和绩效期望值(目标设定)。”,是的直接跳到了步骤二,我不知道其他读者看了啥心情,我又仔细翻了前后,这本书最大的问题是在不该省略的地方惜字如金,在可以省略的地方给你大段的表格和流程图。本质上,我觉得这个书可能更接近于一本随着作者给美国企业培训流程设计,发给学员的教科书,还是2000年教改以后减负的版本。
我又稍微看了一下这本书的续篇,《流程圣经》的续篇:流程绩效实战,英语title是:“Serious Performance Consulting: According to Rummler”(Rummler是这两本书作者),我觉得这本就写的比较好,因为它提出了绩效设计的垂直职位的绩效矛盾和水平协作问题,而且表格也终于少下来了。图还是一样多。
总的来看,流程和绩效系统想设计的好,绩效的指标,期望值,或者说目标设定,还有指标之间的比例真的是艺术,缺了哪点都不行,而且似乎永远你能看到矛盾点,比如强调成单率比如影响回款率,因为销售倾向于无论啥单子都做,最后往往回不了款。
无论如何有书总比没书好,设计系统的时候有个checklist也好,不过我觉得我们设计现在的绩效系统,或者其他的,往往都是陷入于细节中,总体设计的时间,已经不能说是偏少的,简直就是没有…
gdu is a very useful disk usage analyzer in console, except directly install, under Rocky Linux 9, below installation method feels more native:
|
Another brand new Ubuntu 22.04 server and another installation log.
|
|
Using nodesource distribution
|
|
|
|
|
|
|
|
|
|
|
|
The puma file which will lauch puma via system service.
|