看来也是 Jeffery Way 的粉丝一枚啊。

说到重，Ember 其实比 Angular 重多了。Angular 比较好拆分或组装，Ember 则不然（当然也可以，但是相较于 Angular，Ember 更是一个有机的整体）。至于你的 MEEN，我反而觉得没有 MEAN 更加必要，MEAN 的主要意义就在于 Angular 比之 Ember 更加灵活。好比说 Data Store 这一层，你可以很容易实现一套自己的，基于 ngResource，甚至是 $httpProvider，在加上 Cache 层就基本上等同于 Ember Data 了；就算你懒得或不会，也有很多第三方的实现拿来就用。而 Ember 呢？虽然也有第三方的实现，但都不如 Ember Data（or eventually）。再比如说 Router，ngRouter 不够好，但是没关系不用就是了（ngRouter 是独立的组件可以直接替换掉），换成——比如说 ui-router 或其他的什么。但是 Ember 呢？你能很轻易的把 Router 从中间扣掉换成别的吗？

当然，这只是举例说明 Angular 作为 Toolset 而不是 Framework 的灵活性，倒不是说 Angular 就一定比 Ember 强。拿 Router 层来说，Ember Router 比 Angular 及其第三方的 ui-router 都要好得多；Component 也比 Directive 更加友好（至少个人认为如此，用 WebComponent 做参照物的话，明显 Ember 的实现更胜一筹）灵活的双向绑定（也就是说双向/单向/复杂依赖等等的灵活性和 API 友好性），我也更偏爱 Ember。Angular 直到最近 1.3 才实现了“补丁版”的单向绑定，扩充的语法让人蛋疼……而对于 ES6 的友好性，目前 Ember 也领先于 Angular（Angular 2.0 之后再看）更不用说杀手级的 Ember CLI（Yeoman 比之简直是小儿科）。另外，两者都有皆不如意的地方，比如 View 这一层就难以匹敌风头正劲的 React，然而 Angular 整合 React 却比 Ember 要更简单更方便。

以上，我不觉得非要把 Ember 安排进一个“套路”（比如 MEEN）有什么特别的好处或便利性。Ember 的一体化有机化的系统设计使得它可以很好的，很“均等”的适应各种 Stacks，它本身就有相当完备的“生态系统”。MEEN 比其他的——比如说 Ember + EmberCli + Any Backend API + Any DB——没有任何明显的优势。唯一可说的就是 ALL JavaScript？对于 FullStack Developer 来说，这个重要吗？

一、二、六其实都不难，都有很好用的现成的 gem，看看 Raiscasts 里的相关内容即可。

二、四、五其实都是针对同一类资源（表单）的，难点在于自定义结构的表单，如果你愿意采用基于文档的数据库——比如 MongoDB 之类的，我认为是比较适合你这种应用的。若是基于关系数据库，你就得理清【表单】和【可自定义的表单项/类型】之间的关系，比如四楼提到的方案。

如果这对你来说是个难点（难在并非 Rails 自身的知识点，而是要扩展到软件的设计，对象关系等概念性的知识点），你不妨先从固定规格的表单开始。这样会降低问题的复杂程度（但是也同样降低应用的灵活性），先把固定规格表单的 CRUD 做顺做好，然后尝试扩展它，比如说可以为固定规格的表单添加可变数目的表单项/类型。

当这个功能做出来之后，你就知道如何把过去固定规格的表单变成完全自定义式的表单。对于初学者我更推荐这样做而不是一蹴而就，因为这样能帮你吃透它，而且以后可以很容易的举一反三，类似的应用场景还是蛮多的。

我提一点建议，在我看来完全理解 puer 和 livereload 的区别（尽管在功能上有重合之处并且重合之处还不能完全覆盖 livereload），但是不管你相信与否，能理解这一点的人（特别是前端）比较少。

这就是为什么多数人都会把注意力放在 livereload 上，因为这是所有 puer 提供的特性里面最最容易理解的一项（偏偏这项做得并不算全面，很多 edge cases 都不支持，比如 #1 提到的）

所以我建议你可以稍微跟大家解释一下其他的特性，比如说 request mocking / proxy or as middleware / weinre。并且不要只是几句话概括它们是个啥，而是多少描述一个或几个实际应用的场景，可以解决什么问题，可以带来什么便利等等。

request mocking / proxy or middleware 这两项功能我最近都有在用，但不是通过 puer，而是其他的工具或是自己实现，所以我非常了解它们对前端工程师的意义。比如说 request mocking 可以用于测试（依赖异步请求），也可以用于没有现成 API 可用的时候做 rapid prototyping；proxy or middleware 我主要用来和 API backend 访问，特别是当前后端完全分离的时候，有些情况下你没法去改后端，所以没法实施 CORS，甚至你的应用场景也不支持 CORS，但是本地开发的时候我需要跨域访问，于是我可以受益于代理。

或许它们还有其他的好处，但我所用的差不多就这些。weinre 我知道是干啥的，但由于我专注于 web，所以还没机会尝试它。如果你能在介绍 puer 的时候把这些东西描述一下，甚至能录个 demo 那就更好了。这样大家才不至于把大部分的注意力都放在（其实最弱的）livereload 功能上去——实际上若只为 livereload，我个人绝不会选择 pure，一来不够强大，二来作为前端开发反正 grunt/gulp/broccoli……这些我总要用一样的，这些东西用熟了，有没有 pure 对我来说区别不大（至少你提到的这些功能，基本上都有对应的插件可以实现，而且这些插件都是 do one thing，do it well）

#1 楼 @debugger 纯前端的人爱死了呀，想自己做个东西却找不到人帮做 API。

#1 楼 @jiyinyiyong 牵头来搞一下文档吧，我看了一下 Github 上的 fork，有一个建议：不要直接在英文文档上翻译，否则 upstream 更新以后全都变成冲突了。拷贝一份再翻译，发布的时候更换一下文档目标就是了。

按照规范里的定义，<h1> 里面可以放大部分 inline element，比如在你你的例子里 <span> 就是可以的。

但是 <a> 是一个例外，尽管所有的浏览器里它都是默认行内元素。如果标题同是也是超文本链接，则应该把 <a> 放置在 <h1> 的外部。

不过呢，从这里也就看出 HTML 的容错性有多强了，或者说各浏览器有多宽松。

我感觉你还是先选 Android 吧，Ruby 的理由明显不够实际。

按住 command 点击链接就是了。

#11 楼 @leopku 嗯，nbg 组合挺不错，但是 yeoman 我不太感冒，更喜欢自己架构一套。不知道你用不用 ember，ember-cli 比 yeoman 酷多了，基于 nbb 的（npm／bower／broccoli），不过它刚起步没多久，还需要时间去完善。

#2 楼 @lyfi2003 我说的分离就是完全分离成两个项目，使用 API 通信，弃用 Assets Pipeline。前端用自己的一套构建工具。

关于 Webpack 你谈到的两点，的确都有重合之处，但是 Webpack 不是那么简单的东西，可能你没有做过很大规模很重的前端开发吧，angular 并非一切，assets pipeline 对于现代前端开发也并非最理想的构建工具。就那你说的 DI 举例，angular 的 DI 是它自己内部的一套机制，但是大型的项目除了 angular 就能完全不用别的啦？其他的组件一样要考虑 dependencies management，要考虑版本控制／更新，要考虑自动化构建等等。Ruby 的 gems 可以有 bundler 来管理版本依赖等问题，前端的东西怎么搞？总不能样样都是直接 copy 进来吧？当然你也可以直接把 npm/bower/grunt 这一套直接整合进 rails 项目架构里，但是那样太乱了，项目一大就会让人头疼。再比如要使用 ES6 的新特性，assetspipeline 现在能做这个转换不？我不知道哦，angular 可是就要进入 v2，全面使用 ES6，但是在 ES6 普及之前，它还是要依赖前端做一个 transpiler，你要真想大而全，那就还得搞个 gem wrapper。

总而言之，前端开发现在已经有了一整套完善的生态系统，DHH 坚持的那一套不是不行，但总之还是落后了，未来的趋势必然是完全分离。backend 就是 backend，frontend 就是 frontend，何必非要掺合在一起？分开以后 backend 也就不需要负责 view 那一层了，大家都清爽。

当然了，以上都是基于使用 angular／ember 这样的完备的前端框架的前提，目前来说如果要自己整合一套完备的前端框架，倒是可以利用比较成熟的 assets pipeline，因为 grunt/gulp 之类的东西还是有很多 bootstrap 的繁琐工作要做，不过它们也在进化。ember-cli 是一个很好的例子，使用了 broccoli 做构建工具（类似 assets pipeline），整个就是一个 rails 翻版，npm <=> gem，bower <=> bundler，broccoli <=> assets pipeline，grunt/gulp <=> rake，生态完备，但是更适合前端。angular 也有类似的生态系统，不过目前还没有 ember-cli 这么出色的，yeoman 大概算一个吧。这些都是新生事物，但是它们代表着未来。

如果要用到 Angular／Ember 这种量级的框架，我就不选择整合进 Rails 了，而是直接分离，这样最爽。 不过最近有一个新出的东西，好像叫 Webpack 吧如果没记错的话，挺酷的，貌似可以让整合变得很爽。

看你的截图我怎么觉得你没有吧分辨率调整对？你现在是不是处于镜像模式，2414 其实显示的是和你的笔记本同样的分辨率？你要关闭镜像模式，让 2414 自动调整它的分辨率。详见你的 系统偏好设置 => 显示

#58 楼 @Peter 呃。。。为啥非得是外语系的？

Vim

#56 楼 @cqcn1991 我只是随口那么一说，真要搞的话那就不是一句“来吧”就够了。

哪里慢了，不觉得啊，我这翻着墙（美服）都是秒开

#3 楼 @cqcn1991 因为会学习的人只需要有人总结讲解就够了，练习难道还需要手把手么？

逐句评价，对事不对人，如有冒犯多包涵。

我们公司是做云端开发协作平台的，拥有 github 功能

这话不能随便说，不懂的人忽悠了没用，懂的人听见你说 拥有 Github 功能 就准备把你拉黑名单了。为啥呢？不是有个基于 Git 的代码托管就可以叫做 Github 了，事实上 Github 从来都没把代码托管作为他们的核心价值，Github 的许多真正有价值的点都是为了开源项目的协作而量身定做的，而这些开源项目才是 Github 的真正推动力量。

举个例子，Github 的 Pull Request 功能，有哪一家敢说做到有他家一半好的？而 PR 对于开源项目的跨时间地域协作管理的重要性有多高你知不知道呢？你家就没有吧？如果我说错了请指正，至少现在帮助文档里都没见关于 PR 的只言片语。

免费托管公私有项目。。。所有功能免费意味着我们不盈利~

所有功能免费并非意味着不能盈利，而私有项目收费也并非意味着就是为了去盈利。其实强调自己不盈利对客户来说并不会树立什么特别的优势，反而如果是收费还有大量人使用才真的让人打心眼里觉得踏实。

若是为了博取一个好名声，这个入手点其实不怎么好，换个路子说不定效果更好，随便头脑风暴一下：

1. 每家山寨 Github 的服务商都在显著位置上标明了一大堆的合作伙伴，它们都是一些知名企业或者大集团公司。然而目前为止没听说有哪家在里面大规模进驻，开源一些知名项目的。如果你们获取某一（几）家的支持，联手搞一个迄今为止国内最具影响力的开源项目会如何？不用太偏门太难的，就像 Bootstrap 这种的，我知道国内有水平搞个开源 CSS 框架的人绝不在少数，关键是没人推动，宣传，还有鼓励。

2. 国内的软件从业人员基数绝不小，但是平均水平就不算高了，离开学校以后的技能教育是其中很重要的影响因素。如果 1. 觉得搞不起来，那么挑一些知名开源项目，然后召集大家来做文档翻译、教程编撰及相关的发布和推广又如何？反正要打着免费的旗号，不如来搞点免费职业培训，项目托管那块儿收费也没什么的，名声在外了嘛。其实各种个人、小团体做相关翻译的非常多，但都是自发的，缺乏鼓励和推动，也缺乏宣传和推广，都憋在自己的小圈子里了，做这个功劳不小。

3. 如果 2. 也觉得做不起，那就再实际一点。你看 Github 为了推广 Git 都做了哪些事？比如推了一个明星布道师 Zach Holman，Github 用户少有不知道他的吧？他在世界各地到处布道宣传也是加分不少，推一群人没能力推一个人总不是问题了吧？再比如联合 CodeSchool 制作的两套高质量免费视频教程，这个上 CodeSchool 就能看得到。还有 YouTube Channel 里一大堆的 talks 和 tutorials。这些 Bonus 一样是免费提供给用户的，我觉得带来的影响力比免费私有仓库大多了。一个最典型的例子，Bitbucket 可不是小作坊了吧，可是免费私有仓库又能怎样？（当然了，人家的主要生存渠道还是企业客户，这个对他们来说还是毛毛雨）

思维发散一下还有很多，比如楼上有人提到深入大学了，那 OK，大学的 Git 普及教育可以入手吧？你想让师生利用你们的服务管理教学材料，那不能卡在 Git 本身上呀。

质量检测，一键部署，轻量社交元素都有，目标就是让程序员打开个网站就能完成工作。

这些个卖点，怎么说呢？我先问一句，这都是自己实现的吗？我个人觉得实现这几个有点得不偿失，先不说具体实现的效果如何，非要拿 Github 比的话，人家是提供服务接口让你把自己的代码和各种第三方的服务直接对接使用，只看可选择性也比你们大的多了，再加上哪些第三方服务基本上都是专门干这一行的，不管哪一点的专业性上你们都没啥绝对优势吧？

至于轻量社交元素，我到真心希望能有不错的效果，可惜我自己就是个社交迟钝患者，所以没啥想法。

让程序员打开个网站就能完成工作这个就当口号喊喊吧，目前就连 Github 也不做此奢求。你抽一天的功夫啥都不敢，就找你们公司水平最高的程序员，观察一下他一天之内做了哪些事情，用了哪些工具，你看看能满足不能。

但问题是，大家还是习惯 github , 甚至说我们是山寨版... 知名度小

呃，这个不是问题，是事实，承认山寨 Github 其实不丢人，如果人家直接拿你家和 Github 比你应该开心才对，若是那你家和别的山寨比还觉得不如人家你再委屈也来得及。

但更深的想法就不太了解了，有木有人可以告诉我怎么样才能吸引你们呢？

其实你没必要去了解程序员能干什么或喜欢干什么，因为程序员也是多种多样的，并没有定数。我觉得倒是应该反过来去了解下程序员最不能干什么，最怕干什么，最缺什么之类的说不定还有奇效（卧槽，我怎么觉得答案昭然若揭呢……）

你看，搞个开源程序员婚恋项目怎么样，女的负责 issue，男的负责 commit，PR 接受的直接线下约见……捂脸而退

做的很用心，好评！

“差强人意”是“大体上能使人满意”的意思，表达有误哦。

以前好像是最新在首页的吧，后来就改了，原因也记不太清楚了。实际上对于老会员来讲，应该都不怎么看首页的吧？比方说我是直接访问最新创建的，首页难得看一回。

或许把首页一分为二好一些，新建左边，精华右边这样子。

#6 楼 @emanon 说的是插座咯

行尾两个空格实现的换行对应的是 <br />，我觉得非常合理。因为很显然你不能用单一字符来代表 <br />，而重复的多个字符还有比两个空格更简单，更少干扰的吗？

从写作的角度考虑，<br /> 用来换行是特殊情况，大部分时候我们需要的不是换行（属于同一段落的东西就一直写下去好了，具体的呈现——比如说一段文字每一行不应该超过 80 个字符——则应该由 CSS 来控制）。真正需要作者敲下回车的时候，往往是要分段的时候，也就是需要用 <p> 的时候。这一点 Markdown 已经实现了的，考虑到在纯文本编辑器里并没有段间距这么一种设置，所以就用两次回车来区分段落，解析的时候会自动转换为 <p> 标签。

顺便一提，我看过你写的很多东西，你自己的习惯是写一句断一行写一句断一行，所以 Markdown 的 处理方式显然是你不能忍的。可是你有没有想过这其实是你自己的问题？我们从小学习写作的时候都不是你这种写法，无论古今中外不外如是。

#6 楼 @xiaocui Ember 是一个应用级别的框架，它不是一个库（好比 jQuery），也不是一个插件（好比 jQuery 的各种插件），它是用来创造整体化的并且更适合规模较大的应用程序的框架。框架是什么概念？那就好比 Ruby 的 Rails 框架，只不过 Ember 是用在前端的，Rails 是用在后端的而已。

因此你的问题很难回答，因为你问的是错误的。如果要回答“这个技术可以用在前端的哪些功能点”这个问题，那答案只能是：任何一个功能点都可以。

但是这个答案并不意味着前端方面只用 Ember 就够了。Ember 作为框架，它提供给你的是一个基础，涵盖了现代 Web App 所需要的一切基本功能支持，比如数据绑定（单向／双向）、状态控制和管理（路由）、视图抽象化（components 等）等等；另外作为一个框架，它当然还要负责应用逻辑分层和代码组织管理等基本功能（想想 Rails 里对应的概念）

具体到你要实现的功能，你可以只用 Ember，然后手写 Javascript 代码来实现（如果功能不太复杂的话）；你也可以应用第三方的代码库，比如 jQuery 及其插件们（如果功能复杂的话）。还有其他各种各样的前端相关的功能特性都可以实施在 Ember 应用程序上（所谓 Ember 应用程序，就是指基于 Ember 框架开发的应用程序，可以是 Web，也可以是 Mobile），比如 WebSocket，各种 HTML5 API 等等都可以。

所以你的答案就是任何功能点都可以用在 Ember 应用内（注意，是“用在”，而不是“用”）。我觉得你的疑惑根源在于你把 Ember 看做了像 jQuery 或者 jQuery 插件这样的具有特定功能指向的库，然而 Ember 可不是这么简单的东西，它是框架，在抽象层面上要比库高的多，同样它可以覆盖的应用范围也广的多。

不否认 1024 的影响力和流行程度，但是把这玩意当招聘口号实在是太没节操了吧……

试试看这个，命令行下输入：

defaults write org.vim.MacVim MMUseInlineIm 0

#30 楼 @dave 改过之后多说两句，也不是为了解释什么，就是跟你说一下选择那种方式说话的原因。实际上我对楼主没有任何敌意，也没有轻视的念头，但为什么我回复的语气比较“阴阳怪调”呢？那是因为我从楼主的字里行间读出了一种“潜意识”（当然是我过分敏感了吧），我觉得楼主在做他的研究的时候有种先入为主的念头，那就是“Gemset 对于 RVM 来说是一个鸡肋／败笔”，我觉得这种做学问的态度是不对的，比不做学问还可怕，因为你胡说八道大家都看得出来，一笑置之就罢；但若你长篇累牍，一般人就看不出问题所在，很容易被你误导。最近一段时间因为工作的原因遇到了一些类似的人和事情，生了很大的气，所以魔由心生，不觉得就有些代入感过强了。

当然了，我说话的态度更是不对的，如你所说：若有错误指出来便是，不应在言语上令人难堪，否则也不足以服人，更不要说服众。此后关于 ./bin 追加给 $PATH 的讨论就能侧面反映出这一点，我自己由于很小心所以没有出过什么岔子，但是其他人说的不安全之处更加值得注意，我已经改掉了自己的习惯，也很感谢大家让我涨了这个见识。由此可见学问处处皆可见，莫因先知笑后觉。再次感谢你的提醒，总的来说社区对我是相当宽容的，Ruby 并非我的最强项，但我偶然的发言却也总能得到大家的肯定和鼓励，想想我也的确应该更加柔和厚重，才是一个回报的态度，兄弟的当头棒喝真的很及时，谢在心里不多废话了。