V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  chloerei  ›  全部回复第 69 页 / 共 81 页
回复总数  1616
1 ... 65  66  67  68  69  70  71  72  73  74 ... 81  
2011-09-12 21:31:05 +08:00
回复了 Zzway 创建的主题 Lisp 有人学或用Lisp的吗?
SICP 排在想读列表书就在旁边一直还没挤出时间
2011-09-12 21:07:25 +08:00
回复了 stranbird 创建的主题 Ruby rails3.1怎么组织assets比较好
@stranbird 不是,比如 assets/javascript 下面有这几个文件

applications.js
topics.js.coffee
settings.js.coffee

当你用 javascript_include_tag 'topics' 的时候,topics.js.coffee 就会被编译输出为 js。

打包需要声明宏,跟编译是两个过程。
2011-09-12 20:44:43 +08:00
回复了 stranbird 创建的主题 Ruby rails3.1怎么组织assets比较好
@stranbird 其实跟原来的没啥变化吧。

你遇到的问题好像是某个页面特定的 js 跟全局的 applications.js 一起打包导致了别的页面受到干扰?解决方案是不要把特定页面的 js 打包到 applications.js。

我用 content_for,js 逻辑只出现在需要他的地方。

jQuery 有个不冲突模式,也就是不改写 $ 全局变量。
2011-09-12 20:38:06 +08:00
回复了 stranbird 创建的主题 Ruby rails3.1怎么组织assets比较好
@stranbird 问哪一行?
2011-09-12 20:37:14 +08:00
回复了 Los 创建的主题 Ruby on Rails 关于 ruby 和 rails
@keakon 成功恶心到我了,over
2011-09-12 20:21:07 +08:00
回复了 stranbird 创建的主题 Ruby rails3.1怎么组织assets比较好
@stranbird 我觉得还是要 content_for

缺省一点可以在 layout 里面写

javascript_include_tags "applications", controller_name

但是我觉得这样不好,实际中也还没需要一个 controller 一个 js,所以 Rails 默认模板也没这么搞。

pipeline 是个很好的工具,引入 js 库变得很干净了(比如 client_side_validations),打包 js 也变得方便。但这东西不是天顶星科技,Release Notes 里面其实也就占很小篇幅。
2011-09-12 20:02:35 +08:00
回复了 stranbird 创建的主题 Ruby rails3.1怎么组织assets比较好
首先application.js去掉 require_tree . 然后具体指定需要全局使用的js。现在的 applicaton.js 里面的默认规则就像以前的默认路由一样,让你了解 assets pipeline是做什么的,迟早会注释掉。

然后特定的 controller 需要特定的 js,再建对应的 js 文件,然后引入页面。
2011-09-12 16:35:02 +08:00
回复了 oldman 创建的主题 程序员 求问有没有一个人写实现,一个人写单元测试的开发模型?
就是结对编程嘛
2011-09-12 16:32:06 +08:00
回复了 Los 创建的主题 Ruby on Rails 关于 ruby 和 rails
说说这贴没点出来的 ruby/rails 误解

1. Rails 传说中很敏捷,所以学起来是最快的

错误,学习 Rails 花的时间可能比别的框架都多。因为它一方面大包大揽,一方面默认你已经对各个层面的理论有了基本了解,选择 Rails 是因为你已经厌倦了重复制造轮子。但是,学习 Rails 比学习其他语言 + 框架 + 理论 + 最佳实践 + 时髦技术的总代价少,因为它已经为你选择了最受好评的那部分,节省了筛选时间。

2. Ruby/Rails 工作机会少

见仁见智。http://chinaonrails.com 现在招聘帖子很多,但我觉得他们挺难招到人的。有人觉得满大街的招人是安全感,有人觉得适合自己发挥的酷工作才有意义。

3. Ruby 程序员生产力高、一个顶十/玩世不恭、不负责任

Ruby 程序员也是程序员,有靠谱的有不靠谱的,好的程序员总是珍稀资源。
2011-09-12 16:04:37 +08:00
回复了 Los 创建的主题 Ruby on Rails 关于 ruby 和 rails
@Kymair 既然能接受霸道,为什么不能接受约定呢?
2011-09-12 16:02:11 +08:00
回复了 Los 创建的主题 Ruby on Rails 关于 ruby 和 rails
@keakon

Rails 3 没有生成 js 代码

x = save,x 得到的是 save 的值,不论他是方法还是局部变量。或者你觉得 foo.bar 和 foo.bar() 得到不同的结果更符合预期?

命名一直是高级语言一个非技术的纠结点,我不认为 Ruby 是特殊的。

其实你的偏见已经越来越越暴露出来,你为了证明 Ruby 有那么多问题,去想一些不切实际的问题,要不没人会这样做,要不不是 Ruby 特有的。

有什么语言能阻止程序员写出

def save(record)
....delete(record)

这样的代码?这样问题我都不知道点在哪里,哪个程序员写代码是为了跟自己过不去。

路由:完全不遵循 RESTful url,用 match 规则写路由没什么问题;表名不规则,那么设置一下表名;单复数支持很好,rails 维护了一个非规则的单复数名词表,你也可以自己定义特殊词表,也可以无视单复数。破坏约定时,代码量还是比自己实现一套规则要小。

回顾一下#4的套餐恐惧症。

不知道我盛气凌人了没有,我对着你提的问题一个个敲回应,结果就这样的。一方面想感谢你理解 Ruby 受了很多误解,一方面又很无奈你也是误解群体的一员。如果在你产生误解之前,能找到个人问那结果可能就不同了。
2011-09-11 15:01:30 +08:00
回复了 Los 创建的主题 Ruby on Rails 关于 ruby 和 rails
@keakon 前面有跟帖了。save肯定是方法,方法有问题,找方法的编写者。

简洁简约用来描述语言有啥语境区别我只能请指教了。

你对 js 库的理解倒让我觉得还未做到理解 web 开发的本质啊。

我也不太喜欢面向非 Ruby 人群讨论 Ruby,因为发现有些偏见根深蒂固很难改变。
2011-09-11 14:42:15 +08:00
回复了 Los 创建的主题 Ruby on Rails 关于 ruby 和 rails
还是挑几点说好了

1. 方法名和属性名

实例变量(对象的属性)都是以 @ 开头的,比如 @name,默认情况下只能在对象内部可见,要在外部访问,必须设置相应的方法。所以熟悉 Ruby 的人,肯定知道 foo.bar 这个 bar 是个方法,如果它有对应的属性,那么可能会命名为 @bar

你举例的 (@)saved 属性,从命名上看是布尔值,按照惯例,访问方法应该命名为 saved?

2. 方法的别名是开发者对语言和框架作者的适应。

也就是 Matz 和 DHH 为某方法设置了别名,那么想用就用好了。如果团队里面有人乱搞别名,要不人留下代码不留,要不人和代码都不留。

3. 人类语言本来就没有 hash。ruby 1.9 引进了 json 式的 hash,比如 { foo: "bar" }

跟2一样,不想用可以不用。

4. mootools 想用就用啊,该怎么用怎么用。最简单粗暴的拷进 public 目录用 <script src=..> 引进去。Railsful 一点的打包成 gem,用 assets pipline 跟其他js代码一起打包,减少 http 连接数。

奥,已经有人做了 https://github.com/neonlex/mootools-rails
2011-09-11 14:20:26 +08:00
回复了 Los 创建的主题 Ruby on Rails 关于 ruby 和 rails
我最反对的就是这句:

“Python追求简洁,不让人疑惑;而Ruby追求自由,让自己惬意。”

说得好像Ruby不追求简洁,让人迷惑似的。你提出的语法问题在实际开发中未曾成为问题,不一一反驳了。
1 ... 65  66  67  68  69  70  71  72  73  74 ... 81  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2610 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 33ms · UTC 06:33 · PVG 14:33 · LAX 22:33 · JFK 01:33
Developed with CodeLauncher
♥ Do have faith in what you're doing.