在号召一次,不要沉了啊!
因为在新的版本中,已经不用RAILS_ROOT
了,改用Rails.root
,但是你的代码中依然在用这个,解决方法是把所有的 RAILS_ROOT
换成 Rails.root
是通过 Twitter 的 Bootstrape 来实现的,具体见这里
谢谢楼主分享。
如果急需答案,你的问题一定要正确,比如让人能理解“共享 refinery 自己生成的 page 和 page part”,如果很难解释的话,就给个例子。
我们的老大和销售给开发团队设立了一个目标:将现几个 Web apps 用 JRuby 编译,打包成一个 war 文件,交付给客户,让客户能够一键部署。
这个目标在老大眼里优先级很高,于是团队就跟 Jruby 的关系就若即若离,非常暧昧。
这个得从 Rails 考古得角度来解释:
用这个名字命名得插件,最开始都是增强ActiveRecord
行为能力的,统称 acts_as_behaviors*
我最早从 Rails 1.2.6 开始作 Rails 项目,那个时候,Rails 自身自带三个 AR 插件,如果没有记错的话,作者都是 DHH
acts_as_tree
acts_as_list
acts_as_nested_set
到了 Rails 2 以后,这些插件都从 Rails 中抽取出来,变成了 gems 但是大家将这个命名规则保留了下来,作为一个 Convention,而且并不仅限于 AR 扩展插件了。 类似得还有 xxx_fu,这里得 fu 是 Kungfu 得意思。
#5 楼 @kevin__liu 真不凑巧,RubyTuesday 活动基本上只有一个规则,就是将人在规定的时间摆放在规定的位置上,具体时间和位置参加主题帖。
拜读之,收藏之,谢谢 @ouyang 原来教人如何写给力的文章本身也这么给力!
#15 楼 @kevin__liu 个人浅见,基本上没有从正面回答你的问题,呵呵。
顺便呼唤 @nouse 这次来不来,如果来的话,我想好好琢磨下你的 HHKB 键盘。
赞,到时候早点去占座,呵呵。
用一个例子解释给你
>> original_string = "Hello, "
=> "Hello, "
>> hi = original_string
=> "Hello, "
>> original_string.object_id
=> 70187424554540
>> hi.object_id
=> 70187424554540
>> there = "World"
=> "World"
>> hi += there
=> "Hello, World"
>> original_string.object_id
=> 70187424554540
>> hi.object_id
=> 70187437196000 # 这里hi的object_id变了,说明hi是一个新对象,说明 "+=" 操作其实是产生一个新对象,并赋值给原来的变量,但是并未改变 original_string
#43 楼 @alucardpj 默认适用 pg 数据库有另外一个好处,就是可以直接无障碍的部署到 Heroku 上,不知道 shopQi 是不是这个原因?cc @saberma
#1 楼 @lanwen #3 楼 @huangxiangdan 好奇的问下,跟大众点评或者其他图商怎么买数据,如果方便的话我很想私信跟你们聊一下,我的 mail lgn21st [at] gmail.com
我的桌子是在宜家买的厨房桌,就是那种放在厨房中间的工作台,高度跟吧台桌差不多,配一把吧台椅,站着干活或坐着都合适。
当时考虑的就是可以站着工作,但是其实大多数时候很懒,都是坐着的,只有在冬天天气冷的时候坐久了血液不循环,感觉很冷的时候,我才会站一会,然后身体热了就继续坐着了 XDDD
#7 楼 @huacnlee 全部改掉了。 #8 楼 @kevin__liu 关于大网站,其实是一个怎么“优化”的话题,没有统一的方案,具体思路是通过架构调优和运用 cache 技术,以及利用 NoSQL 数据库的 scalability 能力提升单机的吞吐量,然后增加服务器通过集群的方式解决大访问量问题,这个在这个社区里面讨论的不多,但是 Google 的话,能找到很多资料。
我觉得我应该给 Rails 做一点点辩解。
关于 Rails 所说的 Convention over configuration(简称 COC)其实是有个界定范围的。
对于 Rails,我认为这个范围就限于 Framework 本身,是gem install rails
安装的所有 gems。COC 给你最大的好处是节约时间,从而提升开发效率,我给你举个 Rails 框架内的例子,如果你要开始一个 Rails 项目,你是否需要先考虑用什么 template engine 呢?是 haml 好还是 slim 好呢?你是否需要先试用每个模板引擎后给出一个评测报告,然后你的团队根据你的评测来决定到底大家应该用那一个模板引擎?实际情况是不必,Rails 已经在 Framework 给你预置了ERB
,虽然有人觉得 erb 不是最好的选择,但是 erb 却是一个非常不错的 start point,你可以在将来根据具体的需求来决定是否换用其他的模板引擎。同样的 COC 还表现在 ORM,Routing,代码组织结构,gems 加载顺序等等。Rails 给你在 90%以上的情况下都适用而不需额外去做技术选型的框架基础,让你将注意力集中在业务本身。
记得在 Rails 之前,如果要用 Java 开发一个 web 项目,光是技术选型,项目框架搭建和模块划分,就足以让开发团队讨论很久很久了。
以上是 Rails 框架范围内的 COC,那么 Rails 框架范围外的 COC 呢?Rails 并不要求你一定要用 Mac 或者 Linux,Rails 并不要求你具体用哪个 Editor,Rails 同样也不直接给你“网站部署方面和整体架构方法”的 COC,怎么办呢?我们有社区啊,Rails 的 COC 其实一直在影响整个社区,比如什么系统最适合开发 Rails?什么编辑器最好用?怎么部署才是最佳实践,已经有了这么多的讨论,只要你保持对社区的关注,那么你完全可以自己佐证出一套大家普遍接受采纳的方案,那么这个方案就是一个不错的 start point,比如你想找个 Editor,看到 Vim 和 Emacs 的讨论,而且如果两边的拥护一样多的话,你完全不需要观望直到大家有了个统一的结论说 Vim 一定就比 Emacs 或者反之,随便选一个都是 good start point。如果是部署方面,你如果就从 ruby-china.org 的部署方案本身开始,绝对是一个 excellent start point. 所以你的问题就请直接参照这个论坛的部署方案吧。
另外关于“大网站”的话题,除非你已经有了明确的需求和用户数量(这种情况其实很少,试问多人上来做个 Rails 网站就已经是个大网站的?)。网站都是慢慢积累用户,从小网站逐渐发展成大网站的,所以一开始就寻求 Rails 的大网站解决方案,思路是不对的,当你足够了解了 Rails 的开发和部署方面的知识,怎么应付大网站的访问量,以及架构方面的调整,是水到渠成的事情。