嗯嗯，的确是这样。 我觉得中级就已经有能力在框架方面做一些集成和扩展了，不过 Rails 源代码的确难懂。

stackoverflow...

好熟悉的地方...

顺便问下，这个中级和高级，是如何区分的呢？

尝试过防弹咖啡，效果很明显。 但是……我是个喜欢做料理的人，我做出来的美味自己却不吃？这简直天理难容...

1. RubyChina 相当活跃，这一点是如何看出来的？（我个人感觉社区已经远没有以前那么活跃了）
2. 掘金、SF 没有 RubyChina 做得好，这一点是如何看出来的？

erb 不需要刻意学吧…

是我一激动没说清楚。。

我本来是想说，MySQL 里单表存这么多数据，查询效率会非常低；MySQL 一般到千万级就可以做分表了。

分库分表很简单，技术上就是典型的分库分表。

但这只是手段而已。

分库分表的目的，是为了扩大尚未冷却的数据的承载量，比如你单表 800w 数据量达到性能瓶颈、同时业务要扩大发展，那么分库分表就可以承载到 4000w 的数据量（数字是我估计的，意在表示量级）。

处理冷热数据，最关键的是从业务上界定冷热边界，也就是在业务里划清界限；业务的思路理清楚后，根据需求，把冷数据从业务系统里迁出来就是了，至于存储细节，冷数据要怎么存、怎么用，也是需求决定的（如果完全没用，是不是可以扔掉，嗯，当然这么爽的办法现实中几乎不可能，所以就意淫一下）。

处理冷热数据分离，难点在于界定冷热边界后的工程。有些代码实现，一开始没考虑那么多，现在就需要考虑了，这些代码分散在工程里，到处都是，你得一条一条拆，也有可能需要在 ORM 框架层面动手脚（比如做个 Proxy 之类的）。

至于 TIBD，我没有使用过，所以无法推荐（或不推荐），不过楼主的确可以一试。而且，上亿级数据放在 MySQL 里，会死。

不为什么

以我有限的开发经验来看，Python 中显然存在用于用户登录的包，但没有 Devise 这么复杂（何况 Python 源码的易读性和可修改性要远大于 Ruby）。

我离开郑州后，郑州的 Ruby 圈发展真是蒸蒸日上啊。

Django 本身的 ORM 也能用么。。。这么烂的东西，用着还不如裸写 SQL 顺手。

补充一点，关于考勤、工作在岗证据，这一点非常重要，但有时候也非常难搞，平常要多留心。

比如，假设我想主张 1.5 倍的加班费，而所在的公司既“不打卡”，也没有正规的加班记录，这个证据就非常非常难搞；而没有这样的细节证据，加班费就没法算。

巧了。。我刚处理完一起劳动纠纷，还不到一周时间，就在 Ruby China 看到这个帖子。

报警了。。。

`ffmpeg -i 1.mp4 -y -f image2 -t 0.001 -s 352x240 a.jpg`

即可

又招啊~

标题里的“RBR”是不是打错了？

平静的生活，都是童话。

提问两点：

1. 招聘名额？
2. 日常工作节奏是怎样的？

最近在考虑换工作．

想了解一下贵司，平常的工作节奏如何？每天的上班时间，加班情况如何？

好呀，我试试～

这两天会比较忙，忙里偷闲整理一下简历之后发给您：）

大佬快发女装照镇楼。

肯定先学 Python... 但实际上，两个都要掌握。

Rails 2.3.5 很古老了... 我没有用过，不过这样子没事就好了~

API，简单点说就是一个 CGI 而已，你这样讲真的没有任何意义。

具体说来，不仅仅是上面各位提到的要看请求的时间分布，还要看业务场景，比如 IO 密集还是计算密集？相同硬件配置在不同业务场景下的表现可比性就很差了，而你什么也不说。

那我只能说，你看 Github 的请求量，我觉得，一定行的通。

看上去和 RPC 如出一辙...

二楼正解。

我记得以前看过一些东西，上面介绍说推荐使用 mysql2（而不是 mysql gem）。

在所见过的项目里用到 MySQL 的也都是用的 mysql2，你换一下试试看吧。

你检查一下前端资源里的引用，这个可能是重复引用或是引用顺序问题。