修改整个 history,不知道 136 位 forks 能不能情绪稳定……
我这里手工测试是产品和运营做的,但他们是关注用户体验方面的东西
http://gembundler.com/rationale.html#setting-up-your-application-to-use-bundler
打开 config/application.rb
if defined?(Bundler)
Bundler.require *Rails.groups(:assets => %w(production development test))
end
gem 的查找跟 LOAD_PATH 有关
现在 weibo 用的 oauth2 是简单很多,我连 gem 都不用了,用 rest-client,认证过程就两行。希望 oauth 的也赶紧迁移到 oauth2。
看 github 程序员的文章知道了这个东西 http://tomdoc.org/
如果 ruby-china 要走鼓励二次开发的道路,加上注释是好的。
去翻看了几个 model 文件,觉得都太简单了,不用注释了吧。
解决了
找到问题了,content-type 少了 charset,现在加上
bundle install --deployment
我业余时间是不敢再捣鼓国内的认证了
用上以后腰不酸了腿不痛了
PS:楼主弄个头像吧
#21 楼 @hlcfan view 里面的 cache 指 Fragment Cache,是粒度小比较灵活的 cache。Page cache 是框架内粒度最大的 cache,没有走过滤器和控制器。
可以抽时间看一下 http://guides.rubyonrails.org/caching_with_rails.html
看看 Gemfile
不要 sudo 看看
上上周末想从 haml 迁移 slim,有转换器转换代码很容易,不过装了 vim 的 slim 语法高亮插件之后有点卡,所以暂缓了。大家有这个问题吗?
haml or slim
把 ids 存在 User 端,查询收藏用户快 把 ids 存在 Tweet 端,查询用户收藏的 Tweet 快 两边都放,两个查询都快,不要用 mongoid 的 has_and_belongs_to_many 查询,它用了 in 查询,自己写一个能利用索引的查询。
其实量大的是 Tweet 量,收藏量我觉得不会大,新浪围脖的名人转发量也就千到万级吧。
mongodb 单文档上限 16m,一个 id 24byte
16 * 1024 * 1024 / 24 = 699,050.666667 =~ 70 万
如果收藏量真的达到这个级别,建议放在 User 端,查询的时候就不要查库了,直接拿用户的 favorite_tweet_ids 分页按 id 取 Tweet,每个 Tweet 都做个内存缓存。
以上说的没经过实践。
假设楼主用 mongodb:
把关联 ID 存在关联少的那端,不使用 has_and_belongs_to_many。双向关联都很巨大的情况很少见(或者楼主给个例子?)。