バックグラウンドで実行するバッチ処理の改善のためSidekiq Enterpriseを導入しました🥳

こんにちは、エンジニアの森田です。 MedPeerでは、バックグラウンドで非同期に処理を実行させる方法としてSidekiqを使っておりましたが、今回Sidekiq Enterprise(Proを含む)を導入しました。

https://sidekiq.org/products/enterprise.html

今回はSidekiq Enterpriseを導入するにあたって解決したかった課題と実際の導入方法、導入後の活用事例をを紹介できればと思います！

Sidekiq Enterpriseとは?

Sidekiq Enterpriseとは、その名の通りエンタープライズ向けの機能拡張が行われた有料版のSidekiqです。(Sidekiq Enterpriseとは別にSidekiq Proもありますが、Sidekiq Enterpriseを導入するとSidekiq Proの機能も使用出来るようになります。)

ProとEnterpriseそれぞれで主に下記のような拡張がされています。

Sidekiq Pro

• RELIABILITY
• BATCHES

Sidekiq Enterprise

• RATE LIMITING
• PERIODIC JOBS
• ENCRYPTION

詳しい機能の紹介は公式のWikiが充実しているので、興味の有る方はそちらをご確認いただくのが良いかとおもいます。

Home · mperham/sidekiq Wiki · GitHub

Sidekiq Enterprise導入に至った背景

MedPeerではバックグラウンドで実行するバッチ処理にSidekiqを使用しています。サービスの成長に伴い日々Jobは増えていて、100を超えるJob(2020/03/19現在)が実行されています。

+----------------------+--------+--------+---------+---------+-----+-------+
| Name                 |  Lines |    LOC | Classes | Methods | M/C | LOC/M |
+----------------------+--------+--------+---------+---------+-----+-------+
| Jobs                 |   4482 |   3607 |     106 |     500 |   4 |     5 |
+----------------------+--------+--------+---------+---------+-----+-------+

Jobの中には、利用者へのインセンティブ進呈に関わる等、影響が大きいものもありJobにおける処理の信頼性の担保が今まで以上に求められるようになってきました。

またデプロイによるJobへの影響も当時の問題として発生しておりました。 実行完了までに長時間かかるようなJobがあり、デプロイ時のSidekiqのプロセス再起動により実行が中断されるとJobの処理が中断され再実行しても正常に完了できず、毎日運用担当の方からメール配信のスケジュールを共有いただき、エンジニア側でデプロイタイミングがかぶらないように注意するような運用をしていました。。。

このような背景から解決方法を探していたところ弊社技術顧問である前島さんからSidekiq Enterpriseを導入してみてはどうかと提案いただき、導入を検討することとなりました。

結果として上記のような問題は、Sidekiq Enterpriseの導入により解決することが出来ました🎉

Sidekiq Enterpriseの導入方法

ではSidekiq Enterpriseの具体的な導入方法について書いていきます✍

Sidekiq Enterprise申し込み

導入にあたってまずは、Sidekiq Enterpriseの下記のページから申し込みを行います。

https://billing.contribsys.com/sent/new.cgi

金額は100スレッドで月額$179(2020/03/19現在)です。スレッド数が増えていく毎に金額があがっていきます💸

You can use Sidekiq Enterprise with any number of apps and processes and machines as long as their total worker thread count in production is <= the licensed amount. Development and staging environments are free and unlimited. https://github.com/mperham/sidekiq/wiki/Commercial-FAQ

この金額に影響を与えるスレッド数は本番環境で実行されているスレッド数となっているようでstagingやdevelopmentといった本番以外の環境は自由に使うことができます。

申し込みを行うとSidekiq Enterpriseのinstall時の認証に必要なキー情報がメールにて送付されます 📩

Sidekiq Enterpriseのインストール

Sidekiq Enterpriseをアプリケーションに導入する場合は下記のようにGemfileに追記します。

source "https://enterprise.contribsys.com/" do
  gem 'sidekiq-ent'
  gem 'sidekiq-pro'
end

そして下記のようにbundle configまたは環境変数に申込時に受け取った認証用のキー情報を設定します。

export BUNDLE_ENTERPRISE__CONTRIBSYS__COM=foo:bar
# or
bundle config --local enterprise.contribsys.com foo:bar

上記のGemfileと認証用のキー情報の設定が完了したらbundle installを実行することでSidekiq Enterpriseを導入することができます 🎉

※導入したい機能によっては、initializer/sidekiq.rb等で起動時に有効化する必要があるものもございますので、Wikiを読んで導入方法を確認することをおすすめします。

ActiveJobからSidekiq::Wokerへ書き換え

Sidekiq Enterpriseの全ての機能を利用するためにはActiveJobではなくSidekiq::Wokerを使用する必要があります。そのため弊社ではSidekiq Enterpriseの機能を利用したいJobまたは新規のJobについては、ActiveJobではなくSidekiq::Workerをincludeする形式で実装するようにしています。

# before
class MyJob < ApplicationJob
  queue_as :default
  
  def perform(*_args)
    # something logic
  end
end

# after
class MyJob
  include Sidekiq::Worker
  sidekiq_options queue: :default
  
  def perform(*_args)
    # something logic
  end
end

ActiveJobを継承したJobをSidekiq::Workerをincludeする形式に修正するにあたって、引数でActiveRecordのオブジェクトを受けるような形式になっている場合には注意が必要です。

The arguments you pass to perform_async must be composed of simple JSON datatypes: string, integer, float, boolean, null(nil), array and hash. https://github.com/mperham/sidekiq/wiki/Best-Practices#1-make-your-job-parameters-small-and-simple

ActiveJobは良しなに引数のオブジェクトをシリアライズしてくれますが、SidekiqではWikiに記載の通り引数の値をto_sしてRedisにエンキューする都合上、Sidekiq::Workerをincludeしたときのperform_laterに当たるpeform_asyncの引数には単純な値しか渡すことは出来ません。そのため、下記のようにuserではなくuser_idとして取得してUserのオブジェクトを取得するような形で修正が必要となります。

# before
class MyJob < ApplicationJob
  queue_as :default
  
  def perform(user:)
    # something logic
  end
end

# after
class MyJob
  include Sidekiq::Worker
  sidekiq_options queue: :default
  
  def perform(user_id:)
    user = User.find(user_id)
    # something logic
  end
end

これでSidekiq Enterpriseの機能を使う準備が整いました🎉

Sidekiq Enterpriseの活用事例

最後に弊社におけるSidekiq Enterpriseの活用事例としてReliabilityを使ったJob実行の信頼性の向上を紹介いたします。

Reliabilityを使ったJob実行の信頼性の向上

Jobにおける処理の信頼性の担保が課題としてあげられていたので、Sidekiq Proの機能であるReliabilityを使って信頼性の向上を図っています。

Reliabilityとは、Sidekiq Proの機能である信頼性向上のための機能です。クライアント側(エンキューする側)とサーバー側(デキューして実行する側)に機能が追加されています。

https://github.com/mperham/sidekiq/wiki/Reliability

弊社でも下記の2つを活用しています。

• Redisへのenqueueに失敗した場合にメモリ上にenqueueしておいて、接続可能となったタイミングでenqueueできるReliability Client

• Sidekiqのプロセスが停止した場合にもRedisを総なめして孤立したqueueを実行するsuper_fetch

ネットワーク障害等によりRedisに一時的に接続出来ないために失われていたJobや、実行中にSidekiqのプロセスが停止し孤立してしまったJobの実行を担保出来るようになり、信頼性を向上させることが出来ました🎉

Ent Rolling Restartsを使った安全な再起動

デプロイ時のSidekiqのリスタートによる完了までに長時間掛かるJobの中断を防ぐために、Sidekiq Enterpriseの機能であるEnt Rolling Restartsを使って安全に再起動しています。

通常のSidekiqのリスタートではTSTP+TERMを使ったリスタートを行うと思います。通常であればこの方式で安全に再起動出来るのですが、長時間完了までに掛かるJobの中断を防ぐことは出来ません。

Sidekiq EnterpriseのEnt Rolling Restartsを使うことで、長時間掛かるJobの完了を待って安全に再起動を行うことが出来ます。

There is no limit to the time it can continue running. Upon signalling a rolling restart, a new process will be started to pick up new jobs. https://github.com/mperham/sidekiq/wiki/Ent-Rolling-Restarts

具体的にはRolling Restartsを検知した際に、下記のような形で再起動が行われます。

• 旧プロセスは新規のJobの実行を停止し、既存のJobの実行が終わったら停止する。
• 新プロセスが起動して新規のJobの実行を開始する。

弊社でも導入の背景に記載したとおり、長時間完了までに掛かるJobがデプロイ時に中断される問題がありましたが、Ent Rolling Restartsの機能のおかげで現在はデプロイ時にJobの実行有無を確認する必要はなくなりました🎉

おわりに

Sidekiq Enterpriseについて弊社の事例をご紹介しました。もしもSidekiq Enterpriseの導入検討の一助になれば幸いです✨

運用担当とのやりとりやJob実行の信頼性の向上のための内製化コード、なども省けて金額以上のメリットを感じています！

またSidekiq Enterpriseの導入をすすめる中でSidekiqのWikiを読んだのですが、すごく充実した内容になっているので導入に関わらずSidekiqを触っている方は読んで見ると色々と役に立つ内容が多そうでした🙌

それでは👋

---

メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております！

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html

---

CIで稀にSegmentation faultが起きてRubyが死ぬ問題と対応

CTO室SREの@sinsokuです。

先日、弊社のCIで稀によく Segmentation fault が起きるようになりました。

＿人人人人人人＿
＞　突然の死　＜
￣Y^Y^Y^Y^Y￣

調べてみた

最初は気づかなかったけど、画像の右端のダウンロードっぽいアイコンをクリックすると、実行結果のログを全文見ることができます。

[BUG] Segmentation fault at 0x000056529cd6d5e0
ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-linux]

-- Control frame information -----------------------------------------------
c:0059 p:---- s:0312 e:000311 CFUNC  :[]
c:0058 p:0016 s:0307 e:000306 METHOD /home/circleci/*******/vendor/bundle/gems/activesupport-5.2.3/lib/active_support/execution_wrapper.rb:105
c:0057 p:0004 s:0303 e:000302 METHOD /home/circleci/*******/vendor/bundle/gems/activesupport-5.2.3/lib/active_support/execution_wrapper.rb:83
c:0056 p:0008 s:0298 e:000297 METHOD /home/circleci/*******/vendor/bundle/gems/activesupport-5.2.3/lib/active_support/reloader.rb:72
c:0055 p:0011 s:0294 e:000293 BLOCK  /home/circleci/*******/vendor/bundle/gems/activejob-5.2.3/lib/active_job/railtie.rb:27 [FINISH]
c:0054 p:---- s:0289 e:000288 CFUNC  :instance_exec
c:0053 p:0145 s:0283 e:000282 BLOCK  /home/circleci/*******/vendor/bundle/gems/activesupport-5.2.3/lib/active_support/callbacks.rb:118
（途中略）
c:0008 p:0022 s:0029 e:000028 BLOCK  /home/circleci/*******/spec/jobs/conference_mail_sending_job_spec.rb:89
c:0007 p:0003 s:0026 e:000025 BLOCK  /home/circleci/*******/spec/support/multithreaded.rb:5
（以下略）

どうやらマルチスレッドに関する何かで問題が起きているっぽい。

再現した

とりあえず、手元で20回くらい実行しても稀に死ぬのは分かった。

$ for n in $(seq 1 20); do \
    bundle exec rspec spec/jobs/conference_mail_sending_job_spec.rb:96; \
  done

調べてみた

• 100%再現させる方法が分からない
• エラーの起きるActiveSupport::ExecutionWrapperに怪しいコードはない
• Thread についてあまり詳しくない

調べたけど、何も分からない...

ruby-jp で相談した

相談したら、少し経ってシンプルな再現コードが見つかった。ありがたい。

その後、笹田さんが原因と100%再現するコードを投稿。（すごい）

そして、いつの間にか笹田さんが問題を解決するパッチをコミットし、Issueの登録も済んでいた。（すごい）

https://bugs.ruby-lang.org/issues/16676

どうやら、 #hash の実行中に他スレッドから同じHashを弄ると問題が起きるようです。

テストコードの修正

すでにRubyのmasterブランチでは修正されていますが、CIで2.8.0-devを使うわけにもいきません。

Rubyの新しいバージョンがリリースされるまでのワークアラウンドとして、Railsにパッチを当てる事で対応します。

まず、以下の内容で lib/patches/fix_execution_wrapper.rb を作成します。

# frozen_string_literal: true

raise('Consider removing this patch') if RUBY_VERSION != '2.6.5'

module Patches
  # Rubyが稀にSegmentation faultでエラーになる問題を修正するパッチ。
  #
  # `Thread.current` の代わりに `Thread.current.object_id` を使うこと
  # で#hashの実行時に他スレッドがテーブルを弄るのを避けます。
  #
  # 元の実装は以下を参照してください。
  # ref: https://github.com/rails/rails/blob/v6.0.2.1/activesupport/lib/active_support/execution_wrapper.rb
  #
  # ## Issue
  #
  # `#hash` can change Hash object from ar_table to st_table
  # ref: https://bugs.ruby-lang.org/issues/16676
  module FixExecutionWrapper
    def self.active?
      @active[Thread.current.object_id]
    end

    def run!
      self.class.active[Thread.current.object_id] = true
      run_callbacks(:run)
    end

    def complete!
      run_callbacks(:complete)
    ensure
      self.class.active.delete Thread.current.object_id
    end
  end
end

ActiveSupport::ExecutionWrapper.prepend(Patches::FixExecutionWrapper)

このパッチを config/environments/test.rb で読み込む。

Rails.application.configure do
  # 中略
end

require 'patches/fix_execution_wrapper'

これで本当に直るかは自信なかったのですが、1週間くらいCIの様子をみていても Segmentation fault が起きませんでした。
たぶん大丈夫です。

まとめ

自分1人で調べていても全く再現コードを作れなかったし、再現コードを見ても原因に検討もつきませんでした。

• ruby-jpに感謝
• 笹田さんすごい
• ThreadとRubyは難しい

もしスレッド周りで同じ問題を踏んだとき、この記事が参考になれば幸いです。

---

メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております！

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html

---

Nuxt利用プロダクトでIE11と仲良くするためのE2E

フロントエンドなエンジニアの皆さま、ご機嫌いかがでしょうか。

唐突な質問ですが、Internet Explorer 11というブラウザはお好きでしょうか。勿論大好きであられるかと存じ上げます。Webの歴史をまさにその身をもって築き上げてきた由緒正しきブラウザであります。唯一無二の王道です。昨今は様々なブラウザが溢れてあそばせております。しかし所詮それは一時的なこと。やがて全人類は母なるInternet Explorer 11の元へと還っていくことでしょう。

我々が目指したこと

Internet Explorer 11（以下、IE11）を目にすること、操作すること、その他あらゆる接点を限りなく減らしつつ、プロダクトがIE11でも動作可能なことの検証と保証を行いたい。

これを成し遂げるエンジニアリング的な手段、つまりIE11環境でのE2Eテストを自動化することを目指します。

環境

自動化を行うにあたり、何をするにもまずは環境を用意しなければなりません。IE11が動く環境です。

そして早速ですがこの環境こそがIE11環境自動テスト一番の問題と言っても過言ではないでしょう。なぜならIE11が動くということは、当たり前ですがOSとしてWindowsが動いていなければなりません。Linuxディストリビューションではだめなのです。

1年前ならここで既に諦めざるを得なかったかもしれません。しかし今は既に2020年です。Windows環境に対応したCI環境は十分手に届く範囲に登場してきています。

メドピア開発部が最もお世話になっているテスト環境はCircleCIです。そしてなんと、CircleCIでもWindows環境に対応を始めているではありませんか。

circleci.com

既にWindows対応のテスト環境は目の前にあったわけです。しかし不運なことに、この事実はこの記事を執筆中に発見しました。執筆中ということは、当然ながら当初の目的は既に果たしているわけです。今ネタバレをしましたが、つまり今回採用したのは慣れ親しんだCircleCIではありません。

IE11の全てを委ねるべく採用した環境は、Github Actionsです。
なぜGithub Actionsか、とてもいい質問です。「Githubで完結する」、「GithubがMicrosoft傘下になっていた」、「社内ではまだ導入事例も少なく目新しさがあった」、そこには色々な選ぶべき理由があります。

そしてこういう理由は後付けです。最初に目に入ってしまったからです。IE11でサービスが動いていなかった障害に傷心しながら「IE11 E2E」と適当なワードで検索したら偉大な先駆者達の功績が目に入ってしまったわけです。

qiita.com

moneyforward.com

今まで不可能だと諦め続けていたことが、「できる・・できるんだ・・っ！」という確信に変わった瞬間です。あとはもう勢いでやり切らざるを得ません。そして勢いのままに開発フローに導入し、勢いの落とし前としてこうして外部発信をして既成事実としていくわけです。

プロダクト概要

昨年11月にリリースした、「MedPeerスポット×リクルートメディカルキャリア」という医師向けスポット求人マッチングサービスです。 spot-rmc.medpeer.jp

プレスリリースはこちら。 medpeer.co.jp

求人マッチングサービスという特性上、求人情報の検索、応募フォームの入力、応募リクエストの送信あたりが動作してくれないと非常に困るクリティカルな機能となってきます。

プロダクト構成

今回ターゲットとしたプロダクトは、APIを提供するRuby on Railsによるバックエンドと、フロントエンドをSSR対応で配信するNuxt.jsという2枚看板な構成です（以下、Rails、Nuxt）。

Tailwind CSSの話題に終始した前回記事と同じプロダクトなので、お時間あればこちらもご覧ください。 tech.medpeer.co.jp

フロントエンドとバックエンドの橋渡し役となるAPIは、OpenAPIに乗っ取ってスキーマ定義を行い、openapi-generatorのtypescript-axiosを利用して型付きのクライアントSDK化しています。

3者連携

このSDKは独立したリポジトリになっていて、スキーマ更新をpushするとSDKも最新化してくれるようCIを組んでいます。
あとはフロントエンドリポジトリ側でSDKのインストールやアップデートをしていけば、型で（ある程度は）守られたSDKを通してAPIとの連携が可能です。

問題

Railsが強めなメドピア開発環境からすると、フロントエンドが完全にRailsから分離された今回のプロジェクトはなかなかに攻めた構成でした。フロントエンド分離主義者の方々もきっと満足してくださるでしょう。

かくいう私も満足していた1人だったのですが、E2Eテストという観点からするとこの構成は大きな問題を抱えていました。
Rails主導な構成であればcapybaraを利用したFeature specが大体いい感じにしてくれるみたいです。実際メドピアではこれが大活躍していて、入社当初はFeature specによるテストの充実具合に驚いた思い出があります。

しかし困ったことに、今回のフロントエンド環境はRailsの支配下にありません。こういう状況で、E2Eテストをどう行うべきかという知見が社内に全くない状態でした。

このようなマイクロサービス気味構成におけるE2Eテストのベストプラクティスを一緒に考え、議論し、実現していってくれるエンジニアをメドピア開発部では絶賛募集中です。

今、私にできること

全てがうまくいくトータルオールインワンストップE2Eソリューションの実現は残念ながら成りませんでしたが、ある程度の妥協を許せばこんな私にもできることは残されています。

今回の目的に立ち戻ります。それは、「IE11での動作検証を自動化する」ことです。IE11固有の動作検証をしたいわけです。例えばIE11固有の仕様により、ajax通信用APIを提供しているだけのRails側機能が動作しないということはあるのでしょうか？

落ち着いてください、お気持ちは分かります。確かに無いとは言い切れないかもしれません。IE11の全てを疑ってかかりたい人生を送られてきた皆様のお気持ちは十分に分かりますが、それでもときには信じることだって大事なんです。

はい、信じました。これでまずはRailsが動作検証の対象から外れました。

関心範囲

Railsが関心範囲から外れてしまえばあとはもうフロントエンド原理主義者が好きにやるだけです。先ほどAPIとの連携部分は型で守られたSDK化していると紹介しました。つまりは型さえ守っていればモックに差し替えることは容易いわけです。

最小の関心範囲

当初は登場人物が3人も居て途方に暮れていましたが、IE11で動作検証することを目的とするならば、Nuxtだけを検証対象にすればよいという状況に漕ぎ着けました。

Github Actions

Github Actions用ymlファイルの紹介です。
既に先人達が詳細に紹介してくれていて、特に大きな差分もないです。異なるのは、NuxtによるSSR環境を再現するために、テストランナー用のスクリプトを別途用意している点です。

gist.github.com

続いてそのテストランナー用のスクリプトの中身です。
テスト対象となるNuxtサーバーの起動と、テスト本体を実行してくれるTestcafeの起動を担当しています。
Nuxtを裏で起動したままTestcafe（後述）を起動するという制御が必要だったので、非同期な処理が書きやすいnodeスクリプトを利用しています。

Github Actions職人であればNuxtの裏起動をもっとスマートな方法で実現できるのかもしれません。メドピアではGithub Actions職人もきっと募集しています。

gist.github.com

なにやら怪しげなコメントがいくつか挿入されています。いずれも遭遇したエラーとそれを乗り越えた歴史です。

windows環境でspawnが使えない

spawnというのは非同期で外部コマンド実行してくれる関数です。
IE11を動かすGithub Actionsは当然ながらwindows環境です。普段windows環境でnodeスクリプトを実行する習慣がないので油断していました。spawnはcmd経由でコマンドを実行する必要があるようです。

stackoverflow.com

@nuxtjs/pwaモジュールが吐き出すエラーでジョブが落ちる

ERROR  (node:5136) DeprecationWarning: Tapable.plugin is deprecated. Use new API on .hooks instead

こういうやつです。その他環境ではエラーを吐いても特に問題なくNuxtのビルドは成功判定となってくれるのですが、なぜかGithub Actionsのジョブとして実行すると容赦なくエラー扱いで落ちてしまいました。

@nuxtjs/pwaモジュールを最新化すればエラーは消えるらしいものの、まだβバージョンということで躊躇し、nodeスクリプト内でGithub Actionsさんに気づかれないよう実行することで回避しました。

クロスブラウザでテストする場合だと毎回ビルドし直しになって効率悪いですが、今回の対象はIE11だけなのでここも割り切っていきます。

windows環境でnpmスクリプトに環境変数を渡せない

もう1件windows由来問題です。どうやらwindowsではNODE_ENV=production yarn buildのような環境変数の指定はできないらしいです。やはり普段触らない環境は知らないことだらけですね。
cross-envというパッケージを使うとさくっと指定できるようなのでnpxでさくっと使わせていただきます。

stackoverflow.com

Testcafe

環境が出揃ったところで今更ですがテストランナーの紹介です。今回採用したのはtestcafeです。

採用理由は、IE11でさくっと動いたからです。第一目的はIE11における動作検証であって、プロダクトの仕様や機能検証といった大層なものではありません。さくっと仕組みを作って多大な労力を削減する。できそうなことが分かったのですからそのまま勢いで組み上げます。

テストコード抜粋はこんな感じです。できる限りE2E専用のidやclassは入れないほうがメンテは楽な気がします。文言変更で壊れたらそのときは諦めて都度直しましょう。

gist.github.com

なにやらresizeWindowという怪しげな関数があります。これはTestcafeに限った問題ではなくIE11利用のE2E全般の問題らしいですが、IE11では画面外要素はなぜか存在しない判定をされてしまうらしいです。

全盛期の彼ならその理由を躍起になって深掘っていったかもしれません。そんな彼もIE11に打ちのめされ尽くした今となっては、目の前の現実をただ受け入れるだけのマシーンです。そういうものです、目の前で起きていることは紛れもない現実なのです。

ただし開発環境のfirefoxやchromeなどで実行するときはサイズが大きすぎると怒られるので、申し訳程度に分岐を入れておきます。

成し遂げたこと

動くことの証明

かくして、IE11で我々のプロダクトが動作することの検証は自動化に成功しました。E2Eのテストカバレッジは相当少なく、おそらく10%にも届いていないです。しかしながら、最も重要なトップ画面から応募完了までのルートをIE11で通過できることが自動テストで保証されている安心感は凄まじいです。

dependabotでnpmパッケージアップデートのPRが飛んできても、それがbabel関連パッケージだったとしても、自動テストが元気よく動いてIE11環境の動作検証を行ってくれています。

結局スタイルチェックで実機IE11チェックは必須なんですがこの記事が皆様のIE11ライフに少しでも貢献できましたら幸いでした。

---

(☝︎ ՞ਊ ՞)☝︎是非読者になってください

---

メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております！

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html

CircleCIのYAMLを短く書けるRails Orbを作りました

11月に入社したCTO室SREの@sinsokuです。

主にやっていることはRailsアプリのレビューや開発環境の改善です。*1

• 社内のRailsアプリを横断して浅くレビューする（8つくらい）
• MedPeerの開発環境の改善
  • docker-compose up で30個のコンテナが起動するのを減らす
• SwitchPointからActiveRecord v6への移行
• CircleCIの実行時間の短縮、稀に落ちるテストの修正
• その他の細かい改善

このうち、CircleCIについて知見が溜まったので技術ブログで紹介します。

CircleCIで気をつける点

CircleCIの実行時間を短くするにはいくつかコツがあります。

• gemとnpmをできるだけキャッシュする
• RSpecを並列で実行する前に assets:precompile を実行しておく
• 各ジョブで必要なgem（もしくはnpm）だけをキャッシュから復元する
  • 例: JavaScriptのテストはnpmのキャッシュだけ復元する

ワークフローを図にするとこんな感じです。

CircleCIのジョブのワークフロー

キャッシュの仕組みについて

詳しく知りたい人はCircleCIのページ を読んで頂くとして、ここでは一番重要な 部分キャッシュ について説明します。

CircleCIのキャッシュキーには複数のキーを指定することができます。

- restore_cache:
  keys:
    # 「OSとCPUの種類」「ブランチ名」「Gemfile.lock の checksum」でキャッシュを探す
    - gem-cache-v1-{{ arch }}-{{ .Branch }}-{{ checksum "Gemfile.lock" }}
    # 上のキーで見つからない場合、「OSとCPUの種類」「ブランチ名」でキャッシュを探す
    - gem-cache-v1-{{ arch }}-{{ .Branch }}
    # それでも見つからない場合、 `gem-cache-v1` で始まる最新のキャッシュを探す
    - gem-cache-v1

キャッシュキーを複数指定すると上から順番にキャッシュを探します。
これによりGemfile.lockが変わっても、 bundle-installで全てのgemをインストールしないで済むようになります。

キャッシュの肥大化

部分キャッシュを使っているとgemが増え続け、キャッシュのリストアに時間がかかる問題が起きます。
bundle install --clean すれば良いのですが、少しずつ遅くなるため気づき辛い問題です。

参考: bundle install には --clean を指定する (特に Circle CI では) | Born Too Late

ちなみにYarnは自動的に不要なnpmを消してくれます。🐈

Rails Orb

上記の点を気にしながら、社内のRailsアプリで横断的に対応するのは大変なので、誰でも良い感じに設定できるOrbを作りました。

github.com

実際に社内のいくつかのRailsプロジェクトに導入しています。

使い方

Orbの提供するジョブやコマンドの詳細はOrb registryを参考にしてください。

また、Rails Orbを使う前にCircleCIの設定画面で uncertified orbs を許可する必要があります。

gemやnpmのキャッシュについて

Gitリポジトリのデフォルトブランチをキャッシュキーに含めることでキャッシュヒット率を上げています。

- restore_cache:
  keys:
    - << parameters.key >>-{{ arch }}-{{ .Branch }}-{{ checksum "Gemfile.lock" }}
    - << parameters.key >>-{{ arch }}-{{ .Branch }}
    - << parameters.key >>-{{ arch }}-{{ checksum ".git/refs/remotes/origin/HEAD" }}
    - << parameters.key >>-{{ arch }}

一般的なジョブを提供

CircleCIの設定を簡単にできるように、以下4つのジョブを提供しています。

• rb-deps: bundle install を実行する
• js-deps: yarn install を実行する
• assets: assets:precompile を実行する
• rspec: RSpecでテストを並列に実行する

新規案件で rails new した直後なら以下の設定で良い感じにCircleCIが動きます。

version: 2.1

orbs:
  rails: medpeer/rails@x.y.z

executors:
  ruby:
    docker:
      - image: &docker_ruby circleci/ruby:2.7.0-node-browsers
  ruby_with_db:
    docker:
      - image: *docker_ruby
      - image: circleci/postgres:12.1-alpine-ram
    environment:
      DATABASE_URL: 'postgres://postgres:postgres@127.0.0.1:5432'

workflows:
  rspec:
    jobs:
      - rails/rb-deps:
          executor: ruby
      - rails/js-deps:
          executor: ruby
      - rails/assets:
          executor: ruby
          requires:
            - rails/rb-deps
            - rails/js-deps
      - rails/rspec:
          executor: ruby_with_db
          db-port: '5432'
          parallelism: 4
          requires:
            - rails/assets

ジョブとコマンドを組み合わせる

Orbの提供するrb-depsジョブとbundle-installコマンドを組み合わせると、RuboCopを実行するジョブなども短く書けます。

version: 2.1

orbs:
  rails: medpeer/rails@x.y.z

executors:
  ruby:
    docker:
      - image: circleci/ruby:2.7.0-node-browsers

jobs:
  rubocop:
    executor: ruby
    steps:
      - checkout

      # Restore gems from cache
      - rails/bundle-install:
          restore_only: true

      - run: bundle exec rubocop --parallel

workflows:
  rspec:
    jobs:
      - rails/rb-deps:
          executor: ruby
      - rubocop:
          requires:
            - rails/rb-deps

まとめ

Rails Orbを使うと .circleci/config.yml の記述をかなり減らせるかなと思います。

各社でCircleCIのYAML職人をしている方、ぜひRails Orbを試してみてください。

---

(☝︎ ՞ਊ ՞)☝︎是非読者になってください

---

メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております！

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html

*1:SRE所属だけど、あまりSREっぽい仕事をしていない

Tailwind CSSという風と共に走るフロントエンド開発

10km40分切りが2020年の目標、メドピア長距離部の小宮山です。

みなさんTailwind CSSはご存知でしょうか。tailwindとは「追い風」を意味します。最高に気持ちよく走れるコンディションですね。

目次

サービス概要

まずは今回新たに立ち上げたサービスの紹介です。 「MedPeerスポット×リクルートメディカルキャリア」という医師向けスポット求人マッチングサービス（以下、本サービス）が11月にリリースされました。

medpeer.co.jp

ログインや応募などサービスのコアな部分はMedPeer医師会員限定になってしまいますが、サイトの雰囲気自体は非会員でも十分に味わえますので是非ともサイトを開いてみてください。医師向けスポット求人という普段なかなか見ることができない世界を覗くこともできます。

技術概要

本サービスの技術的な構成をざっと紹介していきたいと思います。

まずはMedPeerといえば（？）なRuby on Rails（以下、Rails）です。最新ほやほやの6.0です。自分はフロントエンド畑な人間でそれほどRailsに精通しているわけでもなくそのすごさをちゃんとは理解していませんが、きっとすごいことなんだと思います。

以前のMedPeerなら、「Railsを使っています、以上です。」で終わってしまっていたところですが、なんと今回はもうひとつ目玉技術があります。Nuxt.js（以下、Nuxt）です。

ja.nuxtjs.org

実はNuxtの利用自体はMedPeerでは初めてではありませんでした。静的サイトのジェネレータとしてシンプルなLPを作成した実績はすでにあります。

かかりつけ薬局化支援サービス「kakari」のLPがまさにそれにあたります。

kakari.medpeer.jp

ではなぜ再度Nuxtを強調し直すのか。なんと今回は、Nuxtを本番運用してSSR（サーバーサイドレンダリング）するというMedPeer初の挑戦だったのです。さらにバックエンド（Rails）とフロントエンド（Nuxt）をリポジトリもAWSリソースも分離してしまうというMedPeer初だらけの野心的な技術構成となっていました。

そして非常に申し訳ないのですが、今回伝えたいのはNuxtのことでもフロントエンド分離のことでもありません。開発プロセスやVue.jsの話題ですらありません。それ以上にTailwind CSSのことを伝えたいモチベーションが高すぎました。新大陸の大地そのものよりも、そこに吹いていた追い風にこの心を掴まれてしまったのです。

Tailwind CSSとは何か

tailwindとはずばり「追い風」を意味します。今日の走りは絶好調だと思ったら折返しで現実に引き戻されるやつですね。

公式サイトの文言をここに引用します。

A utility-first CSS framework for rapidly building custom designs.

Tailwind CSS is a highly customizable, low-level CSS framework that gives you all of the building blocks you need to build bespoke designs without any annoying opinionated styles you have to fight to override.

一応CSSフレームワークという分類になりそうですが、BootstrapやVuetifyといった所謂一般的なCSSフレームワークとはやや毛色が異なります。

一般的なCSSフレームワークの多くが「コンポーネント」を提供してくれるのに対して、Tailwind CSSが提供してくれるのはスタイルを便利に指定するためのツール類だけです。

例えばダイアログを作りたいと思ったとき、Vuetifyならコンポーネントとして既に用意されていますが、Tailwind CSSでは用意されたツールを組み合わせてダイアログというコンポーネントを自力で作らなければいけません。Tailwind CSSが提供してくれるのは自動車本体ではなく、その名前が意味する通り、自力で走る者たちへの追い風です。

HTMLとCSS

Webページを構成する３要素といえば、HTML・CSS・JavaScriptです。HTMLはWebページの構造を、CSSはレイアウトや装飾を、JavaScriptは何かをしてくれます。
（今回はJavaScriptについてはあまり掘り下げません。）

ja.wikipedia.org

文書の構造と体裁を分離させるという理念を実現する為に提唱されたスタイルシートの、具体的な仕様の一つ。

令和を生きる私はCSSが登場したころの状況を実際には知らないのですが、どうやらCSSはHTMLからスタイルを分離させることを目的に生み出されたもののようです。そして実際に、文章構造とスタイルやHTMLとCSSそれぞれに切り出して役割分担させるのがWebの作法だという認識が広く広まっていたと思います。

HTML

<ul class="content-list" >
  <li class="content-item">item 1</li>
  <li class="content-item">item 2</li>
</ul>

CSS

.content-list { display: flex; }
.content-item { padding: 1rem; }

なんの変哲もない例を出すとこんな感じでしょうか。HTML側ではタグにclassを付け、CSS側ではそのclassをセレクタとしてスタイルを付与しています。

一方でこんなHTMLはどうでしょうか。

HTML

<ul style="display: flex;" >
  <li style="padding: 1rem;">item 1</li>
  <li style="padding: 1rem;">item 2</li>
</ul>

スタイルをCSSに分離することなく、タグにそのまま書き込んでいます。所謂インラインスタイルです。基本的に、インラインスタイルが歓迎されることはほとんどないと思われます。実際に私もこのコードだけを見たらレビューコメントを入れる手を止めることはできないでしょう。

しかしなぜ歓迎されないのでしょうか？実のところ「そういうもの」で終わらせてしまうことが多く、あまり深く考えたことはありませんでした。実際にCSSは誕生目的からして「そういうもの」なのですが、改めてその問題点をざっと考えてみました。

• HTMLが冗長になる
  class指定が不要とはいえ、styleで書き込むので文字数の絶対量は増えてしまいます。
• スタイルの共通化ができない
  タグ毎にstyleを書き込むしか無いので、リストアイテムなどには大量に同じstyle属性を書き込まないといけません。HTML冗長化をさらに後押しします。
• CSS関連のエコシステム（Sass、PostCSS、Stylelintなど）が使えない
  最近のフロントエンド開発ではこれが相当のデメリットではないでしょうか。
  （もしかしたらインラインスタイルにもいい感じに変換やlintを当ててくれる仕組みがあるかもしれません。）
• レスポンシブ対応が難しい
  若干思いつきベースですが、インラインスタイルでレスポンシブなスタイルって作れるんでしょうか？やるなら下記のようになりそうですが、試そうと思ったこともなさすぎて効くのかどうかは未検証です。

<ul style="@media (min-width:480px) { display: flex; }"> ... </ul>

HTMLとCSSとコンポーネント

時代は変わりつつあります。既に変わってしまっているのかもしれません。その変化の主役となる存在がコンポーネントです。HTMLとCSSは文章構造とスタイルという役割で分離するのが当たり前だったのに、コンポーネントという新たな区切がより重視されるようになってきています。

従来のWebページ構成

コンポーネント指向なWebページ構成その１

コンポーネント指向がもたらす大きなメリットは、コンポーネントという明確な区切りが生まれることです。今までのHTML・CSS・JavaScriptという３層では、互いに分離されてはいるものの、その層内はほぼグローバル空間と化していました。良く言えば自由で手軽に作れてすぐに変更可能、悪く言えば分かりにくく壊れやすくて変化に弱い。

コンポーネントという区切りは、この３層のより上位の区切りとしてWebページのグローバル空間を分割します。そしてさらにコンポーネント内でHTML・CSS・JavaScriptの３層が存在するようなイメージです。

双方ともにメリットとデメリットは様々にありますが、今のフロントエンド界隈はコンポーネント指向が勢い付いていると見て間違いないでしょう。

シンプルに考えると、Webページがコンポーネントによってまず区切られ、コンポーネント内部では従来の３層区切りがそのまま再現されているだけです。確かにコンポーネントが注目されだした当初はそうだったかもしれません。

しかし変化はそこで留まってはくれませんでした。コンポーネントという閉じた安全な世界が作られたことで、その内部ではかつて常識と考えられていた壁の存在感が薄れだしました。

コンポーネント指向なWebページ構成その２

コンポーネントとして完結していて、外部との連携で求められるインタフェースが満たされてさえいれば、コンポーネント内部の実装が多少暴れん坊になっていても大した問題にはなりません。いや問題ではあるんですが、コンポーネント内部はいわばprivateな部分なので大した問題ではないことがほとんどです。コンポーネントという区切りが明確に存在しているので、どうしようもなくなったら丸ごと取り替えてしまうことだって可能です。

かくしてコンポーネントの躍進により、HTMLとCSSの境界は薄れだしました。もちろん完全になくなったわけではありませんが、CSSが生まれた目的そのものであったHTMLとスタイルの分離は、コンポーネントというより大きな関心事にかき消されつつあります。

コンポーネントと雑なセレクタ

コンポーネントという概念によってHTMLとCSSの間にあった従来の区切りは曖昧になり、両者の距離はぐっと近づいています。区分けされた両者を繋ぐために必須だったclassを軽視する、こんな手抜きスタイル指定も横行しているのではないでしょうか。

HTML

<ul class="content-list" >
  <li>item 1</li>
  <li>item 2</li>
</ul>

CSS

.content-list { display: flex; }
.content-list > li { padding: 1rem; }

階層を指定しているとはいえ、セレクタとしてliを直で指定しています。従来のHTML・CSS分離の方針に従うなら真っ先にレビュー指摘が入りそうなコードです。実際に私もこんなコードを素の状況で見つけたらおそらく指摘を入れます。ただしこのコードがコンポーネントに関するものであれば話は別で、CSSにHTMLの構造が漏れ出していてもそれほど気にしません。

理由は２つあります。１つはスタイルがコンポーネント内に閉じているからです。liという豪快なセレクタ指定がされていようと、そのセレクタがコンポーネント内のHTMLに限定されているのなら、コンポーネント外の予期せぬ箇所でスタイルが崩れることはありません。
（セレクタのパフォーマンス観点については今回は立ち入りません。）

もう１つは、classを丁寧に付けるほうがむしろコストが高くなるかもしれないからです。classを増やせば当然HTMLの文字数は増えて汚れます。適切なclass名を文書構造と翻訳サイトを往復しながら考えなくてはなりません。HTMLとCSS間の視点移動だって必要です。つまり面倒くさいのです。単発では小さな手間かもしれませんが、それを数百数千回と繰り返すのはとても面倒くさいのです。人生は短いんです。早く家に帰って走りたいんです。

コンポーネントとインラインスタイル

コンポーネントという箱庭の存在によって、雑なセレクタが許されるようになってきたとしましょう。エンジニアというのはどこまでも怠惰を求める生き物らしいです。当然、一度雑になったセレクタ指定はどこまでも雑になっていきます。雑になればなるほどHTMLとCSSは近づいていきます。そして行き着く先に何があるかというと、インラインスタイルの再登場です。

HTML

<ul style="display: flex;" >
  <li style="padding: 1rem;">item 1</li>
  <li style="padding: 1rem;">item 2</li>
</ul>

コンポーネント指向という前提に立ち、改めて先に挙げたインラインスタイルのデメリットを再評価してみます。

• HTMLが冗長になる
  基本的には従来と同様だと思います。
• スタイルの共通化ができない
  コンポーネント単位での共通化という大きな道が開けます。利用するフレームワーク依存となりますが、v-forやjsxなどで効率的に記述する手段も多くあります。
• CSS関連のエコシステム（Sass、PostCSS、Stylelintなど）が使えない
  基本的には従来と同様だと思います。
• レスポンシブ対応が難しい
  コンポーネントごと表示を切り替えるなどの手段が生まれてきそうですが、ほぼ従来と同様と思われます。

ただしHTMLの冗長さやCSSエコシステムについては、コンポーネント指向な開発の現場でよく使われるstyled-componentsやCSS in JSなどのJavaScript側からのアプローチによって解決は可能かもしれません。
（普段Vue.jsのscoped CSSばかり使っているのでこのあたりの動向には疎いです。）

場面によってはインラインスタイルで済ませてしまうことも十分に可能ですが、大勢をそれだけでなんとかするのはやはり厳しい印象です。特にCSS系のエコシステムとの相性と、レスポンシブ対応のやりにくさは致命的です。インラインでベンダープレフィックスを付けていく作業以上の苦痛はなかなか見つからないと思います。人生は短いし早く帰って走りたいんです。

Tailwind CSSがもたらしたもの

やっとTailwind CSSの話題にたどり着きました。先に挙げたインラインスタイルの例をTailwind CSSで書くとこうなります。

HTML

<ul class="flex" >
  <li class="p-4">item 1</li>
  <li class="p-4">item 2</li>
</ul>

ご理解いただけたでしょうか。ここまで長々と紹介してきたコンポーネントとスタイル指定に関する内容そのものが、Tailwind CSSの良さへと至る道筋です。コンポーネント化の波がもたらしたスタイル指定の怠惰の極みにあるインラインスタイル、良さもあるが辛さも多量に含んだその地点に到達する一歩手前に我々を留めてくれる存在、それこそがTailwind CSSです。

見ての通り、Tailwind CSSはスタイルとほぼ１対１に対応したclassを提供してくれます（一部複合的なスタイル付きclassがあったり、独自で拡張することも可能です）。つまり実質class方式でスタイルを指定しているだけなので、autoprefixerやpurgecssなどとの連携が容易です。

ブレークポイント用のプレフィックス（sm:, md:, lg:）が用意されているので、レスポンシブ対応に苦慮する必要もありません。

例えばPCサイズ以上でだけ横並びにしたい場合はこう書けます。インラインスタイルの良さを残しつつ悪さを緩和する、絶妙な具合ではないでしょうか。

HTML

<ul class="flex flex-col md:flex-row" >
  <li class="p-4">item 1</li>
  <li class="p-4">item 2</li>
</ul>

HTMLが冗長になるという点に関しては、インラインスタイルよりは改善されているものの、class形式でスタイルを当てていくときほどには軽量にならないです。スタイルとclassがほぼ１対１になっているので、この点は受け入れるしかないというのが現時点の評価です。

まとめ

Tailwind CSSは決して強力なCSSフレームワークではありません。フレームワークと呼んで良いのか怪しいくらいに具体的なものは何も提供してくれません。公式サイトに掲げられている通り、utility-firstなツールを提供してくれるだけです。ツールをどう使うか、何を作るかは完全に使い手に委ねられています。

そこに心地よさを感じかどうか個々人で評価が分かれるかもしれません。しかしながら本サービスの立ち上げからリリースまでTailwind CSSを使い続けた私の感想としては、「次もまた使いたい」し「発展に貢献したい」です。

その理由を端的に表現するのはとても難しいです。なぜなら具体的にこれが良いと言い切れるようなものではなく、この記事で述べてきたように、Webフロントエンドの潮流の中で味わう様々な要因が組み合わさって到達した良さだからです。しかしその良さを実感しているのは事実です。

今回はTailwind CSSの使い方自体はほとんど紹介できませんでしたが、最近は利用事例も増えて情報も多く出ているので探すのに困ることはないと思います。需要があればMedPeerでのTailwind CSS利用事例として改めて記事化するかもしれません。

Tailwind CSSの巻き起こす追い風、みなさんも是非味わってみてください。

---

(☝︎ ՞ਊ ՞)☝︎是非読者になってください

---

メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております！

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html

メドピア16期目初の開発合宿@熱海を開催しました！

みなさんこんにちは！

10月からメドピアにジョインしました、サーバサイドエンジニアの福本です。

メドピアでは日常業務から離れ、業務改善や技術研鑽のための開発合宿を定期的に開催しております（ちなみに、前回の開発合宿の様子はこちら↓）。

tech.medpeer.co.jp

私は今回が初めてのメドピア開発合宿だったのですが、すごく楽しくて有意義な時間だったので、合宿の様子をみなさんにもお届けできればと思います。

開発合宿のプログラム

今回の開発合宿は、11月20日(水)~22日(金)の2泊3日で行われました！

開発するテーマは自由なのですが、当日に内容に悩んで時間を無駄にしないように、事前に内容をエンジニアのメンバーに事前に決めてきてもらいます（前もって準備をしてきてもOK）。

また、せっかく時間を掛けて取り組んだ内容なので、開発合宿でのアウトプットを各自が発表する場を設けているのですが、合宿中に発表まで行ってしまうと開発に使う時間が短くなったり、資料に掛けられる時間が少なくなってしまいます。

そのため、成果発表は合宿が終わった次の週にオフィスで開催することにし、合宿中は思う存分開発に集中できるようにしました。

発表の様子もこちらの記事でお伝えしますので、ぜひ最後までお付き合い頂けると幸いです！

1日目

待ちに待った開発合宿は、お昼過ぎからの開始！熱海駅に1名を除きエンジニアメンバー全員で集合し、会場まで向かいました。

ちなみに、今回予約した宿泊所はこちらです↓

www.airbnb.jp

Airbnbで予約したのですが、地下1階から5階まで広く自由に使えますし、屋上で足湯に入りながら開発できたり、地下にはゲームやカラオケがあるなど、みんなで楽しみながら（後述）開発できるような環境になっています。館内のWi-Fiも速く、チーム開発も問題なく進められるのでオススメです。

まずは会場で全員集合して、各メンバーが取り組む開発テーマを改めて発表し、その後は各自で自由に開発を行います。足湯に入ってリラックスながら開発をするメンバー、机と椅子でバッチリ集中して開発をするメンバーと、色々な開発スタイルが見られて面白かったですね。

 

夜は熱海...ということもあり、休憩がてら近くのスパや温泉を楽しみに行くメンバーも。ちなみに、夜ご飯は参加メンバー全員で近くのお店に食べに行きました。周辺に飲食店が充実しているというのも、熱海のいいところ。

 

部屋に戻ってからは、各自で開発に戻りました。

2日目

2日目は移動がないので、朝起きてから夜遅くまで、ひたすら開発に集中できる貴重な一日でした（そのためブログに書くことも少ない....）！

とはいえ気分転換も大事。朝食がてら朝日を拝みに行ったり、

お昼ごはんは、みんなで海鮮を食べに行ったりしました。

そんな2日目ですが、なんとRailsに送ったPRをマージされたメンバーがおりました...（すごい）。合宿で取り組んでいるメインのテーマではなかったようですが、目に見える形でわかりやすく成果が出るのは非常に嬉しいですね！

画像にもURLありますが、マージされたPRは以下。よろしければご覧ください。

github.com

3日目

楽しい開発合宿も最後ですが、合宿所の予約日時の都合上、3日目は場所を近くのコワーキングスペースに移して開発を進めました。場所は同じく熱海にありますnaedocoさん。

naedoco.jp

naedocoさんは2016年にできたばかりのコワーキングスペースで、今までの開発場所とはまた違った雰囲気の中、リフレッシュして開発をすすめることができました。

プログラム上は15時に解散、その後は各自自由に帰宅・開発という流れだったのですが、集中するあまりコワーキングスペースの開場時間ギリギリまで開発をするメンバーも居ました。

そんなこんなで、3日間の開発合宿は終了。各メンバーがどこまで進捗したのかはお互いあまり知らない状態だったので、成果発表がすごく楽しみです。

成果発表LT

厳密には合宿...ではないのですが、土日のお休みを挟み、開発合宿の成果発表会を社内LTのような形で実施いたしました！

合宿に参加できなかったエンジニアはもちろんですが、参加したエンジニアも合宿中には自分たちの開発内容に没頭していたこともあり、開発合宿の進捗や得た学びを改めて確認する場になりました。

開発テーマの内容は本当に様々で、例えば人工知能系のチャットボットについてがっつり調査を進めてくれたメンバーも居れば...

「心拍数を測り、PCのカメラから撮影した動画の顔に計測結果を写す」という、日常のWeb開発の業務ではなかなか触れることのない技術を使いこなしてアウトプットをしたメンバーも。

参加したエンジニア全員が発表したところで、開発合宿は完全に終了！

改めて振り返ってみると、単純に楽しかったというのはもちろんですが、参加したエンジニア全員がしっかりと開発テーマを進捗させて、アウトプットできる形まで持っていっている、という部分が印象に残る合宿でした。

初めて触れる技術をテーマにしていたエンジニアも多い中で、適度に楽しみながらも、集中すべきところはしっかりと集中してやり切る姿に、メドピアのエンジニアの底力を見たように思います。

さいごに

最後までお付き合い頂き、ありがとうございました！

メドピアという会社が、事業も開発チームも大きくなっていく中で、多くのエンジニアメンバーが3日間も集中できる時間を頂けるということは決して当たり前のことではなく、会社全体の理解と協力があってのことで、非常にありがたいことだと改めて感じました。

今後も開発合宿という文化を継続して開催していけるよう、事業に技術でしっかり貢献していきます。

また、今回の合宿で培われた技術によってメドピアのサービスが改善されたり、あるいは新しい事業やサービスを産みだされることで、より多くの医師を支援し患者を救うことに繋がればと考えております。10月から16期目を迎えたメドピアを、みなさまどうぞ応援よろしくお願いいたします！

---

(☝︎ ՞ਊ ՞)☝︎是非読者になってください

---

メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております！

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html

メドピア開発合宿でVue.jsテストライブラリ「vue-function-tester」を作った話

涙の数だけ強くなるフロントエンドエンジニア村上(@pipopotamasu)です。

先週の水木金とメドピア恒例の開発合宿 in 熱海に行ってきたので、そこで作ったVue.jsのテストライブラリ「vue-function-tester」を紹介したいと思います。

github.com

atami

vue-function-testerとは

vue-function-testerは、Vue.jsの「メソッドの単体テストライブラリ」として作りました。
もっと具体的に言うと、Vue.jsのmethods, lifecycle hooks, computed, watchをテストするためのライブラリです。
※ちなみに「vue-method-tester」にしなかったのはmethodsプロパティと被ってややこしくなるのでやめました

Get started

長々と解説するよりは実際のコードをみて行きましょう。
テスト対象のコンポーネントとして、簡単な検索ボックスのサンプルコードを用意しました。

// SearchBox.vue
export default Vue.extend({
  data () {
    return {
      query: '',
      error: ''
    }
  },
  methods: {
    search () {
      this.error = ''
      if (this.query === '') {
        this.error = "Please input."
      } else {
        this.$emit('search', this.query)
        this.query = ''
      }
    }
  }
})

上記のsearchメソッドに対して、vue-function-testerでテストを書くと以下のようになります
(※ jest依存ライブラリなのでjestのテストコードになります。余談ですがメドピアのフロントエンドはjestでバシバシテストコードが書かれています。)

# SearchBox.spec.js
import SearchBox from "@/components/SearchBox.vue";
import { methods } from "vue-function-tester";

describe("search()", () => {
  const { search } = methods(SearchBox);

  describe("no query", () => {
    it("show error", () => {
      expect(search().run({ query: "", error: "" }).error).toBe("Please input.");
    });
  });

  describe("with query", () => {
    it("emits query", () => {
      const result = search().run({ query: "test", error: "" });
      expect(result.$emit).toBeCalledWith("search","test");
      expect(result.query).toBe("");
    });
  });
});

上記のようにsearchメソッドに対するテストを書くことができます。 lifecycle hooksやcomputedのテストに関しては以下をご覧ください。

https://github.com/pipopotamasu/vue-function-tester#lifecycle-hooks https://github.com/pipopotamasu/vue-function-tester#computed

vue-function-testerを作った背景

ただなんとなく作りたかっただけです。深い理由はありません。

(上記だとブログの長さ的に寂しくなりすぎるので、理由を無理やり捻り出しました。)

vue-function-testerを使わなくてもVueコンポーネントのメソッドのテストを書くことは可能です。 例えば...

• vue-test-utilsを使用する
• メソッド内の処理を別の関数として切り出してそちらをテストする
• VueオブジェクトもしくはVueコンストラクタからメソッドの参照を取り出しテストする

ざっと考えついただけ3つの方法がありますが、どれも良い面もあればそうでない面もあり、個人的にときめくものではありませんでした。

vue-test-utils

皆さんご存知の通り、既存のVue.jsのテストライブラリとして「vue-test-utils」という有名なライブラリがあります。
とても便利なライブラリで私ももちろん愛用させてもらっています。

しかしこれは「Vueコンポーネント」のテストにフォーカスしたライブラリです。 常日頃開発している身としては、「Vueコンポーネントのメソッド」にフォーカスしてテストを書きたい時にちょくちょく出くわします。
その場合、vue-test-utilsだとテストコードが冗長になってしまうことがあります。

• テストの度に毎回mountが必要
• mount時に初期設定が必要な場合がある
  • テストしたいメソッドとは関係のないpropsを用意する
  • created hooks用の設定
  • etc...

等々、Vueコンポーネントのメソッドテストをときめく感じに書きたいという欲を満たすことができませんでした。

VueオブジェクトもしくはVueコンストラクタからメソッドの参照を取り出しテストする

上記のサンプルコードを例にすると以下のような感じになります。

# SearchBox.spec.js
import SearchBox from "@/components/SearchBox.vue";

describe("search()", () => {
  const { search } = (SearchBox as any).options.methods;

  describe("no query", () => {
    it("show error", () => {
      const context = {
        query: "",
        error: ""
      }
      search.call(context);
      expect(context.error).toBe("Please input.");
    });
  });

  describe("with query", () => {
    it("emits query", () => {
      const context = {
        query: "test",
        error: "",
        $emit: jest.fn()
      }
      search.call(context);
      expect(context.$emit).toBeCalledWith("search", "test");
      expect(context.query).toBe("");
    });
  });
});

テスト自体は普通に書けるのですが、若干冗長さを感じてしまいます。え、私だけ...? 特に上記のコードで冗長と感じるのは以下の2点です。

• thisのcontextを別変数で宣言->メソッド実行->context変数の検証と、3ステップ踏まないといけない。
• $emitのモック作成。methodsやcomputedのsetterのテストを書いているとそこそこの頻度で$emitが出てくるのに毎回モックするのが面倒。

Vueコンポーネントのメソッドにフォーカスするという部分では問題ないのですが、上記の点でときめかない点が残りました。

メソッド内の処理を別の関数として切り出してそちらをテストする

そもそも別関数として切り出すというやり方です。
関数のインターフェースをcontextベース(this)ではなく、引数・返り値ベースでinput/outputを実装すればとてもテストしやすい関数になります。
(※ contextベースだと結局、contextを別変数で宣言->メソッド実行->context変数の検証と、3ステップ踏まないといけない)

export function sum(lfs, rhs) {
  return lfs + rhs;
}

export default Vue.extend({
  data() {
    return {
      lfs: 1,
      rhs: 2,
      result: 0
    };
  },
  methods: {
    sum() {
      this.result = sum(this.lfs, this.rhs);
    }
  }
});

簡単すぎる例ですが、上記のsum関数なら容易にテストできます。
特にロジックが長くなってくると、Vueコンポーネントのメソッドとして定義しておくとコンポーネント全体の視認性が悪化するので上記のような分割はとても良い手段です。

ただテストのために全てのロジックを外部の関数に切り出すのはどうでしょうか？ そもそも切り出すのがめんどくさいですし、切り出した関数のテストが正でも対象のVueコンポーネントのメソッドが正常に動くとは限りません。

こちらの手段も若干ときめかない部分が残りました。

vue-function-testerのときめくポイント

ではどうすればときめくのか、それはコードを短く書くことではないかと自問自答し、以下のコードを短くするときめきポイントを実装しました。

ときめきポイントその1: メソッドチェーン

以下のようにメソッドチェーンで繋げることで、ワンライナーで検証できるようにしました。

import { methods } from "vue-function-tester";
const { search } = methods(SearchBox);

expect(search().run({ query: "", error: "" }).error).toBe("Please input.");

ときめきポイントその2: alias

さらにaliasを貼り文字数を削減。

import { methods } from "vue-function-tester";
const { search } = methods(SearchBox);

// 通常
expect(search().run({ query: "", error: "" }).error).toBe("Please input.");
// aliasその1
expect(search().r({ query: "", error: "" }).error).toBe("Please input.");
// aliasその2
expect(search.run({ query: "", error: "" }).error).toBe("Please input.");
// aliasその3
expect(search.r({ query: "", error: "" }).error).toBe("Please input.");

※メソッドに引数を与えなければならない時はaliasその2とその3は使えません

ときめきポイントその3: $emit

使用頻度の高い$emitを事前にモック化

import { methods } from "vue-function-tester";
const { search } = methods(SearchBox);

expect(search.r({ query: "test", error: "" }).$emit).toBeCalledWith("search","test");

終わりに

このようにメドピアの開発合宿では自作のライブラリを作ったり、他のOSSにPRを送ったり、使ったことのない技術を使って何かしらのサービスを作ってみたり等々、参加者それぞれが自由に課題を設定しコードを書きます(年2回、水木金の2泊3日)。

今回で14回目の開発合宿となりましたが、まだまだ今後も続けていくので開発合宿をしたくなったら是非メドピアへ！

---

(☝︎ ՞ਊ ՞)☝︎是非読者になってください

---

メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております！

■募集ポジションはこちら

https://medpeer.co.jp/recruit/entry/

■開発環境はこちら

https://medpeer.co.jp/recruit/workplace/development.html