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

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

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 非常了解。

#7 楼 @jarorwar 这个项目的带头人是 Mongoid 的第一开发者。

要用 mongo 真的要研究一下他的设计思想

这不是一个技术上的错误，而是一个对业务预期／沟通的问题。和 Sarah Mei 写的是一样的。

高通胀让法币在其生命周期中快速贬值，所以

1）让你的现金流尽量靠近法币产生的源头（政府通过财政政策和银行通过金融工具） 2）在没有现金流问题的前提下，多举债和投资，少储蓄 3）发工资，而不是拿工资

方法很简单，但只有权势和财富才能有这些条件，所以高通胀在本质上是从穷人到富人的财富转移。

试试 Time.zone.now.tomorrow

#34 楼 @swachian 美帝遍地是垃圾食品，但是安全性还不错。

这个也许对你有帮助： https://github.com/brandonhilkert/sucker_punch

源码我还没看，如果你看了给总结下 :)

#18 楼 @zhangyanan 这个是 Ruby 的 symbol to proc. 相当于

assignments.map {|assignment| assignment.grade}.uniq

很久前写过的一个博客，说的是这个问题。

http://www.gotealeaf.com/blog/declarative-thinking-with-higher-order-functions-and-blocks/

希望大家能看完 Greg 的演讲再发评论。ADD, Bi-polar, 等是生理现象，是神经系统的疾病。认为有这些疾病的人是 不够“心理强大”， “矫情”等 说到最好是颠倒了因果。正是很多这样的社会偏见让这些疾病患者才不愿意寻求帮助，在痛苦中煎熬，造成很多悲剧。

Greg 提到的 Caleb 原来是我的同事，因为工作绩效原因被原公司辞退。但其实如果他能有勇气跟大家沟通，而我们也足够警觉，认识到背后可能的原因，就像 Greg 将的，其实是有成熟的治疗方案的。结果最后他不愿意让别人知道而自己在没有医生指导下吃药结果去世了

类似的例子 Aaron Schwartz 这个圈子里的人大多数都知道，看看他写的东西，就知道他多受这个的困扰。

现在艾滋病都有足够的社会关注，但对“神经病”还有太多的社会偏见，这就是 Greg 要讲这个的原因。

程序语言的用户不是电脑而是人脑 电脑是不看什么程序语言的，只看最后的二进制码就够了

所以决定大多数 general purpose 的语言 的结构都很像人脑思考和对工序的描述，把复杂的问题分步骤加上条件循环什么的。可以找一个菜谱研究下

但是，在很多的特殊领域内，不用说解决问题。描述问题的本身往往需要更强大的语言，所以越是特定领域内的程序语言，往往越贴近问题域而不见得是人脑。这个时候就要程序员主动编程自己的人脑（或者叫学习一种不友好的语言），来优化问题的解决

#22 楼 @xdite 期待血泪

本质是对 api 操作和数据的本地封装；如果本地的应用庞大而且和 api 交互的方式多，可以用类似 gem 的做法，用和 api 操作类似的接口，可以参见 Github, Twitter 等的 gems; 如果本地于 api 的交互不多建议封装的时候用贴近本地业务的名字和数据封装

是保守的人开始进入社区了。Ruby 已经过了 early adopter 的阶段，开始逐渐主流了。

有想法，有激情，有时间，开始做就好了。不要听说不的人的。

#35 楼 @whitecrow 谁是用户？不是在抬杠，而是你的用户越模糊，你的产品越难做