感觉 Rails 团队好怀念当年拔剑四顾、天下无敌的 Web 开发黄金年代啊，哈哈！

个人认为，如果本身是就是 Web 的内容，将其直接移动化，比如 Ruby China 本来就是一个网站，那么用 Turbolinks 的确非常省事。但如果一门心思的试图以 Web 的技术来适配通用的移动应用场景，那就很不合适了，老虎钳是好用，拧螺帽也不是不得行，但总觉得很有点别扭，对不对。

就好像视频中的问答一样，SQL Lite 支不支持？GPS 支不支持？等等，回答好像我记得都是肯定的，但演讲者似乎对这些场景稍稍感到有点意外，可能没这么真正用过，真正处理起来，绝对有许多坑。

所以最近几年下来，个人感觉对 Rails 团队的固步自封非常失望，越来越失望！开源社区从 Rails 身上已经学到了很多，但 Rails 团队自身却很少离开自己的舒适区，核心成员十几年都待在同一家公司，做着同一件事情。因此，Today I accept that Rails is yesterday’s software（并不太同意这篇文章，但比较接受这个标题描述的事实）。

最后，搭个便车，诚招 Rails 工程师，坐标重庆新牌坊，有意者请联系我，谢谢！

#32 楼 @lips 目前我也尚未发现 bower 的替代品，所以仍然得用。大多人都是 npm 管本地的各种开发依赖包，bower 管打包发布到应用中的各种前端包，完全互不影响！用 npm 来管前端包的话，到至今为止，我并没有找到正确的、简洁易行的使用方式。

至于说使用人数，npm install bower 每天安装的次数达十万次，10000+ 的 star，bower 的优点还是非常明显的，非常非常的简单易用，特别是相对于 sprockets 而言（主要是不会产生什么奇葩错误，哈哈）。

另外，bower 和 webpack, browserify 之类的东西是两回事吧？bower 只是包管理器，和 npm 差不多的。那为什么一个应用要用两个包管理器呢，那是因为 npm 的初衷就是为 node.js 管包的，bower 的初衷就是为前端管包的，能够干掉其中一个当然好，但是明明两者各有所长，为什么非得要只用其中一个呢？至少在我目前的项目中，如果只用 npm 的话当然也是做得到的，就象这篇文章所说的那样整，但是，我为什么不用 bower？毕竟，换个角度思考就是：只要使用 bower，文章中所说的这些步骤和工具都是不需要的，你看文章中为了去掉 bower，提及了好多个三方库？

结论： bower 最大的问题是影响了社区的统一和团结 ，同一种东西，存在两种来源是有点令人感觉不爽。但对于开发者而言，只要要用的包还在，不管是在 bower 中，还是在 npm 中，真的没有什么区别，当然，强迫症患者除外。

#16 楼 @qingxp9 做医疗卫生行业的，我发现你不错，可否丢个联系方式，我们聊聊？

来重庆吧，我要！

#11 楼 @chairy11

对于本问题，@gihnius 的答案是最优解（我提的 reSize 也行，只不过要指定一下宽度，稍显麻烦了一些），具体实现可参考如下代码：

$('a[data-toggle="tab"]').on('shown.bs.tab', function (e) {
  $('.chart', e.relatedTarget).highcharts().reflow();
})

注意以上代码未经测试，不一定可用，但思路应该是这样的，你后面改 CSS 就越走越远了。

另外，你把 js 写入 HTML 中，当然就很丑了啊，js 就应该在 js 文件中，而向传递 formatter 的函数，lazyhighcharts 给出的正确做法是写入 Controller 中（或 Model 中），具体写法见我在 8 楼给出的代码示例。

@jasontang168 @chairy11

就像 @lgn21st 提及的那样，首先看这个选项支不支持类似于 label formatter 那样传入函数：

labels: {
  formatter: %|function(){ return this.value + '#{x_suffix}' }|.js_code
}

但是，非常遗憾，我查了一下 API，好像不支持，那么就只能使用纯 JS 的方式解决问题了。先获取 tab 宽度，然后使用 setSize 这个函数设置宽度就可以了，详情请仔细阅读 API，哈哈！

chart.setSize(chartWidth);

#24 楼 @dddd1919 #25 楼 @moyuanming #27 楼 @kgen

非常感谢，谢谢各位，结帖。

#21 楼 @neutralevil 我的问题是，我其实有这么一笔钱的，但是分期划算，还是一次性付款划算？我还有 40 万的公积金贷款未还，手头也是有钱还的，是还了划算，还是不还划算？

当然，不管划算不划算，现实生活我的做法是坚定不移的，钱捏在手头还是安逸些，没事看看余额也不错啊，哈哈，虽然都是银行的钱。

#20 楼 @moyuanming 谢谢！的确是那篇文章把我误导了。

我有个银行的朋友简单粗暴的给我回复了这两个链接：PMT 和 复利。但是，看了之后我仍然还有一个非常现实的问题：同样的年利率，边存款边还款，然后等到等额本息的贷款到期时，是亏了还是赚了，还是刚好相等？

嗯，又觉得可能原文的算法没有问题，关键是在我上面的计算中，余额宝是按月复利计息计算的（事实上是不是这样的？），所以准确是利率是多少，我也搞不清楚了。

我现在唯一可以确定的是， 不考虑资金的其它用途的情况下 ，如果你有 40 万元的公积金贷款，一定不用先还；而你如果你面临着 24 万元的两年分期，你分期之后把这 22.8 万元拿去存余额宝是不划算的。

继续呼唤金融专家权威解释，谢谢！

#16 楼 @hbin 在这里：http://web.toutiao.com/a3909250550/

@neutralevil 你可以这样对比一下银行分期和等额本息贷款：把这 22.8 万存入余额宝，以 5% 的利率复利计息，两年之后的剩余资金为 -2200 元；而假设某人公积金贷款 40 万元，把这 40 万元存入余额宝，以 4.25% 的利率复利计息，20 年后的剩余资金为 17 万元。由此可知这里的 5% 手续费绝对不等于 5% 的等额本息。

但是，先有资金与后续还款还是不一样的，所以，我也糊涂了，我也觉得原文的算法可能也是有问题的，也许没有这么高吧？哪个是学金融的，出来权威解释一下。

#12 楼 @neutralevil 本金 24 万，先付手续费 1.2 万，相当于实际借得 22.8 万，平均每月 9500，每月需还所谓的『本金』10000 元，实际上这 10000 元中只有 9500 是本金，另外 500 是利息，所以算下来 9.94% 是无误的。

#3 楼 @blacktulip 是的，没理解错，每个月本金 10000 元，利息 500 元。

但由于手续费先付，每个月实际只借得 9500 元，然后利息 500 元，算出来就是 9.94% 了。

#15 楼 @miclle 我开始是用的 ngbp，后来也投入到了 Yeoman 的怀抱，但还是一直用的 Grunt，构建文件写好之后就再也不想动它了，Gulp 再简单也不如我不动啊，哈哈！

#12 楼 @miclle 是的，后来在实施的过程中，发现完全独立的模块化其实也是蛮难的

#6 楼 @seem 真正的 大型应用 应该是模块化的吧，我最初是用的 ngbp 起的步，但现在已经不记得是 ngbp 本身还是我参考了这篇笔记 之后把文件目录结构改成这个样子的

另外，ui-router 应该已经快成标配了，你值得拥有

#4 楼 @miclle 我是这样拆分的：

root │─ app.js │─ common │─│─ services │─│─ directives │─│─ views（HTML） │─ foo │─│─ controllers │─│─ services │─│─ directives │─│─ views（HTML） │─ bar │─│─ controllers │─│─ services │─│─ directives │─│─ views（HTML）

怎么没人响应呢？要说推荐的话，那就是一个字：大！桌面一定要大，屏幕也一定要大，这样写代码才爽！

以上各位都没有提及一个重要的问题，就是『生态系统』。

我目前只用过 AngularJS，但我选择它不是因为它本身有多优秀，而是因为 Ionic，显然上面各位都在大公司，有专门设计师，所以体会不到 Ionic 对于我们这种屌丝公司来讲是多么的给力了。

楼主提及的 4 点中有 3 点我都认为有点故弄玄虚，根本不是问题：你会遇到这些坑，但这些坑与真正的坑相比根本就不是坑，比如打包，['abc', function(abc)] 就完了，谁 TMD 会说好牛 X？这么小的技能点根本就不叫技能点。但第 3 点性能问题我们的确有切肤之痛，在电脑上好好的，终端上就不行了，优化优化再优化，还是令人不太满意，最后，不怕说出来丢人，就是一个字，等！等 ionic 升级了，从 beta 13 等到 beta 14，它优化了一点点性能问题，我们应用的性能问题也就消失了。

因此，我认为未来哪家前端框架更可能胜出，取决于并且只取决于哪一个『生态系统』更加完善，比如说我们，我们的当时的需求是要快速开发一个移动应用，开源、闭源世界中转一圈，发现只有 Sencha 和 Ionic 两种选择，我们当时还没有设计师啊，设计师贵啊，你要我用什么，只能是 Angular 了啊，至于它升不升 2.0，今后兼不兼容，和我现在已经完成的应用有什么关系？现在的应用已经开发完了啊？！

OK，又有新的开发单子了，我又要选型了，我真诚的问一句：据说 React 性能极好，React 之上有类似于 Ionic 这样的框架没有？求推荐！如果有的话，我坚决要去试一试 React，前几个月的性能问题虽然已经解决到可以接受的范围内了，但真的都还有点心有余悸的感觉。

#26 楼 @badboy 谢谢，非常有帮助！

#24 楼 @cqcn1991 我以前和你一样，比较瞧不起 IT 培训班，认为所有的东西自学即可，哪里需要专门参加什么培训班呢？其实接受再教育的形式包括自学但绝不仅限于自学，而且自学绝对不是效率最高的一种方式，花钱节约时间、花钱提高效率、花钱学习自学时有可能永远学不到的实践经验指导，都是很有必要的。过份强调自学而拒绝认可其它学习提高的方式和途径，是一种典型的程序员思维偏见。

而对于企业来讲，对参加过培训班的应聘者也不必另眼相看，不要认为他基础更好，也不要认为他悟性或学习能力更差，只要他拿来就能用，对企业就是有价值的，不预设立场，这样才是公平的。

#19 楼 @quakewang 感谢大神莅临指导，感动得哗哗的 那么我可以是否可以这么认为，请一个国内顶级的讲师成本大约在 6000—10000 元/天左右？这个成本实在是有点高，但应该是物有所值。不过大神也许您可以另一个形式来帮助我，如果我事先把培训框架结构、授课内容和每堂课的教案准备好，然后请您现场来就我的培训内容来指导两天，提供针对培训内容的咨询服务，您愿不愿意，愿意的话大概会收费多少呢？方便的话，回复到我邮箱中也可以：huajian28 & gmail dot com，谢谢！

其他大神们呢？你们的意见呢？咱们的事业不能后继无人啊！要是国内没人用 ruby 了，你们的 ruby 技能不就贬值了么，你好我好大家好，大家好才是真的好啊，再请不吝赐教！

#9 楼 @chenge 才看到您那一楼，好啊，啥时候回来的时候一定通知我，一八六玖六七二七录零录，咱们当面聊聊

#11 楼 @cqcn1991 你这个是典型的程序员思维

#8 楼 @awking 这个的确，我前些天给一位实习生说这个，实习生的第一反应是，『ruby 我知道，那个是日本的...』但是我可以不提 ruby 啊，只提『快速创业技术培训』就可以了，哈哈哈哈……

#5 楼 @springwq 我如果完全以讲师的劳动时间成本来衡量讲课成本可能不太科学，传道授业解惑是高尚的事业，大神们愿不愿意便宜点来布道呢？另外，你在 Tealeaf Academy 花了多少银子？投入了多少时间？收获如何？

@kevin 现在还在这儿没有？可否出来给我一点建议，不是要抢您的生意哈，您是做高端的，我就想把 ruby 搞成 java 和 php 那样草根的，哈哈

#3 楼 @chenge 我自己的资源优势就在于可以把现场培训的成本降到比较低的水平。远程指导的门槛实际也蛮高的，并且很难保证这些学生最终能转化为可用的人力资源，比如他可能会比较难以坚持全时全力的投入

#1 楼 @mingyuan0715 主要是想赚雇主（包括我自己公司）的钱，并不希望招收那种连培训考核都过不了的学生

#2 楼 @springwq 连培训资源门槛都太高了正是制约 Ruby 广泛运用的原因之一。。。能不能预估一下，请一个类似水平的讲师，讲一天大概需要多少钱？

坑不多，我只遇到一个，就是事件重复绑定的问题，后来发现是因为把 js 文件的引用放到了 body 最后面的缘故，把 js 文件移入 head 中就正常了。

不过我现在感觉 turbolinks 有点生不逢时，比如它在我的项目中就只存在了极短的一段时间，一开始没敢用它，用了之后发现这玩意儿还真的有点好用，但很快项目上前端框架了，又只有让它下课了。

@jicheng1014 可否留个联系方式，或者加我马化腾 三五三六零五六四九，我们聊聊？

ruby 社区本来就小，大家还是要珍惜吧，看到后头我有些倾向于同情 国徽 了，以我自己的个性而言，如果我做出来的东西客户没用，我是无论如何都不好意思开口要钱的，但局外人都不清楚事情过程，谁也无法评判谁对谁错。

不管事情真相如何，国徽，你那个图标可以换一下好吗？你的头像，你的删帖，都会让人产生无法相信你的感觉。

楼主在重庆的啊？！果断出来聊聊吧！

咱们把重庆用 ruby 的给聚集起来