@whitecrow 说得好。公平性问题不解,请教是什么意思。
@moliliang ,你用 rake routes 查看一下找到合适的就行了。
eval "快速生成一个[1,2,3,4,5,6,7,8,9,10]的数组".gsub(/(\[.*\])/).first
只要你还是你自己就行。
@moliliang 在 form 里面你只用考虑 create 和 update 就可以了。这两个的路径名是一样的,只是 method 不同,一个是 post, 另一个是 put(Rails 3) 或 patch(Rails 4)。form_for
会智能检查if @vhost.new_record?
如果是,method 自动为 POST, 发到 create,如果不是,自动到 update。
= form_for @vhost, url: super_admin_vhost_path(@vhost) do |f|
请结合需求来提问。无需求无代码!
另外闭包不是万能的,滥用容易造成内存泄漏。什么技术都是适用才好。
If it ain't broke, don't fix it
@swordray 不客气。JS 库有的,timeago.jquery https://github.com/rmm5t/jquery-timeagogem:。还有一个 https://github.com/jgraichen/rails-timeago
这个 helper 要慎用哦,一不小心就是 cache 杀手。
lambda 其实就是匿名函数。主要用在一些一次性或者不需要命名函数的地方或其他。这种取名应该能用,但既然都取名了,直接用 def 岂不是更清楚。
127.0.0.1 好过 0.0.0.0
本地 development 服务器来说,只要你不是拿着笔记本在公共 wifi 上开发,并且不在意别人访问你的 500 错误信息,没啥问题。
服务器来说,只要你不直接用 WEBrick 来做服务器,没啥问题。
可以睡觉了。
@nate_yu 楼主估计晚些还要收些耳机。
@pynix 不用那么洁癖。可以用现成的其他语言命令已经不错了。我还想吐槽不是 OOP 呢。
@iBachue 很简单的语言,一看就会。另外一般用户不学也可以的,直接用插件就行。
官方都是用英文,哪里来的什么一致性。
Ruby is...
A dynamic, open source programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural to read and easy to write.
@jimxl 用 vim 都是和命令行一起用的。命令行和 iDE 的区别也是本质的。
@blacktulip 你说的有道理。vim 也有好用的补全,并且自定义极强,但肯定没有 IDE 来得傻瓜(非贬义)。我以前做 PHP 最喜欢 Netbeans 的补全,刚转到 vim 时各种不适应,还设置了半天。不过后来写 Ruby 时把 vim 的补全都停掉了,感觉不需要。
确实有点坑。不过看到这个图,第一反应是应该用 id with namespace,或者是 data attributes。而直接用国别名做 class 的话 name collision 的机会太大了,移植性低。
首先一个请求到后端,用 JS 或者直接提交表单。
后端脚本运行,把运行状态写入一个文本文件。
然后前端 JS 按一定间隔不断请求服务器,读取运行状态文件并写入 DOM。
运行结束后有一个特殊记录。前端读到这个记录停止请求。
@ysihaoy , 想请教 jetbrain 的什么功能是 vim 做不到的。
权限管理有很多种的。
第一,基于角色的管理。就是 role。楼上朋友写 node 代码的就是这种。角色是最简单的,但局限很多。比如管理员是可以删贴的,用户不行。但本贴的作者又是可以删的。这种很简单的逻辑用角色管起来就比较麻烦,不是说不行,至少代码很难看。
第二,基于行动的管理。这个是比较好的方式。轻松解决以上问题。CanCan 就是这种,Pundit 也是。Pundit 是匹配 method name,我觉得不如 CanCan 好。至于 Rails 4 兼容,不是什么大问题,因为 CanCan 代码其实不复杂。
第三,动态的管理。比如 Github 里面我的 Repo 加你做 group memeber,你就可以管理这个 repo 了,虽然没权删除。这个比第二个复杂,需要单独一个 authority model 来管理。这个的应用比较少一点。
综上,CanCan 是比较好的,适合较多的情景。
@leozwa, 不对的。如果没有 id,也没有检查 nil,那么会报错 no method "size" for nil。这是期望的结果,不用检查。
好处是少敲 4 下键盘 :)
@leozwa 你第二句挺好的,第一句检查if id.nil?
我觉得多余。这种情况不用检查,没有 id 应该直接报错"Invalid Argument"。
不过还是应该检查一下 id 是否合格。借用你的代码
def get_birthday_by_id(id)
case id.size
when 18
id[6, 8]
when 19
id[6, 6]
else
raise "invalid id"
end
end
内容网站本来就没有必要做 Javascript MVC。
你这一句既不是 stub, 也不是 mock, 而是直接 assertion 了。
我熟悉 Rspec, 不太熟悉 simple test 和 mocha 的写法,但大致差不多。
代码
def take_dinner
wash_hand
sit_down
eat
end
测试
def hand_washed_before_eating
@user.expects(:wash_hand).times(1)
@user.take_dinner
end
这样就可以了,这个测试确保 take_dinner 被调用时 wash_hand 也被调用。Rspec 和 mocha 里面这种带间谍的 expectation 一般写在前面而不是后面。
本意来说 mock 一般是对于 object, mock an object。但实际使用是 stub 既可以用在 object,也可以用在 method。不用揪理论,掌握 API 就行了。
@wuwx, 如果你这个 API 是面向一般用户的,我建议就不要动了。这个返回的错误是合适的。用户不应该知道 login 的具体错误,只要知道不对就好了。
如果是给管理员用的。API 的地址可以不要用这么通用的。然后你可以根据是否有错误来返回结果
@user = User.new params[:user]
@user.save.tap do |user|
if user.errors[:login]
orig_user = User.find user.login
user.errors.merge! orgi_user: orig_user.attributes
end
end
respond_with @user
以上把原来用户加入 errors 并在结果中返回给管理员做参考。
我知道是字段,但很少见取这个名字的。是不是 token 之类的东西。