#4 楼 @chuanjiabao 你可以试下呗,在测试中的任意位置打印一个 I18n 出来,条目就是你对某一个字段验证的反馈信息,跑一下测试看有输出不?如果有输出那必然就可以用来做断言的呀。
#2 楼 @chuanjiabao 不清楚,我用 FG 的时候没有遇到过你说的问题,所有的字段验证错误都会在测试中报出来,只要你中文化里有对应的条目,就可以用 I18n.t
调用出来进行断言。
object.errors.message == I18n.t('what_you_specify_in_yml_file')
@zhulinpinyu @blueplanet @Vincent178 ok,ok,大家的热情我都了解了,我现在正在整理 Rails 4 的变化,等这个写完了就把视频弄完,因为我想在视频里都用 Rails 4 的代码,已经开始录了,再等等。
很好看啊,我把 mum 系列都看了一遍,其实对产品开发人员很有启发意义
$:
是 Ruby 内建的执行环境变量,它返回一个数组,包含了 include
和 require
方法会去寻找的脚本和二进制文件的路径。
可以用 $: << DIR
来扩充该数组。
它有个别名:$LOAD_PATH
扯跑偏了……
支持~会去现场,就怕那时候找不到位置坐。:bowtie:
#23 楼 @edokeh 两者无法并存,其原因并不在 rails,而是太多的前端工具所拥有的各种特性,你没法指望 rails 全部去支持;如果你认为 rails 管前端的事情管多了,那你有没有考虑过那些不用 require.js 或者 sea.js 的开发者又该怎样处理合并、压缩、cache 等等这些事情呢?是不是还要让他们去重新学习前端的处理工具?
作为一个最终用户我们当然习惯于从自己的角度来看待问题,但是作为一个框架的作者或团队,他们要考虑的问题面就要更加广泛了,它没法做得太简单而让很多开发者觉得不爽,也不能太复杂为了照顾一些高端用户而引入了太多的功能和复杂的处理流程。如何取得一个平衡点,同时又能提供一个扩展性和定制性强的工具框架,这毕竟不是一件简单的事情。
在我看来,Rails 在努力消弭前后端的界限,让更多专们从事后台开发的开发者也可以尽可能多和轻松的使用一些前端技术,反之亦然。这种做法本身是很积极的,但是肯定会遇到众口难调的问题。不管怎么说,理应获得更多的支持和鼓励,才有可能让事情变得越来越好。
另外,技术永远是在不断进步和发展的,node.js 的诞生不也一样可以被视作“前端侵入后端”的经典案例?如果其作者事先也想:“这样做会不会不好?”,那我们今天还能看到 node.js 吗?没有什么东西是完美无缺的,但这一点恰恰是证明我们作为“开发者”的价值所在,我们不就是那一群“让不可能变成可能,让可能变成更好”的人吗?
#19 楼 @edokeh 很遗憾,我说了 grunt 是一个纯前端的工具,它依赖的是 node.js 的环境,所以不能和 rails 一起用。
不过你不要忘记,ruby 本身就是一个很强大很强大的脚本语言,脚本语言能做的事情多了去了,并非一定要全部交给 assets pipeline。
举例说明,require.js 里有一个工具叫 r,js,它完成的工作就是将一个项目里的所有依赖关系文件打包,并且在内部做一些额外的工作(类似于你说的 SeaJS 的静态语法分析这一类的工作)。OK,那么 r.js 是怎么运行的呢?node r.js -o you_file.js
See? 它的工作是通过 node 执行的,那么我们完全可以在 rails 框架里,在 assets pipeline 执行前写个脚本调用这个命令,这样我们就可以使用 require.js 自带的打包工具了。
至于 SeaJS,因为我没用过所以不多做评价,不过我知道 SeaJS 的打包工具是和 Require.js 类似的,好像叫 spm.js?所以理论上也可以用一样的方法来完成这件事情。
明白这一点,我们也可以理解为什么 assets pipeline 没有这个功能,因为 assets pipeline 提供的是一种 common way,能够满足多数 general javascript 的打包、压缩等要求。但是对于特定的库,比如 require.js 或 sea.js 它又怎么去分别实现两者对于自己的库进行的特殊处理呢?就算它能实现(比如通过配置文件),那么你觉得有这个必要吗?你用 A,就要求 assets pipeline 支持 A 的特性,如果我用 B 呢?他用 C 呢?Rails 得多复杂才能满足所有人的胃口?
你只是看到了 Sea.JS 在 js 这一块比 assets pipeline 更多的功能,却没有看到 rails 做一个 full stack framework 又远比 Sea.JS 复杂了多少?正所谓:术业有专攻,作为开发者,我们当有能力在 Rails 以及 Ruby 给我们提供的基础上自力更生,而不是等着别人把我们七零八碎的要求一一去实现。
至于 grunt,那是纯前端领域的类似 assets pipeline 的工具,而且它不从属于任何一个框架,所以可定制性极强,且插件都是用 node.js 写的,对前端工程师天然友好。有兴趣的话直接去看看它的文档吧。
#4 楼 @edokeh 我觉得你这是把两个不同的概念放在一起来对比了;require.js 解决的问题是模块化和依赖调用,assets pipeline 的主要目的是减少 http request,这两者本来就不冲突。require.js 是从语言和代码结构的角度来提升开发,而 assets pipeline 则是从非代码本身的角度来提升开发,完全可以把二者的优势结合在一起,为什么非要隔离开来,还要比个高下呢?
说到纯前端的解决方案,assets pipeline + gems 就相当于 grunt + bower(yeoman 则是一个使用了两者的整体解决方案)无论是 require.js 还是 sea.js 都有 grunt 下的 task plugin,利用 grunt 就可以达到上述两个方面的优势和好处同时获得。
那么在 rails 这个领域里,现在的状况即 assets pipeline 就是 grunt,gems 就是 bower,而且都要更加强大的多(有 ruby 作为脚本语言支撑,当然 grunt 和 bower 也有 node.js 作为支撑,不过前者发展的更为成熟一些),我们完全可以在 rails 框架里使用 require.js 或者 sea.js,在满足了依赖管理等要求之后,还能让 assets pipeline 完成合并、压缩、cache、revision 等功能,何乐而不为?
#2 楼 @alucardpj StackOverflow 是 StackExchange 的一个子站,主要是上 SO 上多了,所以习惯性写了它的名字。
呵呵,windows 各种奇葩啊……直接在快捷键设定里面看看吧,不行就改了。另外,帮助菜单里应该有一个快捷键的 Cheatsheet。
那两个键应该是左右中括号,[
]
@QueXuQ 存数据和使用 nodejs 有何关系?这个例子里数据的存储应该是通过 HTML5 Local Storage 完成的,详见:http://spinejs.com/docs/local
完成这个例子用到的依赖包是用 npm 和 hum 管理的,不过涉及 spine 的源码都是纯纯的 javascript (coffeescript)
提议:加一个能在 Alfred 内调用 rvm 的功能,这样安装 gems 的时候能直接切换 ruby version 和 gemsets 环境,否则先去 terminal 切换,再用 Alfred 安装……啰嗦了点。
呃啊~~~买过了
@_@ 真看晕了,到底是用啊还是不用啊……
事实上是写错了,在配套的视频里,这一章的最后 Michael 做了一个更正,最终的结果如下图:
@u1355214846 你的疑惑没有错,的确这里有问题,但恰好在这个例子里局部变量赋值也没有影响最终的效果,所以很容易让人摸不着头脑。
#1 楼 @lidashuang 应该没啥,我是因为 Rails 4 出了之后想重读一遍文档,所以顺手做的笔记以备后查,然后就分享一下罢了。
他是不问问题就不说中文,说中文也不说简体的,maybe 是海峡对面的同胞,要么就是觉得简体中文的问题看起来没分量?
不知道为啥很多人喜欢把 around 翻译成周期,不是针对这贴里的几个回复,而是见过太多次了,这已经不是准不准的问题了,而是根本连词性都不对。“周期”是个名词,而 around 是个副词,它有“大约”的意味,也有“伴随着……”,“在……其中”等意思,怎么说也不能是一个生硬的“周期”哇。
这个标题的确不太好简明的表述,我个人觉得可以翻译成“在 block 之中执行”,不过这个感觉像是话只说了一半,没头没脑的。然而这一章前后都是在讲 block 的,所以进入到这个语境之中倒也不是难理解。
晕~这年头用 iTunes 都成高富帅了……
#4 楼 @evil850209 如果你怕风险,那就把那俩插件手动导入现有项目用呗……
use find_each
or find_in_batches
so Rails can help you to iterate all records but in batches, it will improve query performance. see documents here in details.
but pluck
is better in your case.
不是一千个词以内,而是使用一千个常用词,关键不在于词的数量而在于用词的通俗性