nainc (nainc)

[北京] 途家海外事业部招聘 Ruby 工程师 (20K-40K)

nainc — Mon, 12 Mar 2018 11:46:37 +0800

关于途家

途家，全球公寓民宿预订平台，于 2011 年 12 月 1 日正式上线。
作为中国住宿分享的引领者，途家致力于为房户提供丰富、优质、更个性的出行住宿体验，同时也为房东提供高收益且有保障的闲置房屋分享平台。
目前途家已到 D 轮融资，是国内民宿行业的领头者。

关于我们（大鱼自助游）

大鱼自助游已跟途家合并，成立海外事业部，独立负责途家的全部海外业务。
大鱼一直致力于海外民宿行业的探索，有完整的供应链体系，B 端体系。
我们今年的目标是海外预定间夜的 30 倍增长！目前 Q1 的目标已经达成，现招募更多的小伙与我们共同努力。

招聘职位

【Ruby 工程师】

【工作职责】

负责途家网海外事业部各产品线的研发，包括供应链产品、电商交易系统、全球分销体系等
负责技术团队内部的基础架构研发、包括微服务化，持续集成交付、基础云平台等
参与公司和部门级别的技术架构设计，评审与 code review

【任职资格】

大学本科及以上学历，2 年以上开发经验
熟练掌握互联网后端技术架构，熟悉 Ruby 语言，熟练使用 Ruby on Rails 框架进行开发和部署
熟悉常用的数据库及缓存技术的使用和设计，如 Mysql，Mongodb，Redis
对面向对象有深刻的理解，熟悉常用设计模式
熟悉前端技术，包括 HTML、CSS 和 Javascript
具备编写单元测试的良好习惯
具备扎实的计算机基础知识，包括数据结构、常用算法、linux 系统

【加分项】

熟悉 Java，有 Java 系统开发经验（之后大鱼部分业务会用 java 开发，欢迎对 java 感兴趣的小伙伴）
有对于复杂业务系统的架构设计，服务拆分经验

薪资待遇

薪资范围：20K-40K
五险一金，年假，病假，额外孝亲假，餐补，团建等等该有的都有

工作地点及联系方式

大鱼新址位于北京市朝阳区亮马桥路 27 号院内 1903 号大鱼公司（地铁十号线亮马桥站／十四号线东风北桥站步行约 10-15 分钟）
如对以上招聘信息感兴趣，请将简历发送至邮箱：xiaoyiw@tujia.com
更多图片与技术栈可参考之前的招聘贴：https://ruby-china.org/topics/33619

Rails 如何写测试

nainc — Sun, 03 Apr 2016 16:12:59 +0800

本帖只是个人总结的一些实践经验，适用于一些不太会写测试的同学，高手请指教

为什么要写单元测试？

个人总结为以下两点：

现在的测试是为了避免以后的麻烦。当一个功能比较复杂，关系到比较重要的业务或者难以进行黑盒测试的时候，或许在你开发的时候你很有信心，相信这里不会出现 bug。但过了几个月甚至一年，你需要扩展功能或者别人需要接手你的代码时，这就会令人头疼了（尤其是公司没有测试工程师！）。
依赖于第三方服务的功能，比如支付回调，支付平台退款。在本地环境无法以正确的数据调用第三方服务，这时候可以用测试来 mock 返回值，以便进行后续开发。
节约回归测试的时间，每次回归测试都要跑的 case 可以写成单元测试

个人认为，如果开发时间充裕，尽可能的写测试覆盖全部功能。如果时间不够，比如在创业公司，测试最好也能够覆盖 service 和 api

miniTest+fixtures+mocha 的测试框架

minTest: rails 的测试框架
fixtures: 生成测试数据
mocha: 各种 mock 方法的补充

常用的测试方法

详细可见 http://ruby-doc.org/stdlib-2.1.0/libdoc/minitest/rdoc/MiniTest/Expectations.html

判断真假 must_equal 这是最常用的一个测试方法了。

it 'model save must be true' do
  model.save.must_equal true
end
it 'service must return true' do
  service.execute.must_equal true
end

判断一个对象的类型 must_be_kind_of

it 'man must be kind of Human' do
  man = Human.new
  man.must_be_kind_of Human
end

判断一定会抛出异常 must_raise

it 'model must raise error if name is nil' do
  model.name = nil
  model.save.must_raise ValidationError
end

常用的模拟方法

模拟调用 stubs

在写测试的过程中，我们常常会希望某个方法返回我们希望的值，不管它如何执行的，这时可以用 stubs。在下面这段代码中，我们需要测试可以成功申请支付宝退款，而实际代码中，申请支付宝退款是一个 http 请求，没有真实的订单号我们一定会申请失败，所以我们模拟一下它的返回。

class AliPayDrawbackService

  def do_drawback(order)
    if apply(order)
      return order.update_attribute(:state, 1)
    else
      return false
    end
  end

  def apply(order)
    RestClient.post(url, order.id)
  end
end
it 'apply alipay drawback success' do
  #any_instance表示该service的任意实例对象
  AliPayDrawbackService.any_instance.stubs(:apply).returns(true)

  order = Order.first
  service = AliPayDrawbackService.new()
  service.do_drawback
  order.state.must_equal 1 #pass
end

期待调用 expects

某个功能在执行过程中会调用一个其他系统服务，或者某个功能会插入一个任务到异步队列。这是我们需要秉承一个原则：自己的功能自己测。即我不关心其他服务的功能是否正确，我认为只要我成功调用了就是正确的。

#一个消息队列的pusher
class Mq::Publisher
  def self.publish(key, msg = {})
    # push 消息体到队列
  end
end
class Order
  def submit
    # ...业务逻辑
    Mq::Publisher.puhlish('order.submit.success', {xxx})
  end
end

it 'send a message if order submit success' do
  #注意，期待调用的方法一定要写在实际调用前
  #这段代码表示期待Mq::Publisher的publish方法在本测试中至少调用一次，并且第一个参数是"order.submit.success"，any_parameters表示后面的可以是任意参数
  Mq::Publisher.expects(:publish)
  .with("order.submit.success", any_parameters)
  .at_least_once.returns(true)

  order = Order.new
  #xxx
  order.submit
  #如果Mq::Publisher没有调用publish，测试结果会是失败
end

mock 对象

有时某个方法可能会需要一个很复杂的参数，或者某个方法返回的一个结果对象会影响剩余方法的执行，这时我们可以使用 mock

个人总结了两个方法来 mock

使用 Minitest::Mock

def execute
  service_a = ServiceA.new
  ret = service_a.do_something
  if ret.success?
    #xxxx
    return true
  else
    #xxxx
    return false
  end
end

it 'execute must return true if do_something' do
  #创建一个Mock对象，设置它的success?方法返回true
  mock = Minitest::Mock.new
  mock.expect :success?, true
  #设置ServiceA查到任意实例对象调用do_smoething方法返回mock
  ServiceA.any_instance.stubs(:do_smoething).returns(mock)

  execute.must_equal true
end

使用 Class.new

def execute
  service_a = ServiceA.new
  ret = service_a.do_something
  if ret.success?
    #xxxx
    return true
  else
    #xxxx
    return false
  end
end
it 'execute must return true if do_something' do
  mock = Class.new{
          define_method(:success?) { true }
        }.new
  ServiceA.any_instance.stubs(:do_smoething).returns(mock)

  execute.must_equal true
end

##先总结这么多

关于乐观锁的重试

nainc — Fri, 25 Mar 2016 11:19:06 +0800

### 关于乐观锁的重试

锁相关的知识可以参考 @zamia 的这篇文章 https://ruby-china.org/topics/28963

这篇文章算是一点小小的补充

### 如何本地复现乐观锁冲突

在访问量大的线上环境，使用了乐观锁的地方是有可能出现 StaleObjectError 的异常的，本地如何复现呢？这个有个小方法（可能比较 low）

使用 byebug 这个 gem，在锁的事务中加上 byebug 调试，例：

假设这是一个库存的对象，库存比较容易出现抢锁的情况

def unforzen
    self.with_lock do
        byebug
        self.frozen_num -= 1
        self.save!
    end
end

开两个 console，获取两个对象（stock_a 和 stock_b）

调用 stock_a.unforzen，会进入到如下调试模式，可以看到已经进入到事务中了：
然后调用 stock_b.unforzen，跟 a 相同，也进入到了事务，这时将 a 的代码执行完，next 是单步执行，continue 是执行到下一个断点。
执行 b 的代码，这时你会发现 b 的 unforzen 方法抛出了 StaleObjectError 的异常

###准备工作结束，如何重试

值得注意的一点是，reload 需要给参数 lock: true，否则 lock_version 是不会更新的

def unforzen
    optimistic_lock_retry_times = 3
    begin
        self.with_lock do
            byebug
            self.frozen_num -= 1
            self.save!
        end
    rescue ActiveRecord::StaleObjectError => e
        optimistic_lock_retry_times -= 1
        if optimistic_lock_retry_times > 0
            self.reload(lock: true)
            retry
        else
                raise e
        end
    rescue => e
        raise e
    end
end

### 一点疑问

其实实际的代码要比例子复杂一点，这个释放库存的功能是通过一个 service 调用的，异常统一在 service 中处理，但是 service 不能直接获取到出现锁异常的 record，我尝试过 error.record.reload(lock: true)，如下：

rescue ActiveRecord::StaleObjectError => e
    p e.record.lock_version
    e.record.reload(lock: true)
    p e.record.lock_version
    retry
end

发现 lock_version 是变了的，但是重新 retry 的代码中的 record 的 lock_version 还是原来的。这块还没仔细研究原理，懂得同学也可以分享一下~

为什么酷站中没有大鱼自助游了？

nainc — Fri, 19 Feb 2016 13:44:58 +0800

@lgn21st @huacnlee 之前记得大鱼自助游在酷站里的，怎么没有了呢，大鱼的竞品自在客反而在里面，而且自在客貌似是 php 写的吧？？

配置 gitlab-ci 进行持续集成

nainc — Wed, 13 Jan 2016 22:58:39 +0800

在日常工作中，我们经常会写一些单元测试来确保程序可以正确执行，但是写完单元测试后常常会面临这些问题：

有一些小改动懒得跑单元测试
别人改动相关代码影响了你的代码逻辑，但他们不知道你写过这些单元测试或者没有跑单元测试的习惯
项目大了，单元测试很多，跑一遍要花很长时间

这时候可以选择进行持续集成

进行持续集成有很多种方式，介绍一下使用 gitlab-ci 进行持续集成的配置方式。

准备

gitlab 版本升级的很快，公司的 gitlab 是在去年 5 月份安装的，当时的版本还是 7.10，现在已然发布到 8.3 了。建议把 gitlab 升级到 8.0 以上，8.0 以上的版本自动集成了 gitlab-ci 的功能，无需再自己配置一个 gitlab-ci-server 了。google gitlabci 相关的内容很多都是基于 8.0 以上介绍的。并且 gitlab7.12 以上版本支持使用.gitlab-ci.yml 进行 ci 配置，自己搭建 gitlab-ci 的话很容易出现 ci 版本和 gitlab 不一致导致找不到.gitlab-ci.yml 的问题。升级方式就不详细说了，详见https://about.gitlab.com/update/ 公司之前用的 Omnibus gitlab，升级很方便，直接 yum install 就 ok 了，升级前记得备份数据库。

gitlab 开启 build 功能

gitlab 项目下-》Project-Settings-》Features 里的 Builds 选项勾上-》保存-》完事儿开启后会发现菜单多了几个功能，打开 runners，里面有 token 和 url，下面配置 runner 时会用到。

配置 ci-runner

首先安装gitlab-ci-multi-runner，之前有一个 runner 是 gitlab-ci-runner，这个 runner 的代码已经不再维护了，不要装错。
安装完成后启动：gitlab-ci-multi-runner start
注册一个新的 runner：gitlab-cimulti-runner register，提示输入 url 和 token，输入上一步 runners 里的内容就行了，runner 的名字随便输入。然后提示选择 executer，个人选的 shell，还可以选择 docker 和 ssh
完成后刷新 gitlab 的 runner 页面，可以看到刚才注册的 runner

配置 gitlab-workhouse

之前公司没有使用 gitlab 内置的 nginx，而是自己起的 nginx 做配置。这种情况可能导致 build 的时候 git clone 不下代码，会报这个错误： fatal: reference is not a tree google 了一下，建议的解决办法就是使用 gitlab 内置的一个 gitlab_git_http_server，好像是 8.2 之后的版本改名成了 gitlab-workhouse。 /etc/gitlab/gitlab.rb中增加配置：

gitlab_workhorse['listen_network'] = "tcp"
gitlab_workhorse['listen_addr'] = "127.0.0.1:8181"

nginx 增加配置：

upstream gitlab_repo {
   server 127.0.0.1:8181 fail_timeout=0;
   server 127.0.0.1:8181 fail_timeout=0;
}
#gitlab的server配置中增加
location ~* \.(git) {
      proxy_read_timeout      300;
      proxy_connect_timeout   300;
      proxy_redirect          off;

      proxy_set_header   Host              $http_host;
      proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
      proxy_pass http://gitlab_repo;
  }

###.gitlab-ci.yml 配置在项目的根目录下创建.gitlab-ci.yml，下面是跑单元测试的配置，当然还可以干很多别的。

before_script:
    - cp config/database.yml.sample config/database.yml
    - bundle install --path vendor/bundle --without development
    - "bundle exec rake db:create RAILS_ENV=test"
    - "bundle exec rake db:migrate RAILS_ENV=test"
  job1:
    script: 'RAILS_ENV=test rake test:units'

进阶配置请参考文档

到此配置完成，从此之后每一个 push 都会触发 ci 进行 build，提交 Merge quest 后也会有相关 build 结果提示，再也不用担心小伙伴们忘跑单元测试了。

##TODO 其实不需要每个 push 都触发 build 的，希望只在提交 MR 后触发一次 build，在和代码之前看到 build 结果就可以了。还在研究，希望有了解的同学能指点一下。