#9 楼 @ruby_sky 发新帖问吧，搭车问个无关的问题，是从什么地方学来的？天涯？百度？还是猫扑？

GitCafe 的发展，越来越迅猛了！

视频已经发布，具体见这里 http://ruby-china.org/topics/7265

视频已经发布了，具体见这里 http://ruby-china.org/topics/7264

#4 楼 @huacnlee 这个好，支持！

#2 楼 @xiaolong 有头像就好了，有了头像就不是 nobody 了，下面就努力给自己多赚一点社区声望吧。

你想找实习机会的话，应该主动去联系，投递简历。 另外可以多参加社区活动，多发贴问问题或者帮助他人解决问题。

我关心的是，就算你做出来了，你上什么地方去找这么多的用户？

#5 楼 @ihlayy 你说的这些都是关系数据库长久的痛点，可能有一些工具和库，但是好用的，信得过的有没有我不知道，我自己的方案是绕行到 MongoDB 上去。

我有删除回复的权限，所以留下 email 的同学，我会发出邀请，然后就把你们的 mail 删除掉，以防爬虫。

折服，这么通俗易懂的 PPT，太有喜感了！

#226 楼 @machixian 其实邀请码我这里还有一半呢，但是好像 SAE 没有准备好一下子接受这么多的人注册申请试用，我估计他们以为只有很少的人会真的拿着邀请码去注册，所以我被喊停了。

受不了了，全部都是回帖不看帖子的人... 大家都没有看 #182 楼 的通知嘛？ 本次发放优惠码已经结束了，这不是逼迫我去跟 SAE 交涉要更多的优惠码么？

UPDATE: 上传了一个 960x450 得版本，尺寸大了 200MB，但是清晰度改善不少，打算后续视频就按照这个尺寸发布。

关系型数据库在水平扩展上都非常痛苦，不是一句话两句话能说清楚的。

方案一是 MySQL 的复制，一个 Master 数据库，多个 Salve，然后利用 MySQL 的异步复制能力实现读写分离，这个方案目前应用比较广泛，但是不怎么好玩。

方案二是 MySQL 的 Sharding 策略，很不巧的是 MySQL 在设计之初就没有考虑过很好的支持自动 Sharding。特别是构建一个自动基于应用的数据分区和负载均衡，以及单点故障处理等等，用 MySQL 实现 Sharding 的话，Sharding 逻辑在你的应用内手动实现的并维护，要手动 Sharding 非常不容易，而且规划好避免每个单机 MySQL 实例的负载过重，以及不同 Sharding 中的数据迁移相当费事，可谓困难重重。这些在后面发展起来的 NoSQL 就处理的很好，比如 MongoDB，甚至自动 Sharding 成了 MongoDB 的核心功能。

帮顶，已经置顶了。

#2 楼 @ihlayy 大部分都在非 Windows 的环境下作开发。

新人千万不要在 Windows 上使用 Ruby on Rails

#13 楼 @poshboytl 用 Final Cut Pro 导出 1080p 的格式好像就这么大。

@jjxp2007 39G 是一个视频的尺寸还是所有视频的尺寸？

#10 楼 @search 高清的有人要哇？Matz 的这个大概 39G。

#5 楼 @gonglexin 会的，不过等我们把事情全部放出来，我们在集中发一个帖子。

当时的暖场效果真的棒极了，Koz 你太可爱了！

如果不嫌折腾，可以试试看这个 https://github.com/ricardochimal/taps Heroku 就是用这个来 push/pull 本地到远程数据库的。

#1 楼 @huacnlee 我也发现了，原版是 1920x1080 拍的，压制成 640x360 后依然要 347MB，在 http://railscast-china.com 上又被缩放到了 960x600，所以看起来有点模糊，不过主要的部分是视频中的 PPT，而不是右下角的人像视频。

#9 楼 @mimosa 12 月 19 日是一个特别得日子？

从第四点到第七点来看，此贴招聘非常靠谱。 建议只有一个，楼主上传个头像吧。

今天来了不少的志愿者，大家回顾了很多东西，气氛非常好。 想来也是年底了，大家都非常忙，今年的 RubyTuesday 系列活动我觉得也差不多可以收官了。 大家年底好好冲刺一下，自己把自己都照顾好，我们来年继续。