#8 楼 @jasl 哦，那算了。

#6 楼 @aptx4869 感觉很花哨……

#4 楼 @cassiuschen 想想还是半透明性价比高啊……

#1 楼 @gaicitadie 我很喜欢啊！我在想，半透明效果和毛玻璃效果用哪种好看呢？而且透明很符合我的网站主题。

额，这是什么东东？ PR，我第一反应是：公关……

#37 楼 @bhuztez 私聊私聊，QQ

另一本关于 Rails 的电子书，哪本？不如来本《The Rails 4 Way》算了。

#34 楼 @fengzhe 我在用 jQuery，不过一切很初级，那我水平再高点时再看这本书……

#33 楼 @bhuztez 我小伙伴在美国，我不好意思开口，额，我不想他太了解我作为“猪一样的队友”的事实……虽然我已经坦白从宽了……

#12 楼 @lg2046 #13 楼 @xwf286 我看了看译者之前翻译的其它书，貌似不是 RUBY 相关的，要不我还是咬咬牙看英文的算了……

#31 楼 @fengzhe 《黑客与画家》看过了。 《Javascript: The good part.》这本好在哪里？最近正想好好看下 JS

#29 楼 @jarorwar 万网？我感觉万网的客服还行……

啥时候才出正式版啊？现在用是要手动标明版本号吗？

#27 楼 @jarorwar 哈哈哈哈，起码人家客服理你吧？貌似听说盛大云你还常常找不到客服的……

#24 楼 @bhuztez 我只对 AWS 有信心啊，一直很期待它能进入中国啊，真心的。国内其它云一直都观望状态，木有下手。

#23 楼 @jarorwar 有啥可后悔的，之前只有阿里云、盛大云有名一点，盛大云还是不如阿里云，所以你做了当时可选范围内最好的选择……

#11 楼 @chenni 我觉得这是防御战。 因为 AWS 声名在外，日后可能成为强劲的竞争对手，最好是在 AWS 在国内发力成功之前尽可能拉到更多的客户。 因为虽说是云计算，但对开发者来说，迁移数据服务器重新部署还是有些麻烦的，如果不是好得多的服务，没准就将就着继续用了。 而如果已经在现有的云上预付款的，比如在促销活动冲击下，已经一下子购买了三年服务的，可能也舍得不放弃。所以，它既得现金流，又维持了客户忠诚度。

如果是别的领域国际巨头进入中国，本土根本不会怕的，因为对国内用户的熟悉，本土化用户体验做得更好，一般反而会打败国际巨头。 但偏偏是云计算这种针对开发者的商业领域，目标用户就是程序员，而程序员大多在专业方面视野非常国际化，所以大家更认可 AWS……所以 AWS 占领本土如果不是它自身被墙的原因，或其它政策原因，感觉，这仗打得会容易得多。

#19 楼 @jarorwar 嘿嘿，没想过用阿里云，现在就是用着日本的 linode

喜欢最后两句，哈哈哈哈

#9 楼 @loveky 哎呀，我是担心英文版的我读不下去，读英文貌似要看心情啊，心情好读得比较顺畅，心情不好常常会发现自己同一段话看了几遍还是没入脑，直接走神了…… 中文版的话阅读速度快，因为我大脑太习惯阅读中文了，建成高速通路了……

不过有时看中文也的确别扭，当你习惯一些英文名词时，这些名词已经直接跟你的具体理解连接起来了。看中文反而要先自己翻译成英文去理解。 比如看到“接口”这样的名词，我宁可他们直接说“Interface”

#4 楼 @xwf286 依你看是什么水平？

第 1 章 面向对象设计 1.1 设计赞歌 1.1.1 设计解决的问题 1.1.2 为何难以更改 1.1.3 实用的设计定义 1.2 设计工具 1.2.1 设计原则 1.2.2 设计模式 1.3 设计行为 1.3.1 设计失败 1.3.2 设计时机 1.3.3 设计评 1.4 面向对象编程简介 1.4.1 过程式语言 1.4.2 面向对象语言 1.5 小结 第 2 章 设计具有单一职责的类 2.1 决定类的内容 2.1.1 将方法分组成类 2.1.2 组织代码以便于更改 2.2 创建具有单一职责的类 2.2.1 示例程序：自行车和齿轮 2.2.2 为何单一职责原则很重要 2.2.3 确定一个类是否具有单一职责 2.2.4 确定何时做出设计决策 2.3 编写拥抱变化的代码 2.3.1 要依赖行为，不依赖数据 2.3.2 全面推行单一职责原则 2.4 最后是真实的轮子需求 2.5 小结 第 3 章 管理依赖关系 3.1 理解依赖关系 3.1.1 认识依赖关系 3.1.2 对象间的耦合 3.1.3 其他依赖关系 3.2 编写松耦合的代码 3.2.1 注入依赖关系 3.2.2 隔离依赖关系 3.2.3 移除参数顺序依赖关系 3.3 管理依赖方向 3.3.1 反转依赖关系 3.3.2 选择依赖方向 3.4 小结 第 4 章 创建灵活的接口 4.1 理解接口 4.2 定义接口 4.2.1 公共接口 4.2.2 私有接口 4.2.3 职责、依赖关系和接口 4.3 找出公共接口 4.3.1 示例程序：自行车旅游公司 4.3.2 构建意图 4.3.3 使用时序图 4.3.4 请询问"要什么"，别告知"如何做" 4.3.5 寻求上下文独立 4.3.6 信任其他对象 4.3.7 使用消息来发现对象 4.3.8 创建基于消息的应用程序 4.4 编写能展现其（内在）最好面的代码 4.4.1 创建显式接口 4.4.2 善用其他类的公共接口 4.4.3 避免依赖私有接口 4.4.4 最小化上下文 4.5 迪米特法则 4.5.1 定义迪米特法则 4.5.2 违规的后果 4.5.3 避免违规 4.5.4 听从迪米特法则 4.6 小结 第 5 章 使用鸭子类型技术降低成本 5.1 理解鸭子类型 5.1.1 鸭子类型概述 5.1.2 让问题复杂些 5.1.3 发现鸭子类型 5.1.4 鸭子类型的后果 5.2 编写依赖于鸭子类型的代码 5.2.1 识别出隐藏的鸭子类型 5.2.2 信任你的鸭子类型 5.2.3 记录好鸭子类型 5.2.4 在鸭子类型之间共享代码 5.2.5 合理选择鸭子类型 5.3 克服对鸭子类型的恐惧 5.3.1 使用静态类型颠覆鸭子类型 5.3.2 静态类型与动态类型 5.3.3 拥抱动态类型 5.4 小结 第 6 章 通过继承获得行为 6.1 理解经典的继承 6.2 弄清使用继承的地方 6.2.1 从一个具体类开始 6.2.2 嵌入多种类型 6.2.3 找出嵌入的类型 6.2.4 选择继承 6.2.5 描绘出继承关系 6.3 误用继承 6.4 找出抽象 6.4.1 创建抽象父类 6.4.2 提升抽象行为 6.4.3 从具体分离出抽象 6.4.4 使用模板方法模式 6.4.5 实现所有模板方法 6.5 管理父类与子类之间的耦合 6.5.1 理解耦合 6.5.2 使用钩子消息解耦子类 6.6 小结 第 7 章 使用模块共享角色行为 7.1 理解角色 7.1.1 找出角色 7.1.2 组织职责 7.1.3 删除不必要的依赖关系 7.1.4 编写具体代码 7.1.5 提取抽象 7.1.6 查找方法 7.1.7 继承角色行为 7.2 编写可继承的代码 7.2.1 识别出反模式 7.2.2 坚持抽象 7.2.3 重视契约 7.2.4 使用模板方法模式 7.2.5 预先将类解耦 7.2.6 创建浅层结构 7.3 小结 第 8 章 组合对象 8.1 Parts 组合成 Bicycle 8.1.1 更新 Bicycle 类 8.1.2 创建 Parts 层次结构 8.2 组合成 Parts 对象 8.2.1 创建 Part 8.2.2 让 Parts 对象更像一个数组 8.3 制造 Parts 8.3.1 创建 PartsFactory 8.3.2 借助 PartsFactory 8.4 组合成 Bicycle 8.5 继承和组合的抉择 8.5.1 接受继承带来的后果 8.5.2 接受组合带来的后果 8.5.3 选择关系 8.6 小结 第 9 章 设计最划算的测试 9.1 意图测试 9.1.1 了解测试的意图 9.1.2 了解测试的内容 9.1.3 了解测试的时机 9.1.4 了解测试的方法 9.2 测试输入消息 9.2.1 删除未使用的接口 9.2.2 证明公共接口 9.2.3 隔离测试对象 9.2.4 注入使用类的依赖关系 9.2.5 将依赖关系注入成角色 9.3 测试私有方法 9.3.1 在测试过程中忽略私有方法 9.3.2 从测试类里移除私有方法 9.3.3 选择测试私有方法 9.4 测试输出消息 9.4.1 忽略查询消息 9.4.2 证明命令消息 9.5 测试鸭子类型 9.5.1 测试角色 9.5.2 用角色测试验证测试替身 9.6 测试继承代码 9.6.1 指定继承接口 9.6.2 指定子类责任 9.6.3 测试独特行为 9.7 小结 后记

#3 楼 @xds2000 你是说中文翻译很差？那就痛苦了……买，还是不买？

#5 楼 @cqcn1991 这么牛 X？那得买一下……

哈哈，等了好久

这书很好吗？好在哪里？好我也买！

#11 楼 @libuchao 啊哈哈，我也看到微博各种类似照片了！

好长，有空再看，mark!

#6 楼 @libuchao 真的真的？我就等着啊！啥时候啥时候？

#22 楼 @nightire 我一开始是以为会跳转，后来听你说 URI 啥的，我对你的话的理解是：url_for(params.merge(text: true)) 只是把 params 给融合了，所以不会跳转的……

你知道我都糊里糊涂的啦……我以为只是页面图片那部分刷新一下，图标本身是不刷新的……

#3 楼 @upyun 好好好，多降点，到时我可能还真得用不少……最好时不时来个优惠码，折上折