对于一般的 Rails 项目，DDD 的最大价值在于 Ubiquitous Language - 用业务和应用域的语言来命名类，方法和变量，而不是用技术或者 Rails 的语言来命名，来增进易读性。

看代码形状

越是锯齿形的，锯齿越深的 如果用了 TDD 就越有利

补充几个对时间和当前用户缓存的策略：需要显示当前时间或者 n 个小时前 这种推到客户端用 js 实现 如果页面差异对不同的用户很小可以考虑 1）服务器端贪婪缓存，客户端用 JS 异步实现用户差异化 2）做 action / 页面 / 片段缓存，用 after_action 针对用户差异化 － 这个我没有自己试过，如果有做过的可以谈谈效果怎样

#40 楼 @xmonkeycn 其他的不清楚， cloudflare 是把 DNS 都包过来，所以对缓存页面的请求是完全不经过你的服务器的。

我们在用 cloudflare 可以帮助管理 2，3 的缓存不用自己弄； 不知道国内有类似的服务没有

函数数据流风格

fizzfy = ->((n, words)) {n % 3 == 0 ? [n, words << 'Fizz'] : [n, words]}
buzzfy = ->((n, words)) {n % 5 == 0 ? [n, words << 'Buzz'] : [n, words]}
whizzfy = ->((n, words)) {n % 7 == 0 ? [n, words << 'Whizz'] : [n, words]}
special_fizzfy = -> ((n, words)) {n.to_s.include?("3") ? [n, ["Fizz"]] : [n, words]}
initialize = ->(n) {[n, []]}
normalize = -> ((n, words)) {words.empty? ? n : words.reduce(:+)}

puts (1..100).map(&initialize).map(&fizzfy).map(&buzzfy).map(&whizzfy).map(&special_fizzfy).map(&normalize)

产品经理项目经理什么的 把经理换成 “管理员” 就对了

这个 video 里面有很多 Basecamp 的具体实践

#t=2m57s

#17 楼 @luikore +1

#8 楼 @hpyhacking 很好的一期！

希望能了解下除了网站／用户系统外的具体的交易系统是怎样的技术实现；如何直接对 P2P 的 block chain 进行编程？我看到过 coinbase 的 API, 但不知道这样 API 的底层技术实现是怎样？

还有，你们是否做 market making 来提供流动性？ 在交易所这样高并发的环境下 Ruby 是否是很好的选择？ 你们采用什么样的算法来确保最优化的交易？

最近有几个全职在家带小孩的妈妈来参加我们的课程， 真的有点全民学习的感觉

这个 “元驱动编程” 说的不就是函数式编程的思想么，还是我没看懂

Rails 大项目这几年发展越来多是 composition over inheritance, 越来越多的依赖 OO 扩展，而对框架本身的魔术依赖的越少了。

好的代码，模型和数据库的设计一定是业务驱动， 而不是技术或者框架驱动，再用代码或者文档在业务层和代码层搭桥。

在这个例子里面，与其想 Rails 的 convention 在这种情况下写？ 不如想在真实的情况下，你管这个东西叫什么？ 如果你在多个球队，你和每个球队的关联叫什么？你肯定不会说， "Oh, 我的这个 TeamUser 过期了!"，这样想那么 Membership 这个 model 就很明显了。而一旦你叫了这个 model Membership, 很多东西比如 membership status, membership expiration date, membership fee due date 这些就都有地方放了。

http://martinfowler.com/bliki/UbiquitousLanguage.html

#4 楼 @springwq 几个月的时间从纯小白到能找到一分不错的工作，放在任何一个行业都是奇迹了。

如果不知道该用哪个数据库，就用 Postgresql

They who understand OO are Erlang fans.

今天刚买了个椭圆训练机，据说是更符合人体工学的

造生命太短了，没人愿意干这事儿

http://stopwritingramblingcommitmessages.com/

涉及核心业务 － 自己写 基础设施或者边边角角 －可以考虑用 gems

#14 楼 @jarorwar

问题恰恰是当时的项目几乎是 Mongo 的最佳用例 － 从数据本身的结构，完全是孤立的深层次的 Documents, 而没有任何需要 cross references 的地方, 不需要任何冗余; 项目需要支持非常大的 scale， 深度的 Partition 和高可用，不需要灵活的分析，简直就是 Mongo 的案例型的项目。

前面很久的时间用 Mongo 非常舒服，mongoid 这个库也就是从这个项目里面抽取出来的，但是做到两年以后就越来越感觉别扭了，应为很多的新的硬性需求和最前面的数据结构假设非常不一样，也是可以实现，但是就觉得 Mongo 不是方便，而是处处别扭。

和 Sarah Mei 文章里将的案例非常相像。

#26 楼 @zhangyanan

过程式的思考方式是想一步步的"实现步骤"，然后抽取步骤重构出高的抽象层，是从下而上的；声明式是先勾勒出高层的框架，描述出问题本身或者解决方案的框架，在用具体步骤来实现，是从上而下的。Ruby 的语法很适合这种思维方式，对复杂的问题可以写成 DSL 来描述，然后解决。

#11 楼 @jarorwar

想说明 这不是一个出于技术无知的错误。参与的程序员对 Mongo 非常了解。