# encoding: utf-8
require'sinatra'

get "/" do
  "123"
  return "789"
  "456"
end

你自己有没有尝试过 return?

@luikore 辞早了!!!

#13 楼 @hooopo 学名：小耳犬吻蝠

除了 Gollum, 似乎没有别的软件可以支持 Github Flavored Markdown. 这个才是着急的地方。

#19 楼 @sunfmin 今天 @yedingding 主讲，你踢他的我没意见.. 哈哈！

#17 楼 @sunfmin 哈，领导必须来科普 Go 啊！

世纪末最后一次 Ruby Thursday 必须到齐啊。

#44 楼 @hhuai 让 vagrant 内的 vm 使用外部网络。然后把 vm 的端口映射出来就好了。

主要是设置 virtualbox 的网络连接方式。

#41 楼 @hhuai 是的，手动启动。

可以的。这个你查看 virtualbox 的端口映射就好了。

#39 楼 @hhuai 这个除了改善我们的网络环境别无他法..

#37 楼 @hhuai 这个镜像好老了.. 我应该把他移除掉了。

你现在可以用 https://github.com/gitlabhq/gitlab-vagrant-vm 来跑一下，所有环境就都有了。

选 1 吧，能做这个做好也挺不错的。

我们现在直接放在 Gitlab 里面，安全又方便。不需要做特别的 Gem Host.

银行的算法是：只要是我欠你的钱 (利息), 就断尾。你欠我的钱 (贷款), 就进位。

就辟谣...

#29 楼 @luikore 丢不丢是一部分。能不能跟现实匹配是另一部分..

即使精确到后面四位小数，取不出来钱什么都是白搭。最终还是得 round. 貌似银行都是直接断尾，不四舍五入。

ps: bigdecimal 比直接整数加减可慢多了...

#26 楼 @woaigithub 一般保证金额是分就好了。

真的要做抽成这种，不得不损失精度，来解决现实与计算结果不匹配的情况。那就晚做。

#24 楼 @woaigithub 最后包一次。但是这个解决不了问题。因为钱是没有分以下的。

最终还是得 round.

#20 楼 @woaigithub 不一定。有些系统真的是用 BigDecimal 搞的。

但是整数结算是能解决大部分问题的。

#19 楼 @woaigithub 看你卖什么东西。如果是什么 氰 X 钾 什么的话那结算单位就不一样。

卖西瓜肯定不会出现毫克。

#17 楼 @woaigithub 抽税是这样的，你不可能抽到分以下的。

所以你还是必须选择，或者四舍五入。或者断尾.. 百分比抽税是比较难对账的。

#14 楼 @woaigithub 你给我一个这样的场景来..

一般意义上的商品都是不可分割的。没人会说我要 58.12 个什么东西。

如果你是卖切糕的。那另当别论。

你的系统就应该设计成按克来结算，而不是按斤。这样才不会出现说我要 58.12 斤的切糕的情况。

#10 楼 @woaigithub 算钱基本就是这么算的，后台全部以分结算。

难道不是：

[1] pry(main)> (190 + 1899)/100.0
=> 20.89

#6 楼 @luikore spellbreak !!!

估计到时 Ruby 2.0 出来了，Refinements 应该不会被推荐使用。

http://zachholman.com/talk/how-to-build-a-github zachholman 是我最喜欢的开发者之一，这是他的关于 build github 的介绍。

Grit 提供了非常多的周边小功能。有些非常好使..

Github 使用 Rugged 的方式以后会在这个上面再封装一层。http://zachholman.com/talk/how-to-build-a-github 叫做 GitRPC, 这一层下面是 Rugged. 会不会再增加新的方法不知道。

以你现在的需求来说，用 Grit 就行了，Github 迁移的主要原因是 性能。

你陷入了 RESTful 的 URL design 的误区。

下面那种才是对的.. 不是说有 query string 就不 RESTful.

中午就指着这张图提神了.. :D