#4 楼 @lyfi2003 再加一个淘宝，测试这块 ruby 很普遍

#4 楼 @zuowei 论坛是用来聚集同好的，如果是学习，各种 blog 其实不错，多搜一搜就会积累下来

我对这句话很感兴趣——“有些地方必需用 String 做 key”，有例子么？ BTW：这里的“必需”用错了，应该是“必须”

关注的人这么少？这本书很不错，不过不知道翻译的如何

#10 楼 @carl 这个没做过不了解，不过我 google 了一下发现有很多这样的文章，你都尝试过吗？

#7 楼 @hooopo 这个思路很敏捷，值得鼓励 (当然，实行的时候要看产品和项目的具体情况，要独立判断)。 说一下我自己的经验，我手边的项目在三个月内做了两次彻底的升级，由于升级前确保测试用例的充分覆盖，所以升级后立刻能知道是否可行，这样就可以灵活决定是否回到旧版本。另外，有一次升级遇到某个插件没有跟上 rails 的升级步伐，测试用例暴露以后我评估了一下，写了几行 monkey patch 绕开了这个问题，下次这个 gem 升级时就删掉 patch 总结：

1. 充分的测试是减少这类困难的有力保障
2. 动态语言、open class 有可能很好的解决兼容问题，但是要注意评估影响范围

#1 楼 @huacnlee 是的，bundle update 会升级一些 gem，如果你没有对这些新版本有足够的把握，不要随便 update

• http://gembundler.com/man/bundle-update.1.html

Update the gems specified (all gems, if none are specified), ignoring the previously installed gems specified in the Gemfile.lock. In general, you should use bundle install(1) to install the same exact gems and versions across machines.

You would use bundle update to explicitly update the version of a gem.

#5 楼 @pro20 第二条不一定是错误，看场景

#2 楼 @ichord 看了一遍，很有意思

程序和应用之间，其实边界没有那么清晰，但凡有点复杂性的东西都是需要设计的，看你怎么理解“设计”这个概念

#27 楼 @ery 这个提醒我了，我学 git 走过一个大弯路：没认真学习就拿着 github 就开练，结果把 rebase 当成 merge，痛苦了好久——不看书不学习是不行的

#19 楼 @lgn21st 我也不信，排队

未来也许有必要，目前我感觉社区还不够热

我的弯路还在走：懒得写博客......

#9 楼 @renrenshang rails 的特点是，如果你和 DHH 想法一致，那么很简单，否则很复杂。你直接用 ruby，基于 rack 规范，按照自己的方式开发 web 其实也可以

如果简单就用 cron，当业务复杂到一定程度，就要开发定时任务服务，用服务化的方式解决问题 切记，所有工具都有适用范围

#7 楼 @carl 我只是获取信息，不是拿来认证，所以裸用 ruby-ldap 就可以了

#8 楼 @huacnlee 拿出来大家 review 一下？

#5 楼 @renrenshang 你把“基本”这个概念弄错了，rack 才是基本，apache mod 是部署方案，而且还不是最好的方案，@metal 说的对，先看 rack，再看 sinatra，自己可以慢慢的尝试做一个山寨的 rails

#4 楼 @iwinux 将一些 has many 拆出成为扩展模型；将部分业务功能拆成 module；根据使用者类型的不同将业务分开（比如前端模型和后台管理模型）...... 总之这首先是业务问题，不是技术问题

@hide2 是不是就是 javaeye 上的 hideto？感觉很勤奋，以前写了很多有关 rails 的 blog

#5 楼 @carl 是啊，一般就这么用的

我用过是做用户信息查询，因为很多系统会有 LDAP 接口，比如 Windows AD

原来还可以用 block 阿，还是第一次知道

只写过没上线的示例项目，不过如果 ldap 协议没有变化，ruby 库不改变也是正常的阿

#10 楼 @jinleileiking 我对 md 一直不太习惯，至于编写 html，zen-coding 能起到很大帮助的

之前没有看到这个帖子，不知道有没有试过我们的镜像 http://ruby.taobao.org/mirrors/ruby/

@allenwei 说的不错，不过太炫了，而且对浏览器要求有些高（ff 上性能很差），退一步可以用 deck.js http://imakewebthings.github.com/deck.js 我现在一直用这个，很方便

没做过这种事，email 是 hard code，通常做法应该不太可行，我倒是觉得自己改一下 gem 更简单。 另外，devise 适合从零开始做的项目，如果是遗留系统，干脆抛开 devise 可能更好