2.7.1 Limits to Nesting http://guides.rubyonrails.org/routing.html#limits-to-nesting
Resources should never be nested more than 1 level deep.
用什么判断一段代码是否简洁?不是代码行数,而是语法单元的数量。
expect(Calculator.new.add(1, 2)).to eq(3)
语法单元有 expect
to
eq
,长度为 3。
assert_equal 3, Calculator.new.add(1, 2)
语法单元有 assert_equal
,长度为 1。所以,assert_equal
的代码更简洁。
Paul Graham 在《梦寐以求的编程语言》中有一段讨论到简洁:
不要觉得为用户着想就是让他们使用像英语一样又长又罗嗦的语法。这不是正确的做法,Cobol 就是因为这个毛病而声名狼藉。如果你让黑客像下面这样求和:
add x to y giving z
而不是写成:
z=x+y
那么你就是在侮辱黑客的智商,或者自己作孽了。
我记得 gitlab 不是有 deb/rpm 包么?
哇,这代码排版是按照什么语言规范?(反正不是 Ruby)
Ruby 2.2.1 有缺陷,依赖已经升到 Ruby 2.2.2 了 https://github.com/rails/rails/pull/19753
token 当然要和用户绑定啦。
另一条路:
将 B < A
改成 A < Base
,B < Base
,Base 没有校验。这样 A、B 逻辑是独立的,依然在同一个表。
如果需要共享方法,用 Concern(Module)。
如果 A,B 不需要在同一个表,只需要共享方法,那么不需要继承,只用 Concern(Module)。
You're gonna love it in day 5 and you're gonna hate it in year, but that's all good because the meantime you'll be blaming me and we can still work together. —— DHH,RailsConf 2015 - Opening Keynote
印象中不好跳过,validate 是作为匿名方法放到一个列表里的,虽然是可以过滤出来,但是代码很丑陋。
父类有的校验子类不需要做,那么这个继承关系是否有问题呢?
这是在给自己挖坑啊,能说说目的是什么吗?
JavaScript
我觉得从 RubyInstaller 起步,遇到问题逐个解决比较好。
<%= render partial: "users/user", object: @user %>
楼主面临一个机遇,这个项目就是试水的,看看 Rails 效率高到什么程度。如果让老板满意,那么以后新业务可能会往 Rails 迁移,那么楼主作为先行者在公司的地位就会上升。
但是开发效率高不意味好入门,从零开始三周有点难,如果之前业余就有学就有可能。
是根据对象的类型去找模板。
['9956'.hex].pack 'U'