用户数少、招人难是个很严重的问题，稍微的人员变动就会带来很大的影响。像其它语言一个招聘发出去就会有一大堆的熟手来应聘。

另外其它语言的框架通过这十多年的学习和借鉴，Rails 的优势逐渐变得很小了。优势的消失导致像性能、人才储备这些之前可以忍受的问题凸显。

经常在交互过程中 key，iv 给的是一个字符串，使用中需要转 16 进制值，pack h* 试一下。

哈哈，看到各位的回复真是汗颜啊，@liwei78 说的对的确是欠缺考虑了。

#7 楼 @jjfujj 没那么夸张啦，我那简历写的确实很差。

#1 楼 @fighterleslie 谢谢指正. #2 楼 @cloudqq

昨天找到了个以前的简历，加了最后两段，就有错误啦 :)

应该给出 server 端的代码才能判断。

感觉得应该是写的长度不够，而 server 端需要读取指定长度的数据而阻塞了，所以 #3 的 read 超时了。当然如果 server 端用 EOF 判断的话就不大对啦。

而且你给的那个 c 的 write 也感觉奇怪。如果 char_array 做为数组用的话 sizeof 不应该-1（或者应该是上方有个变量保存实际数据大小），如果做为字符串用的话应该用 strlen

#3 楼 @hardywu “人终究是消耗品”

#2 楼 @ken "不过操盘整个国家的人并不关心单个个体过得好不好"

#22 楼 @rei 虽然没用过 AWS 但是听说过这类方式。 我们还和做集成、大数据方面的伙伴公司测试过 Openstack 啊，DigitalOcean 等服务商的动态创建之类的方案。小公司为了存活下去还是很看重成本控制的。 所以有的压力大的就模块重写了。

#4 楼 @swachian "语言太慢绝对是瓶颈" 非常赞同。

正常情况下在 8 时-22 时配置合理的硬件系统可以运行良好，但在某些情景下比如秒杀、比如群发或推送后的 10 分钟内流量洪峰来的时候，” 语言的性能 “就成为巨大的瓶颈了。由于语言的限制即使做了极致的优化，可能效果还是不如一个新手用性能更好的语言做实现的。

硬件可能很便宜，云服务器扩展也很方便，对于大公司来说可能有无数的解决方案（比如 kaminari 作者所在公司那种动态启停几百个节点的做法），但对于很多小公司来说可能并不便宜，实现也并不简单；对于很多客户来说并不愿意为了你的实现多投入那么多的资源。

最开始看到 15 分钟写 Weblog 实现的时候惊艳我的是 scaffold(代码生成）以及 ActiveRecord，后来是语言的特性和活跃的社区（丰富的插件）。现在我仍然喜爱，我们有的产品也还 完全 在用 Ruby/Rails，也更明白了其实无论什么语言和框架，最终以合适的代价创造出有价值的 东西 才是最重要的。

赞。

#1 楼 @msg7086 #2 楼 @billy

上面的代码只是为了方便说明举例写的，方法里面还有 #...... 表示更多逻辑哦。

实际代码中当然不是有意要这么写，但是 在 class methods（scope）里面调用的关于当前 model 的方法 (Relation) 中均会包含 scope 之前的 where 条件。