我们周五下午开在线会议，互相学习交流，现在正在进行中，呵呵。今天 @poshboytl 给大家分享怎么作 Screencast。

rspec 从开始到现在，已经形成了一整套针对 Controller，Model，Helper，Mailer 等相关的最佳实践和套路了。在团队中，每个功能落实到开发的那个人，应该遵循大家都普遍接受的 rspec 最佳实践/套路来写测试，如果强势的团队甚至必须要求提交的代码必须附带对应的功能测试，大家多互相 Code review 对方的代码和 rspec，团队协作 rspec 方面最大的法宝是沟通，只要多沟通就没有问题了。

推荐 Rspec 的官方文档网站 https://www.relishapp.com/rspec

有更新了，check out! http://37signals.com/svn/posts/3111-basecamp-next-ui-preview

#9 楼 @googya 初学者也欢迎，如果能过来参加活动的话，任何初学的问题，我和其他人都非常愿意帮你找到答案，呵呵。

#1 楼 @hhuai #2 楼 @sunzheng91 看来以后不能让坐沙发的人打击人民群众的积极性哈 ;-)

#1 楼 @sunzheng91 好的，Omniauth +1，还有么？

#4 楼 @hutusi 放心吧，RubyTuesday 以后至少每月都有一到两次，是一个长期的活动。

vividchalk 是一个模拟 TextMate 的配色方案 https://github.com/tpope/vim-vividchalk

#11 楼 @fsword #12 楼 @hooopo 学习了，我开始全面启用 1.9 的时间并不长，不过看起来 Ruby 的字符编码变得很强大了啊，顺便问一下在 Ruby 1.9 下面，怎么 detect 任意文本文件的编码？

我也是建议用双系统，然后尽量强迫自己在 Ubuntu 上完成所有的日常事务，有问题也尽量在 Ubuntu 下面用 Google 解决。当必须要用 Windows 的时候，可以现在 Ubuntu 上用 VirtualBox 虚拟一个 Windows 出来，最后实在不行在切到 windows 上，一段时间后你会发现对 Windows 的依赖越来越小，我自己和很多我认识的朋友都是这么用过来的。

我的 MacVim 不知道为什么，安装插件多了以后就变得非常不稳定容易崩溃，现在基本上不用任何自动补全插件，其他插件也基本上不用，基本上现在就用了一个 Theme 和三个插件：

Bundle 'tpope/vim-vividchalk'
Bundle 'scrooloose/nerdtree'
Bundle 'hallettj/jslint.vim'
Bundle 'kchmck/vim-coffee-script'

毫无疑问 Rails 引入 bufferlog 是为了性能，我直觉既然引入了这个 feature，那么 rails core-team 定会提供一个可以 disabled buffer log 的方法，刚刚找了一下，这里提供一个方法你试试看 http://stackoverflow.com/questions/5947551/how-to-write-flush-the-rails-log-when-the-process-dies

config.logger.auto_flushing = false

#2 楼 @ruby_sky 遇到 Excel 的场景，我都考虑用 csv 文件替代，ruby 读取 csv 文件有 FasterCSV，而 Excel 也可以直接打开 csv 文件，代码优化一下的话，百万条记录的 csv 文件我都操作过，性能不是问题。

#8 楼 @413472212 简单地说，就是首先将要处理的文本文件的字符编码转换成 UTF-8，然后再用 ruby 去读取并 split 操作。

转换的方法有很多，可以通过 ruby 的库，也可以直接用命令行工具，比如 iconv

$ iconv -f GBK -t UTF-8 input.txt > output.txt

#2 楼 @chitsaou 赞同

就像处理时间换算这样的场景，统一将时间先转换程 utc，然后在进行换算。同理，处理任何文本文件之前，现将文件的字符编码转成 utf-8，然后这个世界一下子变得美好了一点点。

这个免费的 Rails 培训的活动太成功了，钓足了大家的胃口。

#2 楼 @_samqiu 原来如此。

谁知道广告里面的女主角到底是谁？我记得 Godaddy 曾经使用过官恩娜作为形象代言呀？

从某种角度上来说，这才是真正的意义上的“会员突破 1k”，大家一起庆祝吧，呵呵。

这个帖子下午被我短暂的屏蔽了几个小时，现在重新恢复。

原因是我对 Gurudigg 和其衍生的一系列活动诸如 0x65 以及 RubyVSPython 的商业目的，最初时候的推广手法和借用社区影响力的方法都不能认同，也从不参与，甚至在 Shanghaionrails 的邮件列表上所有 Mike 的帖子我也一律不予支持，但是我以前一直能保持克制，理性的反对 Gurudigg 相关的所有活动。但是今天下午行使管理员权利直接屏蔽帖子的做法是我反应过激了，我对屏蔽这个主题贴的行为向大家表示歉意。

经过几个非常知心的朋友劝告，我会非常谨慎使用管理员权利，最理想的情况是永远不使用管理员权利去影响任何论坛内容，如果大家感兴趣，那么就会响应，如果大家不感兴趣更无需管理员来屏蔽。

在上海还有不少活动，跟 Mike 碰头的机会很多，下次见到他我会主动找他说清楚。

非常支持，不过看起来 Rabel 和 Ruby-China 非常相像，或者说都能找到 V2ex 的影子，请问 Rabel 开源嘛？

...... @camel you are cheating!

#11 楼 @azhao 建立 ruby-china.org 之初，就是因为身边的，认识的，熟悉的 rubyist，没有一个人是 chinaonrails 的用户啊。

看来大家对这个问题本身的兴趣远远大于解决这个问题的方案啊 :-)

#16 楼 @huacnlee 我不信，呵呵。

建议非常好，只是现在社区的发展方式是一种自由，松散的方式，凭着大家的时间精力投入关注，才让社区有了今天的规模和气氛，你提到的两个建议都需要背后没有一个实际的团队负责运营和维护，才有可能实现，坚持作一两个月，靠兴趣和激情完全没有问题，但是长期坚持靠的是稳定的机制，我同意三楼 @fsword 说的，目前尚不成熟。大家的想法呢？

我走的最多的弯路是每天看大量的各种稀奇古怪的国外博客文章，一有什么新的东西，不管有用没用，一股脑全部用在手上的项目上，耗费了大量时间去追求奇技淫巧，反而忽视了最一些最基础，最本质的东西，以至于耗费了大量的不必要的时间精力反而水平能力长期徘徊不前，长期只是一只东南西北分不清楚的傻菜鸟。。。

“站在巨人的肩膀上才能看得更远”，42 位开源社区杰出贡献者在 Open Advice 一书中讲述他们各自在社区不同领域的经验。感谢 Marguerite Su 提供消息

与其他以往偏重代码的开源社区类书籍不同，本书覆盖的角度十分广泛，包括：

• 概念、创新和研究
• 招募和督导
• 基础构架和代码编写
• 质量保证和支持文档
• 翻译、用户可用性和艺术设计
• 社区管理
• 打包
• 市场宣传，会议组织
• 商业模式、法律和规范。

推荐该书给：

• 不满足通俗媒体报道，深入了解开源社区如何运作的人。
• 希望加入开源社区做贡献，但心有顾虑的人。
• 愿前辈们的经验帮助您更快的了解并融入开源社区。

http://open-advice.org/

#6 楼 @clc3123 很多笑点，而且都比较符合苦逼的程序员文化背景。