少年，是时候辞职走一波西藏了

用 octokit 直接调 github 的 api，不用写爬虫

#4 楼 @lithium4010 这样的话，岂不是一张不漏？看来是时候坚定我转行鉴黄师的职业规划了，参与上面的人工复审。让这些不堪入目的破东西远离广大善良群众，我来承受这些心灵的污染吧。来吧，向我开炮，我不入地狱谁入地狱。

我只想知道怎么去找到剩下的那 0.3% 视频链接

https://github.com/bbatsov/ruby-style-guide

对方没有不尊重你，只不过相互是路人而已

哈哈 支持 一定来围观

有的时候，采用前端渲染是为了复用一套多端公用的 api

#2 楼 @941112341 http://guides.rubyonrails.org/autoloading_and_reloading_constants.html 你就听 rei 说的，把文档看一遍吧

College 这个 const rails 会去自动找所有 autoload 目录下的 zjsu/college.rb 并加载进来，你没有这个文件

所以不要把多个 model 写一个文件里，rails 下类名和文件名要一致。

能不能先搞个 ruby 的

#16 楼 @zhong_sw 哈哈 同

前端正处在从原始的 jquery 脚本时代迈向框架时代的大跃进里，许多原来写单页脚本的前端从思维方式上还没有完成这样的转换。

很多习惯了写单页脚本的前端目前缺乏的不是某个代码规范，而是工程化的思维模式。

以前写单页脚本的时候，脚本由单个人维护，不会掺杂一些比较复杂的逻辑，不同页面的脚本之间基本没有什么关联。

在这种情况下，只要能够快速完成开发需求，就足够了。

但是在目前的框架时代，你个人编写的组件是嵌入在整个前端项目里，而不是某个单独的 html 文件。

衍伸出来的问题就是组件和整个框架的联系、组件的复用性和组件之间的相互关联，重前端的情况下更多的业务逻辑和它们之间的耦合会迫使系统复杂复成倍增加。

每一次的改动都要考虑到这次改动和整体之间的关联，即使只是开发部分组件，也需要对整个系统有足够的了解。你一个单独组件里的错误，很可能会使整个应用挂掉。

之前面试过不少前端，发现现在前端确实很难招（当然可能是因为我们公司对好的前端缺乏吸引力）。

大多数问 js 的作用域、this 的指向和原型链的委托机制这些基础的语言特性都答不上来。对于框架，也很少能够有把组件的生命周期讲清楚的。

原来在单页脚本时代，遇到问题，可以随便找个方法绕过去，然后再回到舒适区。可是框架时代这样就不行了，不把整个系统都吃透是不行的。

这个过程是痛苦的，但是是必要的，各个公司也要有耐心给前端时间去完成这样的转变。

同事有搭 Cloud Foundry，自己用的话太重。

这个好轻量，很适合自己搭着玩。

特别是写 API wrapper 的时候，挖 json 数据用起来很爽

#7 楼 @Canmel 2.3 以前可以用 active_support 里的 try，之前 rubymine 没有更新以前老是提示语法错误，还是用回了 try

用 turbolink 了吗？

我会去卖内存

http://stackoverflow.com/questions/436411/where-is-the-best-place-to-put-script-tags-in-html-markup

要说服 PM 给自己一点重构的时间，会减少后面项目迭代的时间。

豪华阵容

看照片 matz 完美融入你们的团队

#2 楼 @yingce 直接用 ubuntu 也不错的。。。

#15 楼 @ericguo 哈哈，一脸幸福的女儿奴啊

#6 楼 @yingce 没有实际用过微服务，不是很了解。我想应该就是像楼上说的，当项目需要的动态路由、参数检查、权限控制复杂度很高的情况下，再抽象出一层服务来单独做这些事情比较合适。

#7 楼 @realwol 很有道理

#2 楼 @novtopro 见过所有的 api 请求全部先进同一个 controller 进行一些处理，然后再 redirect_to 到相应的 controller，感觉没有你这个办法好。

先活到 35 岁再说，到时候你面临的主要问题可能并不是要不要转管理。

你用过后端的框架，自然觉得前端框架也没用什么特别吧。但是你从手写 jquery 转到数据绑定 dom 自动更新，爽快感就来了。