• 看完后应该还要常常翻阅的☺️

  • 恭喜出版 🎉🎉🎉

    有幸作为大疆 Ruby 技术团队的一员参与技术审校,自从第四版之后我就一直想为这本书中文版的出版出一分力,终于在这一版如愿!感谢 Andor 和 chinakr 的细心翻译,感谢出版社和编辑独具慧眼引进这本书,也感谢其余参与技术审校的大疆 Ruby 团队成员用工作之余的时间完成审校,我为我们自豪!

    这本书是我的 Rails 入门书,让我真正走进了 Web 开发的领域,对我有特殊意义。审校过程觉得这本书和当初我看第二版的时候是一样的味道,循序渐进、深入浅出、语言风趣,让我想起刚接触 Rails 时的激动。这本书不仅仅是教怎么使用 Rails,更是教人怎么分解需求,一步步搭建 Web 应用。相比我看第二版的时候,Rails 已经有了很大变化,多出了一些组件,例如 ActionCable,审校过程还没来得及细细品味,纸质书到手之后我要再看一次!

    总的来说,这本书是目前最好的 Rails 和 Web 开发中文教程。

  • 我觉得文章的重点是怎么通过 FFI 调用 c share lib 吧。

  • 部署后邮件发送不成功 at 2018年01月20日

    服务器到邮件服务器的配置和网络。

  • 部署后邮件发送不成功 at 2018年01月20日

    Net::OpenTimeout 无法连接 smtp 服务器,检查配置和网络

  • Rails 中背景图片没显示 at 2018年01月20日
  • 部署后邮件发送不成功 at 2018年01月19日

    用 smtp 就不用 sendmail。

    现在服务器生产环境的邮件配置是怎样?(隐去账号密码)

  • 部署后邮件发送不成功 at 2018年01月19日

    邮件是需要配置的: https://ruby-china.github.io/rails-guides/action_mailer_basics.html#action-mailer-configuration

    默认配置的是 sendmail,如果你的主机上装有 sendmail 程序,那么就可以发送。服务器发不了可能是没装 sendmail。

    解决方法之一是在服务器装提供 sendmail 命令的程序,例如 postfix,但是接下来会遇到第二个问题,被收件方判断为垃圾邮件。实际中一般会使用 mailgun 一类的第三方服务来发邮件。

  • 介绍看着高大上,邮箱地址有点可疑……

  • Ruby 2.5 中的 yield_self at 2018年01月16日

    希望把原文链接放到前面。

  • 那么修改 nginx 配置,root 去掉 current 目录,reload 配置。

    current 是对应 cap 自动部署脚本生成的目录。

  • 正常顺序就是先触发 require_admin 然后 require_user,父类优先。

    你在 filter 里面打 log 再访问看看,清除 cookie 再访问看看。

  • ls /www/Haley_blog/current/public/assets/application-fd38ec0d36a29c0e7147c4c03b1d9eaeddab725402721f277495b90984aae858.css 看能不能找到文件。

  • 怀疑权限问题,执行 ls -ld /www/Haley_blog 看看。

  • 你需要看清 puma 和 nginx 的配置,而不是拷贝过来就用。

    从 puma.rb 的内容看,如果设置了 RAILS_ENV=production,就使用 unix socket 的方式,需要启动 nginx 做反向代理才能访问。RAILS_ENV=production rails s 走的是这一分支。

    如果没有设置 RAILS_ENV=production,就使用 puma 的默认配置,监听了 9292 端口。bundle exec puma -C config/puma.rb 走的是这一线路,当然也就没启动在生产环境。

    先简化问题,你是要部署到生产环境还是本地开发?是在服务器调试还是本地调试?

  • https://www.w3.org/TR/html5/links.html#link-type-noreferrer 看起来 noreferrer 就是 HTML5 的标准,而且 FireFox 文档也说支持 https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types

    没装 FireFox 不能测试。

  • 前后端分裂 at 2018年01月11日

    用两个极端例子做参照,新闻网站基本没什么交互,需要 SEO,适合服务端渲染;Google Doc 交互很复杂,不需要 SEO,只能重客户端;在这两者之间有很多重合区域,重服务端也行,重客户端也行。

    新闻网站 <—— (重合区域)——> Google Doc

    问题是到底自己的应用偏向于新闻网站还是 Google Doc。我认为大部分网站都是偏向新闻网站,局部复杂的交互可以局部使用前端框架,没必要整站用前端框架实现,这样架构更简单,开发维护更容易。

    我反对的是,抱着“应用总有一天会变复杂”的心理,不管实际情况无脑的选择前后端分离方案。这种流行影响了很多人,造就了一大批需求简单但难以维护的项目。

    推荐一篇文章 https://www.planningforaliens.com/blog/2016/04/11/why-js-development-is-crazy/

  • 关于 Rails 中的路由问题 at 2018年01月11日

    提醒:xml parser 以前出过远程执行漏洞,后来 rails 就干脆剥离了,目前维护热度肯定不高,为了安全最好别用。

  • 关于 Rails 中的路由问题 at 2018年01月11日

    试试 request.raw_post

  • 先换标准版 Ubuntu

  • 很好,可持续发展。

  • 前后端分裂 at 2018年01月09日

    Rails 是个多元化的框架,合适的工具做合适的事,所以不会局限于某个端,而是全局的考虑问题。

    https://github.com/ruby-china/the-rails-doctrine/blob/master/README.md#%E5%A4%9A%E5%85%83%E5%8C%96%E7%9A%84%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F

    如果接触 Rails 足够久,应该记得 RJS 模版,那是失败的实现。

  • Rails 部署负载均衡代理 at 2018年01月09日

    可以。

  • Rails 部署负载均衡代理 at 2018年01月09日

    可以啊,用 puma 或者 unicorn。passenger 的特点是作为 nginx 的模块编译,要想均衡负载可以在前面加。

  • 前后端分裂 at 2018年01月08日

    那么你是开发了自己的混合语言全栈框架,造了一个只有自己能理解的架构,我觉得你们老板说得对。

    其他部分,看起来你已经认同我博客里的内容了。

  • 前后端分裂 at 2018年01月08日

    你还没处理 SEO 的问题,所以还没理解同构要解决什么,如果要同构,中间层必须换成 node.js。

    不过内容看下来,你已经意识到了前后端不可分离了,不然你的前端方案无法实现。

    所以前端的诉求其实就是全栈,跟 Rails 的区别就是一个是全部用 JavaScript,一个是 javaScript + Ruby,那么也就别再抱怨说 Rails 全栈管太多。

    至于 node.js 全栈好还是 Rails 全栈好,这是另一个话题了。

  • 前后端分裂 at 2018年01月08日

    为什么前端会需要组件前后端一致,为了解决什么问题?如果你认同同构不现实,那么应该用什么方法解决它本来想解决的问题?

  • 前后端分裂 at 2018年01月07日

    你应该去看下 react 和 vue 的同构方案,这是纯前端搞出来的。

    Rails 可没搞同构。

  • 前后端分裂 at 2018年01月07日

    喜欢分离就是大公司病。

  • 还是那句话,开发效率高。试过有个前后端分离的功能改一个下拉框花了三天时间,各种协调工作、设计 API、测试联调……我就觉得把前后端分离当作唯一解法就是不对的。

    虽然大家都知道用什么方案要看用在什么场景,但就算很简单的场景要用 Rails 默认方案都会有人质疑这样会不会不好分工。技术潮流把人们对“分离”的期望推到了不理智的地步。

    现在要坚持 Rails Full Stack 路线很艰难,但不要放弃前端技能,技术潮流就像钟摆,说不定过两年又会摆回来。

    最近我观察到风向其实已经有点变化,看这个 Hacker News 这个关于一个 JavaScript 全栈框架的讨论串里面很多人开始批“现代前端”方案 https://news.ycombinator.com/item?id=16052558

    我喜欢这个评论:

    The reason this stuff gets popular is not because it's a good idea, it's because big companies have tons of cash and man power and can't wait for browsers to get updated. Well, a lot of us code monkey vets are done chasing "shiny crappolla", and we can wait a bit until the dust settles. https://news.ycombinator.com/item?id=16053587

    说远一点,我希望对新技术陷入狂热的人看一下一篇老文章,《行进中开火》 http://chinese.joelonsoftware.com/Articles/FireAndMotion.html