读了一下免费的第三章……其实基本上没什么可读的，因为整章几乎就是把 MDN 抄了一遍，如果替换几个 literal string 加上翻译几句话也能算作“著书”的话，现在出书的成本可也太低了些。

为了自己好，请出版社把你写书的精华作为试读部分放出来，以免别人喷你言之无物，毫无己见。

免费半年……

还是我推荐一个吧，秒杀所有同类：https://raindrop.io/

I split my time between Ruby, JavaScript (mostly with TypeScript) and Rust, with occasional Java and devops work. Of those, JavaScript (with TypeScript) is my predominant language at the moment, but the mix changes pretty often. Skylight's stack is Rust and Ruby for the agent, Rails for the backend, Java for our data processing pipeline (essentially a custom data store) and Ember for virtually the entire front end. The graphs in Skylight are Ember components written in d3.

I still think that Rails is a great choice for most web apps, since (to this day) it provides an extremely productive baseline for building account management and working with third-party integrations, which turn out to be a surprising percentage of the total code (and an even higher percentage of backend code changes) in even an ambitious project like Skylight.

I also think it's reasonable to use something like Java or Rust for any heavy data-crunching your app might do, but I think people overestimate which aspects of their application are truly performance and efficiency critical.

-- Yehuda Katz, talking about his language chosen in routine work

另外，Cargo 其实已经超出了依赖管理的范畴了，它应该是一种工作流程管理器（WorkFlow Tool）。它之所以好，是因为设计伊始就从更高的角度来审视 Rust 程序员的日常工作流程，而依赖管理仅仅是其中的一个环节而已。最近出现的语言中，比如 Elixir 的 mix 也是类似的理念和设计，不过 Elixir 更年轻，还有一些地方需要向 Rust 学习的。

关于 Cargo 的设计理念，Yehuda 有专门撰文介绍：https://blog.rust-lang.org/2016/05/05/cargo-pillars.html

@darkbaby123 没准儿楼主是打算设计一门博采众长的语言，所以在做调研呢。

@posee 纯 vim 并非不够，具体要取决于你想做多少事。你自己也说了是“编辑器”，编辑器有编辑器的 scope，IDE 有 IDE 的 scope，你非要指望编辑器能完全代替 IDE，那编辑器也就成了 IDE。

我过去一直用 vim 的时候并不觉得 vim 不够用，后来用 emacs 的确感受到了很多新的东西，但这并不意味着 vim 不够用（可能会有一些事情有了更多的用法选择，孰好孰坏这是一个 sense 的问题），现在常用 vscode，是因为它在编辑器的基础上，智能分析做的丝毫不弱于 IDE（typescript 或 javascript，其他语言我用的不多），但编辑代码我依然用的是 vim 的操作。

vscode 的 vim 插件问题并不多，没有什么不能克服的毛病。当然这也和 vimer 的习惯有关系，我曾经也是不装 50+ 的插件就不舒服的人，但现在用 vim 只依赖 surround 和 unimpaire，其他的无所谓，vim 的基本操作已经步入如臂使指的阶段了，你不依赖插件的话基本的 vim mode 是完全够用的。（当然，公平地说对 vim 还原最好的还得是 emacs evil，vscode 的插件相比而言就是一个弟弟）

elixir 成为主流？抱歉，我不关心这种事情。

@posee 编辑器的话其实随便了，vim 和 emacs (spacemacs) 都没有什么问题，我最近用 vscode 也很爽（不怎么写 ruby，主要是 typescript 和 elixir），IDE 的话 rubymine 也不错。

这种问题其实是没有普适的答案的，自己多试试吧，总是需要适合自己的才是最好的。

但是按道理来说，终端应该会自动载入啊

来描述一下你原话中的“道理”是什么，描述清楚了你的问题就解决了。

1. 离开 Rails 的人通常不会否认 Rails 的成熟，真正的动因大多都是因为 Rails（或者说 Ruby）的短板在可见的未来里没有提升的可能（或者可能性微弱，又或者是即使有所改善也就聊胜于无）。

2. 惯例优于配置并不能降低成为“优秀程序员”的门槛，它只能拉高“普通程序员”的底线。对于真正的优秀程序员来说，惯例优于配置是一种“品德”，然而即便身处于“没有惯例”或者“惯例崩坏”的场合，优秀的程序员依然优秀，而普通的程序员则会原形毕露，坠入深渊。如果一个普通的程序员可以进化成优秀的程序员，那么即便他不知道什么叫“惯例优于配置”也不会阻碍他的进化的。

3. 前后端分离是一种工程实践，而不是一种意识形态；不能理解到这一点的，对它的评价最终也会归于意识形态批判的范畴，变得没有价值可言。

总结：你认为对你合适的，且在今天也确实适合你的，那就是你的选择；至于你怎么看自己的明天，那是你的自由。

Rust 用的是 ace 做的在线编辑器（前端部分），也算是一个老牌云编辑器了。https://github.com/ajaxorg/ace

没啥不可能的，混合范式的 JavaScript 都有借鉴的成品了：https://github.com/poteto/ember-changeset

如果 Rails 想做一样可以做，这大概不是一个能不能或者会不会的问题，而是愿不愿意或者接不接受的问题吧。

真有意思，那请问如果你英语学得很不错那又能怎样呢？难道会对你有害处吗？今天你搞不定 man 的文档，找到了 tldr 来帮你简化它，可明天你遇到 tldr 没有覆盖到的文档呢？tldr 的条目其实很多也是其他人贡献的，你觉得这些贡献者会看不懂原始文档吗？

这个项目的目的是为了让查阅命令的用法变得更加方便，而不是为了取代 man。这原本是一件锦上添花的事情。什么叫锦上添花？就是有了会很好，但是没有也不妨碍罢了。如果你本身英语就过硬的话，有没有这个锦上添花又有什么关系呢？更重要的是锦上添花并不能替代事物的本源，举个例子，看这个问题的答案：https://segmentfault.com/q/1010000000430426 你试试看只用 tldr 查出来的文档能不能回答这么清楚？我也不是闲的没事干天天把文档当小说看，这些都是因为工作中遇到了实际的问题而不得不深入文档才得到的答案。

在你的原帖里，问题的关键是你有没有主动去寻找答案，而不是你寻找的答案是不是足够简易到让你能看懂，这是两个性质不同的问题。如果你只是想要更加方便的工具来帮你看懂，那我相信大家会给你推荐各种辅助工具的，比如你自己提到的这个，或者是这个：https://www.explainshell.com/ 等等。可问题是你原文是那个意思？不，你不是在寻求帮助，你是在抱怨。

我跟你无仇无怨，并不会专门为了挤兑你而说你英语不过关。仅就个人而言，你英语过不过关对我来说又能怎么样呢？你埋怨别人说话冷漠刻薄，那我还觉得你不识好歹呢？就这个帖子而言，我其实根本没必要回复这些，若是你觉得我斤斤计较，小肚鸡肠，那便随你吧，言尽于此了。

很感兴趣现在有多少前端有开发 dapp 的经验的，好招不？

在这里说的是爬虫，又不是 DOM Manipulation，除了选择器语法之外，你还指望 Nokogiri 哪里要做到和 jQuery 一样呢？

早在 2011 年，我第一次尝试 nokogiri 的时候就感叹：“我擦，这玩意儿用起来感觉和 jQuery 一样……”，结果到今天还能看到你抱怨没人封装一个 jQuery 选择语法的。可见之前我对你的评论并没有任何偏颇。

什么是 SPA？Single Page Application 其核心特点就是通过浏览器提供的 History API（或 fallback 到 hash）来实现非重载且能够持久状态的路由系统，从而达到只需要加载一个静态 HTML 页面就可以作出不限数量的“页面”（确切地说是“视图”）的应用形态。只要能够满足这种形态的，无论其是否是分离架构，也无论其使用了什么框架（或者完全不用框架），更无论其使用的视图渲染技术……它们都是 SPA。

再说虚拟 DOM，这已经快被说烂了还要被拿来继续嚼。首先，用不用虚拟 DOM 跟是不是 SPA 没有丝毫关系！其次，虚拟 DOM 的诞生不是为了比传统操作 DOM 快（尽管很多场景下它的确比传统方式快，不过这个“快”的幅度是要取决于实现的人的），而是为了给越来越复杂的客户端状态管理与视图渲染的同步问题找到一个新的解决方案。如果你认为像 QQ 邮箱的状态管理就能称之为“复杂”，那你得是多没有见识？不要因为那些初心者总是拿框架搞点博客和 Todo 就觉得这些框架就是用来干这些事情的。

虚拟 dom 是只要一个元素变化，整个区域都重新渲染

请不要总是活在几年前，技术总是在进步的，如今的主流渲染机制都能做到精确的节点（DOM NODE）更新了。

不知道你是蠢还是坏，我看到你讲别的技术话题的时候还是有可取之处的，但一说到前端框架和 SPA 就好像跟别人有杀夫夺妻之恨一样。肆意的发泄和传播不尽不实的讯息并不能让你看起来更睿智。就用你说的邮箱来举范例好了，gmail 就是比 QQ 邮箱的状态管理复杂得多的同类应用，而它恰恰就是用了一个 SPA 框架辅以操作 DOM 为视图管理主要机制的框架。若你一定要杠说前者的 UX 没有后者好，那也随你了，本来这就是一个主观性的东西，却拿来评价某种技术的适用性和优缺点，你说是蠢还是坏？

再者说了，就算你这么说鹅厂的人听了也不会给你点赞的，QQ 邮箱不用新的技术栈又不是因为人家不会用或者用不好，而是它的产品形态太稳定了，压根没必要重新实现一遍，让你说的好像同门微信疯狂搞小程序框架就是离经叛道一样。

格局大一点，不甚了解就别总是大放厥词。

hopscotch 和 shades-of-purplt 不都是 theme 么？

加个 -v 给看一下日志详情。

啧啧啧

呵呵呵，令人很有感触的一篇帖子。前段时间我闲着无聊翻我以前的帖子和回复，看到若干年前那些菜到抠脚的文字不禁感慨 Ruby China 几乎就是见证我从开始编程一直到现在的每一步历程。感谢有你 !

我记得 Heroku 是有官方解决方案的，找了一下，果然：https://github.com/heroku/heroku-buildpack-emberjs

这种问题其实没有必要担心，因为升级并且还用这些 gem 的又不止你一个人，如果真的有了问题上游肯定会很快修复的。你担心时间因素那么可以晚一点再升级，但没有必要不敢升级。

@1c7 会经常看，很少说话，因为上面高手众多，很少有没人回答的问题，倒是 slack 里面更活跃一些。

不客气。我想这个就是你了吧：https://discuss.emberjs.com/t/what-is-the-correct-way-organize-css-file-with-ember-js/14547

因为你是定制 Discourse，所以你可以选择的余地并不算太灵活，尽管理论上 discourse 同样可以兼容绝大部分的 ember addons，但由于它本身就是一个足够庞大而复杂并且有着很长开发历史和相对多的约定的项目，所以如果你选择一些东西最终的结果恐怕你会给自己找麻烦。

我举个例子好了，如果抛开 Discourse 不谈，一般的 ember 项目想要实现 component scoped css，可以使用 ember-css-modules，这个就是解决你问题的最佳方案。并且它是一个通用的标准（而不是 ember 特有的），背后还有丰富的 postcss 生态支持。但是它不适合和 discourse 整合，因为 css modules 对于样式的编写（特别是 local classname / global classname）有特殊的约定，如果你把它用在 discourse 里，那么你需要改写 discourse 原本的样式（主要是转换类名成为 local or global scoped），这个工作量太庞大了，得不偿失。

至于说 Discourse 自己是怎么组织样式（避免命名冲突），我本人并不是特别了解，因为我没有定制过 discourse。我大概扫了一眼现在它的样式，也没什么特别的，就是自己做的一些命名约定而已，不是什么特别 fancy 的方案，但足够简单。按照 discourse 的架构设计，你要怎么组织 css 其实是绝对自由的，随便你怎么做都好。只要你把样式放在 styles 目录下，你可以自由做目录结构的划分和组织，反正最终会被 bundle 成一个样式文件而已；至于命名冲突，没有特殊的机制来管理，就靠你自己形成约定了。

回过头来再次抛开 discourse 不谈，单说 general ember app，可用的样式处理的方案实在是太多，难以一言蔽之，建议你参考 https://emberobserver.com/categories/styles，里面列举的很全了。

Copy & Paste 教学？

除了一些特种职业（比如无脑打字员……），双拼相较于全拼所带来的速度上的提升几乎为零，即使是带有辅助码的双拼方案也不会带来质的变化。这是因为我们日常的打字是有节奏变化的，经常是打几个字停下来想一想，想妥了继续写，写得不好还要回头去修改，双拼所带来的效率提升并不会把整个过程的耗时缩减。

但是说到效率那是很明显的差别。双拼无论什么拼音的组合都是两次击键，加上辅助码最多四击（算上间接辅助码）；而全拼即使输入法可以猜测一些简化的拼音输入也做不到这么高效率的输入。

希望大家能明白提升效率和提高速度是两码事。我打个比方，弹吉他的时候我过去养成的习惯导致我摁某些把位的小七减五和弦效率比较低，形象的形容就是手指变换的方式有很多冗余的部分，这就是效率低下（因为我达到同样的结果要比习惯好的人多花一些肌肉控制的努力），但这并不代表我转换这些和弦的速度比别人慢。速度是一个熟能生巧的事情，就算你用的不是最高效的办法，但只要你持之以恒一样可以达到非常高的速度（别较真，除非你要争取世界纪录，那是另外一回事）。

再比如说我们现在惯用的 qwert 键盘布局理论上用手效率也不如其他的一些布局方案，但这并不妨碍很多人打出超人一般的速度。所以如果你想知道自己换双拼之后会不会提高打字速度，那答案其实是：这跟输入法无关，跟你自己有关。

@xhj6 完全赞同你在本帖说的大部分内容，但不认同你说的：

全栈营竭泽而渔的事实非常明显，对 Ruby 社区的伤害也特别大，但至今不见社区的活跃人士（包括管理员们）出来评论两句。

因为这两年来，社区里关于此培训营的话题并不算少，我仅凭印象大概也能忆起：

1. 最开始发招生贴的时候，那时候大家都不清楚这事究竟含金量几何，再加上主办人具有的知名度和交游广度/深度，大家也不便于唱反调；但就授课内容和收费来讲已经有很多人点出“不值”了。

2. 第一期结束之后，有部分学员就来发 promotion，在里面就展示过所谓“培训成果”，当时就被很多人喷得生活不能自理了，主要聚焦于所谓“全栈”的噱头和最后的实际效果上吧。
   话说到这里插一句，作为成年人吧有时候说话总是会用点技巧，就算心里清楚那边是什么货色，但一来和自己没有直接利益关系，二来人在江湖留一面日后好相见，又没有深仇大恨，不至于“路见不平就拔刀相助”非要跟人家怼到死不可。我这么说你能理解吧？那么在此基础之上，我已经见到不少人旁敲侧击的指出这个事情的问题了；我相信脑子清楚一点的后来都打消了一头扎进去的念头，但问题别人的良心不会因为这个而变好，招生的渠道也不止这一家。在过去几年漫长的时间里，该说的能说的我认为大家其实都说到了。并且后来也有仁人义士专门发帖抨击过，这在上面几楼已经有人告诉过你了。

3. 消停了一段时间，又冒头了出来几个代表性的帖子，主要都是埋怨为什么找不上工作或是应聘不顺利的，并且这些人都是此营培训出来的，这些帖子差不多也就是今年年内的事情吧，你往回翻翻应该还能看得到。在这些里面，你所说的活跃人士们已经不仅仅是评论全栈营了，而是真正的担负起了“课外教育”的职责，不断的把全栈营没教授的或者乱教授的东西进行补充和修正，而这些额外的努力并没有赚取过一分钱。

基于此，我是看不懂今天你站在这里指责活跃人士们没有“评论几句”有什么站得住脚的理由？更何况你的指责还并非事实。我能理解你的愤恨之情，但貌似你怪罪的打击面有点广啊，这是万万要不得的。

我知道这么做不好，不过你可以先试试，满意了再买……

https://www.macbed.com/navicat-premium-12-0-13/

话说这个问题你还要继续追问我，那你的自我驱动能力是不是有点捉急啊？

举个例子好了，你上网搜教程（不管什么框架／工具）大抵都是教你怎么用，在学会用的同时有没有想过：这个是怎么实现的呢？于是主动去翻翻源码也好，上 SO 提问题询问也罢，总之这都是在单纯学习之上的深入探索。

去解决一些实际的问题，做一些学习之上的研究。学习固然重要且终生受用，但也不能一直处于被动学习的状态。另外，不要和别人比，要找到自己的目标和节奏；如果你之前没有什么基础，那么仅仅学了一年 Ruby 根本算不上什么积累，你所艳羡的那些人哪个不是拥有五年十年实际开发工作经验的？做好自己，每天进步一点就好，日积月累，持之以恒。