@fighterleslie 谢谢解答。

@huobazi @zlx_star 我看到 Lotus 第一个想到的是超市，第二个是跑车，还真没联想到 IBM，可能是没做过“企业级”应用……

我看了 GitHub issue 里的讨论，想问一个问题，项目重名真的有这么大的（潜在）问题么？

@zgm 我以前也是这般想法，但现在倒比较倾向组合一些小工具和框架。诚然 Rails 是一个很完善的全栈框架，但现实中的需求各有千秋，开发者的审美也各有不同。没有一套框架可以适应所有应用场景。这种情况下组合一些各个领域做得好的类库或框架，不仅可以根据项目和个人的情况选择更适合的工具，而且替换零部件的成本也更小。

@nightire 你这个是真精华

@nightire 你为什么不写 post

ES 里面有类变量的规范，Babel 等 transpiler 也已经实现了。私有变量是没有的，不过以现在 OO 的影响力，加进去估计只是时间问题了。

但是换个思路想，干嘛一定要用私有变量呢？真担心有代码会改写私有变量么？或者担心队友滥用私有变量？这种事情靠开发者自我约束就能解决。Ruby 和 JavaScript 都属于这类的语言。少了语言约束，但得到了灵活性。

我觉得 ES 给出 class 的写法，不是为了让 JavaScript 更 OO，而是为了在不改变 prototype 的设计思路的情况下，为批量创建 object 提供一个更 简便 和 统一 的标准（虽然也丧失了一些灵活性）。你看看各种框架里千奇百怪的创建“类”的语法就会觉得 ES class 还是有必要的。但这不代表你就一定要用 class 去构造整个应用，class 给了一个选择，但不是唯一的选择。如果你最后真需要了解 class，可以看看我之前写的 JavaScript 原型系统的变迁，以及 ES6 class 。

废话了这么多，说说我自己的应用场景，一般情况下我可能直接创建 object，如果很多 object 需要共同的模板我就会用 class。如果需要标注私有变量，我就用 _xxx 。团队里有明确的约束和 code review 的情况下，一般不需要担心什么。

我建议 LZ 想一下，用同样的时间成本，去做其他事情，是否比学车更有意义。一个例子，不学车了，空下来时间如果学些知识，能否让步入社会的起点更高一点？当然 是否有意义 这点只能你自己衡量，最后找一个投入产出比值得的方案就行。

学车比你想的要重要得多。但我觉得也到“错过这村就没这店”的程度。上班以后时间成本是比学校里高得多。但如果因此觉得没时间学车的话，那估计也没多少时间学其他的东西了。另外，如果你在大城市混，两年之内应该能够轻松负担起车的。如果现在手头没有重要的事情的话，早点拿证也挺好。

@eailfly 全路径是指 ./bin/rails 么？Ruby 里建议统一都用 bundler 管理，然后用 bundle exec xxx 运行 gem 的命令。如果觉得麻烦，有几个选择：

一是用 binstub 把常用命令放在项目的 ./bin 目录下，然后用 ./bin/xxx 达到 bundle exec xxx 一样的效果。

二是为常用的命令设置 alias。见 Never type bundle exec again 。我个人比较推荐一个脚本 bundler-exec。

三是针对 rails 的，直接运行 rails 命令会检测并使用当前项目使用的 rails 版本。所以 rails 命令是不用接 bundle exec 的。不过 bundle everything 是个好习惯。

smallest in lexicographical order 是说需要让去除重复后的字符串最小。这题麻烦的地方也就在这里，需要思考“当有重复的字符的时候，到底该保留哪一个？”。这涉及到如何比较两个字符串的大小，描述起来太麻烦，举几个例子：

"a" == "a"
"a" < "b"
"ab" > "a"
"ab" < "z"

这也是为什么第二个例子的结果会保留第二个 c，而不是第一个。

@gonglexin @yukihiro_matz Phoenix 的 channel 的抽象层级更高，而且个人感觉设计得更加容易理解。

我两个都写过 demo，ActionCable 里面分了 cable server, channel, broadcasting 三个概念，其中 broadcasting 才是负责把服务端的消息发送给客户端的，并且要跟 stream_from 配合起来用。虽然这些写法是固定套路，但感觉框架层面还可以把 API 实现得更简单点。不过 ActionCable 毕竟诞生不久，总有时间变得更好。

BTW 简单地看了一下 broadcasting，Rails 是直接把消息代理给 Redis 的 pub/sub 了。所以理论上 Rails 应该是不知道有多少个 subscriber 的。这点我没证实过，如果说错了欢迎指正。想了解的可以去 edge Rails 文档里去查。

Phoenix 里面的 socket 和 channel 都是抽象概念，具体实现方式不仅限于 WebSocket，所有主流平台都有对应的客户端（Web, iOS, Android），这应该是它相比 ActionCable 最大的优势。socket/channel 对应传统的 route/controller，代码处理方式也比较一致，你可以在 socket 文件中定义针对 channel 的路由，每个 channel 的 handle_in/handle_out 方法用来处理输入输出。感兴趣的可以去看 Phoenix Channel 。

:plus1: 正准备看的，然后发现翻译了，真快

@fredwu 非常感谢！

@fredwu 生活方面，请问在澳大利亚生活和在中国生活各有什么好处和坏处？

技术方面，请问您对“Rails Way”怎么看？我指的是传统 Rails 中组织代码的方式，比如 fat model，controller 的 before/after_action, strong_parameters。它们是否在 简单的场景 下仍然是很好的选择？甚至是更优的选择？

问这个问题的起因是，对于一些复杂的需求，我往往会根据抽出更多的对象让代码更好维护，但也导致会写一些“胶水代码”去组合使用它们；同时项目中有些部分的需求非常简单，直接在 controller 中操作 model 是最容易的选择。我想这种“因地制宜”也许是个好方案，但最后一个 Rails 项目中混合了各种不同的实现方式，某种程度上会让其他人不那么容易理解。我也曾经想过更 OO 的方式并没有问题，“胶水代码”的出现也可能是框架没有给出一个好的高层次抽象。不知道您对此怎么看？

@yukihiro_matz @tangmonk 哈哈，又有一个被骗了

@Kabie 似乎是警察暴力对待他，不过原因还不清楚。

@aidewoode 为什么改成 char =~ /[A-F]/ 了？

Ember 最头疼的就是没有好的配套 UI 框架，这方面的发展总比其他轻量级框架落后一点。

@zhang_soledad @yukihiro_matz 新兴语言和框架的生态圈不够好，这是大部分新兴技术的问题。相比起来 Elixir 其实还算好点的，因为 Elixir 可以直接用 Erlang 的包。后者发展了这么多年，再怎么说生态圈也不会太差。

我觉得 Elixir 的语言特性足够吸引人，也看好它的前景。语言特性几年之内非常难以改变，这甚至决定了一门语言能够发展的上限。相比而言生态圈则容易扩展得多，只要 key feature 足够吸引人。虽然谁也说不好 Elixir 能走多远，但它确实也是个挺有意思的选择。

BTW hex 的库里有 log 的 file storage，并且 mailman 也是搜索结果前三。就像你说的，功能肯定都是可以实现的。并且我相信，非常大众的需求往往都已经有了解决方案。至于是否框架内置，我倒挺喜欢 Web 框架就只干 Web 的事情，不过那是另一个话题了。

@hanhor @alex_marmot 这个问题 Phoenix 文档可以告诉你：

Phoenix views have two main jobs. First and foremost, they render templates (this includes layouts). The core function involved in rendering, render/3, is defined in Phoenix itself in the Phoenix.View module. Views also provide functions which take raw data and make it easier for templates to consume. If you are familiar with decorators or the facade pattern, this is similar.

我的理解是，Phoenix View 一是负责 render，二是负责隐藏 view 层的逻辑，让 template 变得更简单（类似 logicless template）的理念。相比而言，Rails 用 renderer 对象去负责 render，但默认不提供 presenter/decorator/facade 这类对象去隐藏 view 层的逻辑。helper 跟 presenter 并不一样，这点就不说了。

很遗憾，你这个情况必须把自己的存储逻辑用 transaction 包裹起来，没办法用 save 触发的隐式 transaction。

相比这个需求，我更好奇 LZ 为什么要排斥自己写 transaction 呢？只调一个 save 本身就是非常理想化的情况。稍微复杂点的逻辑都需要自己写 transaction，框架没办法帮你智能地界定 transaction 的边界的。

顺序跟原数组是一样的

看来群里没啥搞 Elixir/Phoenix 的人啊，求同好~

@psvr 同求分享的内容。另外派生 thread 是为了不阻塞 EM 接收下面的请求么？ 另外，视频里的思路是把 render 放到 job 里去，也是为了不阻塞 EM 么？

我觉得 Web 会是未来的方向。但是何必把 Web 和 Native 的界限划得那么明确。未来两者的界限会越来越模糊的，Web 应该是一种更好的发展思路，而不是仅仅是跑在浏览器里的一堆技术。

Grape 就是专门做 API server 的。按你的描述它应该是你想要的。Intridea 的几个 gem 质量都还是挺好的。

但是 Rails 做 API server 也没问题。其实渲染 JSON 也就是 view 层的一些变化，对一个系统而言更复杂的地方还是在业务逻辑方面。Rails 因为在 Ruby 框架中一直以来的统治地位，解决方案也相对更多。

并发量没测过，但大部分时候，缓存和没缓存是两个境界……如果目标开始就很明确的话，适量缓存可以减轻很大的负担，至少前期设计得考虑缓存的使用，避免后期加得太过困难。

@nightire 嗯，我说的是 JSONAPI::Resources ，文档和功能倒是很全，不过又抽了 Resource ，Serializer 两层，加上 Rails 默认的三层感觉有点复杂。毕竟 API 规范也只是整个系统中的一小部分，我比较倾向于能让事情变得更简单而不是更复杂的方案。ActiveModel::Serializers 我只用过 0.8 版，经验自然是没你丰富。还等着你什么时候分享 JSON API 的干货呢。

看了 Sparse Fieldsets 和 Patch，一个处理 response 一个处理 request，挺清晰的。谢谢！

@nightire 你说的 JSON API 实用场景我挺感兴趣。可否详细讲一下？我比较关注的几点：

1. 和 Ruby 框架的集成是否简单？(有一个 Orbit 作者他哥写的 Ruby gem，我感觉有点重了)
2. 对细粒度一点的 API 好用么？比如只更改局部数据而不是整个 resource 的
3. 涉及到多个 resource 的保存如何处理的？

既然说到“多花那 1 份的时间值在哪里” ，那我就从时间成本方面着手分析一下。

测试是什么

我的理解不是狭义的“用工具进行自动化测试” ，而是“检查软件功能是否运行正常” 。我们写代码的过程中，经常会刷新一下页面点一下功能，或者在 Rails console 里手动调用方法看结果是否正确。这其实也是测试的一种表现形式（手动测试，也称肉测……）。从这点来说，测试无处不在。因为你总要验证你的功能是否正确，对吧？

肉测的效率

既然测试这件事情是必做的，那我们思考的就不是“测不测”，而是“怎么更有效率地测” 。测试一般发生在代码修改之后（没有修改自然不会引入新的错误），所以保险起见，我们应该在达到一定量的代码修改的时候，把被影响的功能全部测试一遍。问题是：

1. 这一定是一个非常重复的过程。
2. 谁来界定什么是“被影响的功能” ？

肉测是回答不了以上两个问题的。人做重复劳动是非常低效且容易犯错的，而且在大量重复劳动下很容易草草了事，比如“我觉得这个改动应该对功能 A 没什么影响，不测也行”。这会产生一些明显的或潜在的 bug，成为以后开发过程的拖累。

自动化测试的好处

一定要做而且重复的工作，自然是交给计算机做更好。测试就是这类工作。以此类推的还有部署，数据库备份，代码风格检查等等。为一个功能写测试代码，第一次会花时间，但以后就可以非常快速地检查这个功能是否正确，在项目变复杂后也不用担心添加新功能或者重构会不会破坏已有的功能。不然的话，有可能后续一个开发周期有 1/3 的时间分配给改 bug，这效率能高到哪儿去？退一万步来说，就算维护测试的时间跟改 bug 的时间相同，我也愿意花了时间换来的是一个清晰可维护的系统，而不是补丁打满暂时能跑的系统。

什么时候没必要测

从上面的分析来看，开发周期不长，功能不复杂，并且开发完成后就可以撒手不管的项目是可以不写测试的。因为你的测试过程不会重复很多次，代码产生的修改也是有限的。不过我真不建议你这样做，因为：

1. 不要低估任何可以持续 3 个月以上的项目的复杂度
2. 习惯成自然，别指望一个平时不重测试的人到了大项目就会把测试写的很好

3.times do .. end 的 block 也是作用域。其他的 block 比如 each 同理。

另外，虽然没实际跑过，但你这段代码最后的 "#{person} got a #{number}" 应该是获取不到 number 的，但也不会报错，因为你正好实现的是 method_missing …… 这样会循环调用直到栈溢出。

粗看了一下，没发现心动的地方啊，可配置和分离式键盘都也不是新鲜的概念了。

concurrent-ruby 有意思