#5 楼 @azpokr 嗯，heroku run，只能执行单条语句 好吧，毕竟，免费的 能提供这个功能已经很好了 ^0^

If you do not specify a web server in your Procfile, it is likely that you’re running WEBrick in production. If you continue to run WEBrick it is likely that requests will take a long time, possibly timeout, and you will need to use many more dynos than your application requires.

Rather than doing this, ensure you use a production web server.

所以你是用 WEBrick 在跑吗？

建个 Procfile 文件，用 unicorn web: bundle exec unicorn_rails -p 80 -c ./config/unicorn.rb

笔记 http://www.myrailsmap.com:3000/notes/11

UI 屌爆了

#6 楼 @peter 嗯，有道理。准备一个月爬一次，再弄个趋势什么的，根据一个月内新增的 star 数量来排。

#3 楼 @rennyallen 嗯，对的，第 10。之前有个 sinatra 的项目弄错了也算了进来。

#1 楼 @hooopo 哇，果然是的。多谢，这页抓的时候出了点问题，我就自己手工去看是不是 rails 项目，结果看错了。

#6 楼 @feng88724 哈哈，版聊多的话应该是被禁止的吧，而且 gitter 的话以后可以大家一起建个 repo 玩。

#4 楼 @fluagen 哈哈，昨天刚建的

#1 楼 @sean 我试了下我这里没翻墙也可以打开耶，你有瀑布 im 的 id 吗？要不我邀请你进瀑布的频道吧。

#15 楼 @larryzhao

哈哈。看上次 TIOBE 的排名，不算世界上最好的编程语言，应该是 ruby、python 和 nodejs 吧。

三大动态语言里前景最不明朗的一个

2011 年 11 月，nodejs 取代 rails 成为 github 上最火爆项目

Denial 主持地真好，即能够活跃气氛，又能在闪总吐槽以后把重点拉回主题里。薄荷感觉超级低调温柔，估计对老婆也一点很好。Larry 很机智幽默，演讲听起来津津有味。

整个过程基本全程高能，非常感谢活动的举办方和分享者。另外希望 PPT 能够公开一下，方便回忆细节。

ps: 闪总反复吐槽户口问题真的好逗，看来怨念颇深。

和 ZF 打交道的事要问清楚，也许房管局和第三方开发公司是有关联的。你贸然找别人，房管局关系人在项目中没有拿到提成，万一不认可你的系统你怎么办？

确实，rubymine 一个好用的地方就是会自动扫描项目依赖的 gem 代码

除了少数元编程定义的方法，基本都能快速找到方法的源码

aws 免费一年 30G 流量每月 估计你看视频可能不够

#1 楼 @small_fish__ 嗯 全栈的，有内核接口

我觉得像类似像《You Don't Know Js》这样直接上传 md 到 repo 也不错啊，关注的人可以直接 star。

#12 楼 @tkvern 我不知道真正的老玩家是怎么写的，但是碰到特殊需求（比如我想在 will_paginate 中用罗马数字代替阿拉伯数字来表示页数）时。一般的思路是自己调用 will_paginate 的一些 Api，结合一些代码写一个自己的 helper，然后在 view 里用<%= my_will_paginate @posts %>替换原来的 helper 方法。

在能够不用元编程的时候，尽量避免使用它。像上面的例子违背了一个我们在构建程序结构时的原则，即把经常需要变化的代码和不会变动的代码分写在两个不同的容器里。

#11 楼 @455804841 rake 这个 gem 没有正确安装，试试源http://rubygems.org/ 好像没有 SSL 的没有被墙

#5 楼 @455804841 二楼的方法没错，你的错误信息是什么？

#4 楼 @455804841 要改 Gemfile 里的 source，否则只是改了 gem install 时用的源。

https://gems.ruby-china.org/

精彩，签到，回郊区了。楼主真人比照片帅！

#2 楼 @hooopo 嗯，受教了

原来如此

所以一般如果用 offset + limit 方式分批查询，sql 里会包含 offset 而导致查询变慢

SELECT  "articles".* FROM "articles" LIMIT ? OFFSET ?  [["LIMIT", 30], ["OFFSET", 10000]]

而用 find_each 查询时，会直接根据 id 来加快查询速度

SELECT  "articles".* FROM "articles" WHERE ("articles"."id" >= primary_key_offset) ORDER BY "articles"."id" ASC LIMIT ?  [["LIMIT", 30]]

还是被 python 压了两个身位

如果真能开源又是一个极好的用来学习的项目啊

https://github.com/DarthSim/carrierwave-bombshelter

哇塞，比我的漂亮多了