如果能出来个工具,把现有的 Rails 项目自动转成 PHP 代码,然后跑在 Laravel 上就更赞了!
我 100% 相信你发布的资源对大家非常有价值,可能会受到很多人的追捧,但是这是侵权行为,必须阻止,我移除了你的这两本书的下载链接。
不知道其他家的 Podcast,如果放到 UPYun 上怎么添加这个 Content-Disposition
的 header,我自己一直都是用 iTunes 订阅。
不知道大家有没有翻看自己用的 Gem 的源码的习惯?
小白的时候,我总是喜欢通过找 Gem 来解决各种需求,后来一个项目上三五十个,甚至百八十个 gems 都有... 项目后期,尤其是升级的时候苦不堪言。
长期经验总结下来,除非某个 gem 能够完美的匹配你的需求,或多或少都有可能引入新的问题。后来我也是通过 http://www.ruby-toolbox.com 来找 gem,但是除非万不得已,我尽量不引入一个外部 gem,至少也要跟同事们讨论一下是不是一定有引入某个 gem 的必要。
在引入新的 Gem 之前,我一般会自己大致过一遍源码,因为通常 Gem 的 Readme 只介绍如何使用,不会介绍 Gem 的内部原理,或者实现方法,更不会告诉你有没有什么坑之类的。翻看一个 Gem 的源码,通常十几分钟,半个小时,至多不超过一小时就可以做到心中有数,用不用就更有把握了。
有的时候甚至不必要真的引入一个 Gem,自己从 Gem 中抽离一段代码,然后简单封装一下反而更契合自己的需求,而且也更加环保。有的时候 Gem 的实现太过复杂晦涩,总有一天会找你的麻烦,比如 Devise 这个东西,看似强大,实则应该能避免就尽量避免使用...... 后话了。
#13 楼 @nagae_memooff 如果不上传头像,很难在社区中建立个人影响力和声望。
应该规定,必须超过 140 字,才能发布跟 LongMail 相关的帖子。
可以向 @jasl 取经,问问他是如何没有毕业就已经在创业,甚至在休学期间还给大家搞了一场 RubyConf China 技术大会,然后定一个清晰的目标:把我们这些前人全部拍死在沙滩上即可。
#40 楼 @jxs471494539 在 Gemfile 中删除 Ruby 版本相关得配置。
#37 楼 @turingbook 看了一下,主要性能提升得地方在于 Rails startup 时间,就 Rails 处理请求效率提升有限。记得从 1.8.7 到 1.9.3,Ruby 性能大幅提升,但是 Rails 得性能提升也很有限,归结于 Rails 得性能瓶颈并不完全来自语言效率本身。
#9 楼 @chukonghr 现在不是招聘得好时候,除非许以高薪厚职,且可以年后上班。
哇,虚惊一场!刚刚我一直在心里盘算,我们已经在多个客户项目上以及生产环境用上了 MongoDB,所以一直捏着一把汗,原来是这样,辛苦了 @huacnlee !
估计这两天会陆续又各种细致的评测,分析放出来。
已经用上了。
#3 楼 @hellokitty 嗯,现在能看懂了,但是没有这方面的经验,期待其他同学能回答你的问题。
#2 楼 @yukihiro_matz メリークリスマス
如果按照计划,今天应该能够迎来 Ruby 2.1.0 最新版本,期待!
#7 楼 @ryudoawaru 太好了,我在 Twitter 上看到了消息,支持! RubyConf Tw 的官网是不是还未上线?