09 年入坑至今，好巧，也是 14

，天天打飞的往返成都，机票报销不

先 mark 一下^_^

如果是兼职，20K 还是阔以喔，最近又穷又闲。

crystal 出 1.0 了，确实也是个不错的选择，就是需要少许的学习成本，国内偏小众，生产用得少，不好招人呀。

直接放主机就又回归到之前的 mina/cap 状态了。 可以把 Rails 替换成 Rack、把 Rails 里面的通用验签逻辑前置到 Openresty 里面试试看

好的，谢谢

商汤早有耳闻，成都商汤在兴隆湖边上，可惜成都商汤好像不招 Ruby。

Ruby：我可以打10个
Golang：。。。
Java：。。。

其实快与慢，与硬件、带宽、DB、业务逻辑复杂度、是否有同步外部调用等其他因素息息相关，不用一味追求快。 易开发、迭代、维护，系统资源占用少，易扩展就好。

三方依赖少，不用担心因依赖重大版本变更带来的 breaking changes， 也不用去排查某 gem 包的内存泄漏， 也不用引入什么，puma_worker_killer, unicorn-worker-killer 一类的，因为内存基本不会涨。

没有用框架，单一服务，少量 API 直接用的 Rack + Sequel + Puma 撸，线上已稳定运行大几百天

必示科技，AIOps，查到了

弱弱地求下公司名

好早之前面过，接待小姐姐很美

阿里，腾讯，梦网，亿美，大汉三通，欣易辰，创蓝，你要哪家？

“谁让你们用 Ruby？这语言就是慢，我一个自动化专业都懂这个道理。”

自动化专业，11 年 + ruby 路过。

面 ruby，给套 c++ 的题，做完，然后开面，才发现是面 ruby 的，有木有同样遭遇的？

通常招聘贴，都要晒妹纸，敢问贵司单身妹纸可有？

不知道是不是你想要的结果

`xxx` 命令行执行的结果貌似没有 nil，顶多是空字符串''

没有测试环境，所以没法一一验证代码的准确性。

`/bin/stty size 2>/dev/null`.split.yield_self { |_, width|
  width || `/usr/bin/tput cols 2>/dev/null`.split[0] || 80
}.to_i

另：xx.yield_self 仅限 Ruby 2.5.0 以上

喔，懂了，可能设计思路不太相同。

其实你已经有了数据库的持久化形式了，在 job 的运行过程中，也对整个流程做了步进日志的记录，你可以不用再去访问 job 的状态，前端展示只需要轮询持久化之后的结果就可以了。

Sidekiq 的 API 通过 job_id 寻找这个 job 是非常低效的，这在前文已经说过

我不是很明白，为什么会有通过一个 jid 去寻找 job 的需求

each_slice 多核问题

是不是可以考虑将 50 万数据，each_slice 成 50 份或者是 100 份，enqueue 至 sidekiq，然后利用多进程 sidekiq 来跑多核，我并没有要将 50 万数据扔一个 job 里面跑的意思。我指是的你可以用 each_slice 来将数据分片，然后批量创建 job。

job_id 生成是有成本的

跟第 3 一样，既然明知是一个很耗时的方法，我们何必非要让 push_bulk(items) 一次跑 10 万个，我们将数据切片打散成多个 job 也是可以的。

1、sidekiq 平民版支持一次批量插入成千上万的 job，可以用 Sidekiq::Client.push_bulk(items) 这个方法来生成待执行的任务；源码和注释见： https://github.com/mperham/sidekiq/blob/master/lib/sidekiq/client.rb#L135 https://github.com/mperham/sidekiq/blob/master/lib/sidekiq/client.rb#L92

这个方法同样也返回了所有生成 job 的 jid，效率如何需要自测。

2、关于失败 job 的提示信息记录或者是执行过程全记录，可用第 1 步生成的 jid 数组来自由发挥，选择适合自身项目的一种即可。 方法有很多种，比如照原来的方式存 mysql，步步更新。

3、对于需求 3. 批量导出 50 万大促信息，ruby 本身即有一个对大数据的分批方法：each_slice，文档见： http://ruby-doc.org/core-2.5.1/Enumerable.html#method-i-each_slice

可将这 50 万，按 10_000 或者更多分为一批，做一些简单拼凑然后导出，降低数据库或其他数据源的查询压力，最后将结果拼装成一个 excel 或者是你们想要的其他的数据导出格式即可。

临时想到的一些平时用过的方式，也不知道是否符合你们项目的胃口，有说得不恰当的地方请不要笑话。

容我先细细看下你们的思路先^_^

对 sidekiq 的研究还是比较深入，这一点不可否认，点 N 个赞。

过一年再来回头来看今天你们这个设计，可能会发现其实还可以走另外的设计方式。具体怎么设计，我并没有细看，所以不发表意见。

拖家带口不容易呀，我其实也想放飞自我，出川看看祖国的大好河山。

消灭 0 回复，福利待遇目测都不错哟，可惜不在成都

rubocop 其实是不建议用 x.times.map / x.times.collect 这种用法的，可以看这里：

https://github.com/bbatsov/rubocop/blob/master/lib/rubocop/cop/performance/times_map.rb

会有这样的提示出现： Use Array.new with a block instead of .times.collect.

写 0.upto(arr.size - 1) 纯粹是为了容易看懂，一般情况下，都是用 Array.new(arr.size)