大的知识框架看 guide 或者书（比如滑板书 AWDWR）。具体的细节查 API 文档：https://api.rubyonrails.org 或者 https://apidock.com

其实如果写代码时有职责划分的意识的话，代码写着写着你可能会突然发现：我正在写/准备写的这些代码应该是谁谁谁的职责。如果是 Rails 的，就去 Rails 的 API 里翻一翻。如果是 Ruby 的，就翻 Ruby 的 API。如果属于用到的第三方库或者框架，就去翻相应的 API。找到了就直接用，实在找不着就继续自己写。

09 年左右环境好，有公司招 Ruby，也有人找 Ruby 职位，无论是职位还是人才，数量都在增加。现在似乎是恶性循环，企业找不到人，换语言；新人找不到工作，换语言。

其实我觉得在一个本就小众的编程语言社区宣传其它编程语言，带走不少人，对这个社区伤害挺大。

说回正题，之前搞 Java，搞了 3 年。当时在研究所谓的贫血模型、充血模型这些概念，一直不太能理解。我看 JavaEye 上面几位前辈说 Rails 天然充血，就买了本 Ruby 镐头书回来啃，想从 Rails 这边借鉴一下思想。只是没想到一下被 array.find{|x| .... } 这样简单的代码吸引了，然后辞职回家买了几本书，学 Ruby, Linux, HTML/CSS/JavaScript。过程中认识了 @hooopo ，时常交流。然后 2010 年 2 月他给我介绍了份工作，就这样开始了。

这么吓人… 不行注册个 1000 元的公司好了

我做了个个人工具，隐藏在子域名里。首页就是个静态页面。

前端作为接口使用者，在接口设计上没有话语权，就这样。

五笔和表形码，差不多都是这个思路吧。

kimi 可以。而且 AI 的翻译相对比较准确流畅。

看样子要学着 Java 来搞各种“层”，培养照猫画虎工程师。

它已经告诉你答案了。

现在连换一门语言写都能被叫作重构了。

TDD 感觉更像一种设计手段，强迫你写出容易测试（易用）的接口。

文中对“为什么要测试驱动开发”的回答，其实只是在回答“为什么要写测试”。

另外测试不是重构的前提，没有测试也可以重构。

最后多数人嘴里所谓的“重构”其实不是重构，重构其实都是些很小步很细碎的代码移动、提炼等等操作。重构严格按步骤来的话，本身完全不改变程序逻辑，原来逻辑是错的重构后还是错的，原来是对的还是对的，所以其实也就无所谓测试。

还有写不出来 10 行以内的简单方法可能也容易依赖这些特性吧。毕竟代码写得复杂，脑容量就不够了。

一直 Vim + NERDTree

最近也在被强迫使用 TypeScript。Ruby 和 JavaScript 用久了，总觉得 强类型（被博客带歪了） 静态类型提供的那些约束本该是程序员自己的意识，主动思考还是被动思考的差别罢了。

我觉得程序员写代码时的思维应该是主动的、清醒的、活跃的，而不是被动的、怠惰的。

另外，没看明白什么叫“不能正确处理代码接口”？

等你刚问完、讨论完、开完会，他们会问你“快开发好了吧”。

Struts 1 默认用的 .do，不过这个其实 Servlet 都可以随意配置，改成 .html 都行。

另一条路子：独立开发，爱用啥用啥。

读书人的事，能算偷么？别在意这些细节。

根据本帖讨论的内容搜到一个帖子：http://129.226.226.195/post/24983.html 为什么将 Python 用于高性能/科学计算（而不是 Ruby）？

不过读着像是机翻。

这套方法似乎必须依赖 SCSS 来实现是吗

原来如此。

我之前拿 JSON:API (有点类似 GraphQL) 对比了一下传统 API. 我不知道自己有没有理解错，跟大家交流一下。我感觉这种方式几乎是直接把后端的模型暴露给了前端，前端在知道后端的模型之后，可以直接根据规范针对已知的模型进行种种操作，包括但不限于：按属性排序、按属性过滤、列表、分页、查看详情、删除、更新等。如果再定义了模型间的关系（比如 has many comments），还可以通过 side loading 和 side posting 的方式对模型及其相关联的模型同时进行查询和修改，可以自由控制数据的粒度，似乎也省掉了很多前后端沟通。这样基本上弱化了后端的功能，后端直接退化成了一个对象数据库。

跟传统 API 的区别在于，传统 API 返回的某些字段可能是后端计算之后返回的，JSON 结构也可能跟后端模型不完全一致。如果直接返回原始模型给前端，这样的计算工作会被放到前端，一些业务逻辑也都往前端移了，最终的结果是前端计算量和代码工程量都变大。而一个项目中，前端可能有很多种实现，比如 HTML, Android, iOS 等，这些前端的工作量都跟着变大的话，感觉不是很划算。我没有在项目中使用 JSON:API 和 GraphQL 的实战经验，这只是我在粗略了解 JSON:API 之后的一些推测，不知道实际情况是不是这样。

“确保后端返回的 json 和前端 ts 里的 json 是相同类型的”不是太理解。在我看来 API 是个契约，它一变动，前后端都得跟着作调整，你的意思是把这个前后端开发者协调的过程给省掉吗？不太明白是打算解决什么问题。

你说的这些 REST 的缺点，JSON:API 似乎都补上了。

大公司的人，是不一样。

类似这种帖子我总想问一句：然后呢

福州居然有用 Ruby 的

母语和英文还是两回事的。当然，也不排除你的英文达到母语水平。

如果 1 楼的方法能行，用浏览器能下载只是用命令行 curl 访问不了，说明你是翻过去的。

这样的话装个 proxychains 再配置一下，然后 proxychains curl -k -sSL https://get.rvm.io | bash -s stable