大部分中国人的日文程度，到中国生存活下来还是可以的。因为汉字已经够多了。

没有开放只能穿视频给瞅瞅

http://screencast.com/t/JcJDLoYNIP

http://screencast.com/t/AKPQBpfbr1Nr

@luikore 这个工具可好了。多谢当年吕哥贡献超级正则 parser 哈哈。

顶 占哥

谢谢大家对政府的信任。相信他们一定不廉洁

有道理。我觉得上亿肯定有。而且他们估算是全国 6 亿的人口在同一时间使用。所以还需要有很大的冗余。 他们估计这样算的. 1w 的机器 (大批量购置需要便宜点吧) 12000 台 1 万人 2 台应该够了吧，包括 balancing。这样 10000 x 12000 = 120,000,000，balancer 防火墙 估计要几千万了吧，带宽什么的，管理人员每年的工资。开发系统，系统的维护成本。算算也有很多。

我在想这个排队问题。是不是因为定下票和付款之间有一定的间隔，所以需要等待？

#4 楼 @flyerhzm 嗯。是的。

这里有几个时间当从服务器读取页面

• etag 计算
• 页面数据读取
• 页面渲染
• 网络传输

很多时候 etag 计算 已经比较复杂，因为你要遍历一些子元素啥的。

不过还是能够省下以下的时间：

• 页面数据读取
• 页面渲染
• 网络传输

对于服务器大于 2 台的网站来说比较有用，对于小网站来说，开发速度第一啊。有时候加 etag 还不一定效果那么明显。

但是在 rails 里的 action 里写一些

if stale?(:last_modified => @product.updated_at.utc, :etag => @product)

就意义不是超级大。除非渲染页面需要超级久。

PaaS heroku 做的还真的挺好的。

好楼主。人品好啊。

本地编译的还是远程编译的？

选择强的机器编译喽

话说日本的 3G 网络真的不错。我手机分享到电脑上（得越狱）softbank 都屏蔽了 hotspot 功能。然后跟家里 facetime 一点儿都不卡。下载 500K 左右。都不用装宽带了~~尽管这里宽带更快。

@ashchan 占哥电话多少都不告诉我。周末过来找你啊。我房子找了住板桥这里。过来应该挺近的吧。

#39 楼 @ashchan 嗯，来日本不一定日文会好，一定要自己嗷嗷的学习啊。

Air 有一个很大的缺点。就是不能加内存。今天跑去加内存，居然不能加的说。郁闷死了。

用了一天 air 低配。1G 内存的。感觉，开发 Rails 都够用了。当然开发 iOS 就省省了。xcode 多费内存啊。还 iPhone 虚拟机。

如何你在插件里，请别用 slim.

#12 楼 @night_song 顶一下。xcode + obj-c 方便多了。还免费。还支持多。

去看看 macruby 吧。其实写起来更麻烦。很多调用 cocoa 的库你都得转化一下。算了还是写 obj-c 吧。

vagrent + chef 非常好用 :) 我觉得我们在群里可以整一下。把弄好的调试好的 chef 贴出来供大家实用。

我觉得创业加班的几率比较大一点而已。也不是说一定完全都加班。

其实我认为敏捷开发和极限编程，都是基于一点“良好沟通”为啥要客户参与，为啥要 pair。很大程度减少了错误和重复。但是跟加班并不完全是一个事情。

@clc3123 是的，他不是 web server，但是应用程序如果支持多线程，你 web server 才有机会去并发处理多请求。你 web server 多线程，像 Rails 应用，跑一个 instance 怎么跑都只能同时处理一个请求。

两个 sinatra 配置项：

• lock Places a lock around every request, only running processing on request per Ruby process concurrently. Enabled if your app is not thread-safe. Disabled per default.

• threaded If set to true, will tell Thin to use EventMachine.defer for processing the request.

在我心中，宙哥就是 字符达人，吕字达，吕正达，吕 C 达。 忘记 @night_song 晚歌了

@Saito 是的，宙斯哥推荐给我了 charlock_holmes，用了，行了，好使，谢了。

恩。可以读出来。是 Rails 正则处理，以 utf-8 编码去处理。所以你用 File.read("xx", :encoding ..) 就帮你转成 utf-8 了。所以就可以交给 Rails 去做处理了。

我们做过详细的性能比较：

https://github.com/hlxwell/performance_evaluation

最终领导选择了 golang ...

node 和 EM 都是用 c++ 写的 EM 看文档上打算用 c 重写，为了性能和兼容性啥的。但是 EM 的插件真的没有 node 多，支持和社区也没有那么多。写 Rails 的人，JS, Ruby 都熟悉随便哪个都能很快上手。

Erlang 最近学了一下，要写业务逻辑负责的东西，我看还是算了吧，支持的库也没有 Rails 或者 node 多。

但是他的分布式能力和 cpu 多核利用能力天生的。搜索了一圈。erlang 做的最多的就是聊天室了，还有消息服务器。其实就是聊天室的底层的服务。就这样。为通信行业所生的语言。

用 go lang 吧 ;)

@clc3123 告诉你一个不幸的消息 sinatra 是多线程的，前一个请求卡住了后面一个还能请求。

不过有个问题就是，在 ruby 里能够处理的字符串都得是 utf-8 编码的。就是说 File.read("file_path", :encoding => "这个必须设对") 否则根本就读不出来。但是你不知道这个 encoding 你怎么去读出来判断。矛盾了。