Misoca メンテナンス画面の裏側

Misoca の開発をしている id:mizukmb です。

先日、Misocaでは軽減税率8%の入力、および区分記載請求書の形式に対応しました。今回のリリースはシステム全体に関わる大規模なものとなったため、リリース作業中の時間はWeb・API・iOS/Androidアプリ全てのサービスを停止し、メンテナンス中としていました。

これまでMisocaではサービスを長時間停止させたメンテナンスやリリースをほとんど実施しておらず、メンテナンスモードを簡単に切り換える機能はありませんでした。加えて、今回のリリース作業の時間においては、下記を実現する必要がありました。

  • 一般ユーザからはMisocaサービスにアクセスさせたくない(メンテナンス中として見せたい)
  • 開発者など、特定の条件を見たすユーザの場合は、メンテナンス中でも本番環境にアクセスして動作確認ができるようにしたい
  • 外部連携するシステムによっては、メンテナンス中でもアクセスを止めたくない

そこで、今回のリリースに合わせて上記の要件を満たすメンテナンスモード機能を実装しました。本ブログでは、メンテナンスモード機能の紹介や、実際のメンテナンス画面などをお見せしていきたいと思います。

メンテナンスモードの仕様

メンテナンスモードの有効・無効の切り換え方法として以下の2パターンを用意しました。

  • スケジュール実行による有効・無効の切り換え
  • 手動による有効・無効の切り換え

メンテナンスモードの状態は上記2パターンをORで判定しています。ですので、どちらかが有効になっていればメンテナンスモードになりますし、どちらも無効にならない限りはメンテナンスモードは停止しません。

こうした仕組みにした理由は、メンテナンスの時間を延長した場合にスケジュールの時間を変更するよりも簡単にできるようにするためです。

また、メンテナンスモードの状態管理はRailsアプリケーションに持たせています。調査の段階では、ロードバランサで制御する方法も検討しましたが、先に述べた要件を満たすためには、現行のシステムでは実装コストが非常にかかるということが分かったので、Rails内で制御する方法に決定しました。1

設定方法

スケジュールの設定

メンテナンスモード設定用のYAMLファイルに時間を書きます。デプロイすると、指定した時間内はメンテナンスモードが有効になります。

開始・終了時間の設定は2つ以上設定できないようにしました。メンテナンス自体は頻繁に行われるものではないため、高機能にさせすぎず実装をシンプルに保つためです。

# メンテナンスモードの有効・無効を設定する
# `start_time` `end_time` に記述する日時のフォーマットは以下の通り。タイムゾーンはJSTとする
#   YYYY/MM/DD hh:mm:ss
production:
  start_time: 2019/06/18 05:00:00
  end_time: 2019/06/18 06:00:00

手動の設定

手動のON/OFFはThorタスクを使うようにしました。誤って使われないように、こちらの機能は実行できる権限を持つ人を限定しています。

特定ユーザのアクセスを許可するための設定

メンテナンス中に開発者を含む特定ユーザがアプリケーションにアクセスして動作確認できるように、ホワイトリスト方式でアクセスを許可するIPアドレスやHTTPヘッダを指定できるようにしました。

# メンテナンスモードの有効・無効を設定する
# `start_time` `end_time` に記述する日時のフォーマットは以下の通り。タイムゾーンはJSTとする
#   YYYY/MM/DD hh:mm:ss
production:
    (snip)
    ips: ['XXX.XXX.XXX.XXX', 'YYY.YYY.YYY.YYY']
    header:
      name: 'X-Foo-Bar'
      value: 'value'

これにより、前述の

  • 開発者など、特定の条件を見たすユーザの場合は、メンテナンス中でも本番環境にアクセスして動作確認ができるようにしたい
  • 外部連携するシステムによっては、メンテナンス中でもアクセスを止めたくない

を実現しました。

実際の様子

f:id:mizukmb:20190702145424p:plain
メンテナンス画面

全てのページで上記画面を表示するようにしました。メンテナンス情報は別ページを見てもらうようにリンクを貼っています。サービスによってはツイッターの公式アカウントを載せているところもあるみたいです。速報値を伝えるためにこうした情報は外に置いておくことが重要だと思います。

HTTPステータスコードは 503 Service Unavailable を返しています。

おわりに

メンテナンスモードの仕組みについて紹介しました。調査の段階で得た気付きとして、他サービスのメンテナンス画面を調べようとしてもそんな都合良くメンテナンス中のWebサービスは見つからないということです。Herokuがメンテナンスモード機能2を提供しているため、社内のHeroku上で動いているサービスをメンテナンスモードにして参考にしていました。

採用

Misocaのサービスをメンテナンスしてくれる人を募集しています。

recruit.misoca.jp


  1. 根本原因を解決することも検討しましたが、一旦スコープから外しました

  2. https://devcenter.heroku.com/articles/maintenance-mode

画像を使ったテストでリリースサイクルをあげる

こんにちは、MisocaでAndroidアプリを作っている @k0matatsu です。

MisocaのAndroidアプリではリリース前に通常10営業日のテスト期間を設けています。
おおよそ1ヶ月に1回リリースを行っているため、開発期間の半分がテストに費やされていることになり機能追加にさける時間が圧迫されています。

そこで、品質を落とさずにテスト期間を圧縮するために画像のdiffによるテストを導入しました。
これにより表示を確認するテストケースは大幅に削減できます。

spoonを使ったスクリーンショットの取得

f:id:komatatsu:20190624193113j:plain

画像のdiffによるテストを導入するためにspoonというソフトウェアを使いました。
これはAndroidの開発を行っている人にはポピュラーな選択肢だと思います。
この記事では詳しい使い方などは説明しませんが、ネットにたくさんの知見がありますので興味を持たれた方は調べてみてください。

espressoやUI Automatorを使って画面表示や遷移を行い撮影したい状況を作り、spoonを使ってキャプチャするという方法でスクリーンショットを撮影しています。
撮影されたスクリーンショットはdiffの比較がしやすいようにスクリプトでまとめています。
本当はreg-suitなどを使って見やすくしたかったのですが、最初から完璧をめざしているとなかなか導入できないので、ひとまずgithub上で見比べることができることをゴールとしました。

ほかにも次の点については導入段階では対応しない判断を行いました。

  • 通信処理のモック化
    • これはチャレンジしていたのですがハマってしまったので諦めました
    • スクリーンショットの撮影は日に何度も行うわけではないので決まった環境で実施する運用でカバーするものとします*1
  • 画面表示のバリエーション網羅
    • 税の設定や金額で多岐にわたるバリエーションがあるため断念しました
    • 徐々に範囲を拡大したいと思っています

一方で、テストの安定性については妥協せず進めました。
UIの絡むテストだと表示の待ち合わせなどで成功率がさがりがちですが、偶発的に失敗するテストは信頼感を損ないます。
テストが信頼できないと人間による確認の手間が発生してしまい、メリットが薄まってしまうのでこの点はこだわりました。
今はテストコードが原因で偶発的に失敗するようなテストはリポジトリにありません。

恩恵について

この画像のdiffによるテストが適用されたバージョンはまだ開発中なので具体的に何日短縮できたのかはまだ明らかになっていませんが、多くのテストケースが削減できそうなので期待を寄せています。
テスト工数の削減はリリースサイクルをあげるだけでなく、人間でないと判断が難しい作業にリソースを集中させられるメリットがあります。
UIテストにおいてテストケースのメンテナンスコストがよく問題視されますが、毎バージョン変更が入るような画面はほとんど無いはずです。
テストが自動化されることで些細な変更でも「変更した部分だけ確認しよう」ではなく、すべてのテストケースを確認しやすくなります。
このような変化が品質の底上げにつながると信じています。

MisocaのAndroidアプリもカバレッジはまだまだ低いですが、効果の高い部分から地道に自動テストの範囲を拡大しています。
私はこういった基盤的な作業が好きなのですがMisocaにはAndroidエンジニアは私しかおらず、普段はサーバーサイドエンジニアに手伝って貰っています。
たしかに品質も大事なのですが、フリーランスの商取引における課題はまだまだ山積しています。
これらの課題を解決し、フリーランスの方々が安心して自分の業務に集中できる環境を構築すべく新たな機能の設計開発にももっともっと取り組みたいと思っています。

Misocaでは私の背を守りバリバリと価値を形にしてくれるAndroidエンジニアを募集しています。

recruit.misoca.jp

Twitterなどでお声がけいただければ普段の様子などお話できますのでぜひご気軽ににお声がけください。

追記: テスト対象とした画面について

Twitterにて対象とする画面について質問がきたのでこちらに追記します 。

画像のdiffによるテストの導入は普段の作業の合間に少しずつ進めていました。
この作業に割ける時間は少なかったので、テストを書いてもすぐ修正することにならないように、変更頻度の低そうな設定画面のキャプチャからはじめました。
次いで全画面のファーストビューのスクリーンショットを撮ろうとしているのが今の状態です。
今後は再現させるのが難しいエラーの表示から優先的に範囲を広げていこうと思っています。
これは元の目的がテスト期間の削減なので、簡単にテストできる正常系よりも再現手順の面倒な準正常系を自動化したほうがテスターの負荷がさげられると考えているためです。

*1:ユニットテストは既にモック化されているのでこの判断になりました

名古屋Ruby会議04登壇 & もくテク開催のお知らせ

こんにちは、Misoca開発チームの@kokuyouです。

最近HitogataでVRアバター出社をはじめました。

f:id:kokuyouwind:20190605155611p:plain

上段真ん中でキラッ☆としてるのが自分です。

かわいい女の子になれて楽しいのですが、Windowsでしか動かず作業用Macと2台体制になってしまうのが地味に不便です。WSL2が来たらWindowsにちゃんと開発環境を構築しようかな…

名古屋Ruby会議04

もう今週末に迫ってしまいましたが、6月8日に大須演芸場で名古屋Ruby会議04が開催されます。

f:id:kokuyouwind:20190605164528p:plain

自分が「入門 関数型-ish プログラミング on Ruby 」という胡乱なセッション名で登壇するほか、Misocaから他に@KawamataRyoがスポンサーLTを行います。他の登壇者の方々も豪華メンバーですね。

前回の名古屋RubyKaigi03も大須演芸場で開催されたのですが、登壇者のめくりがあったり、2階席が椅子ではなく桟敷席になっていたりと、独特の雰囲気で非常に面白いです。

すでに枠が埋まってしまっていますが… 当日までに枠が空く可能性もありますので、未登録の方はよければキャンセル待ちにご登録いただければと思います。

会場で会えるのを楽しみにしております。大須演芸場で僕と握手!

もくテクpowered by Misoca #1 リモートワーク座談会

そしてそして、明けた木曜日の6月13日には、もくテクpowered by Misoca #1 リモートワーク座談会が開催されます。

f:id:kokuyouwind:20190605164410p:plain

こちらは名前の通り、Misoca主催の勉強会です。もくテクは弥生株式会社が1年以上主催しているものですが、今回はそれのMisoca主催バージョンになります。

毎回いろいろなトークテーマを取り上げていく予定で、初回は「リモートワーク座談会」です。リモートワークに関するあれこれを、Misocaのメンバー数名でパネルディスカッションする形になっています。

会場も秋葉原・名古屋・松江・富山と各地から参加でき、さらにはYoutube Live配信もありと、リモートワークをある意味体現したものになっています。

こちらもよろしければぜひお越しください。

宣伝

Misocaではコミュニティイベントを盛り上げていきたい 方を募集しています!

www.wantedly.com

『入門 監視』社内読書会を開催しました

2019年1月〜5月上旬の間、『入門 監視』という本の社内読書会を週一で開催しました。

www.oreilly.co.jp

今回は、社内読書会開催に至ったきっかけや実際の進め方、社内読書会を通じての学びやその後のアクションについてお話したいと思います。

社内読書会をはじめたきっかけ

この本が予約開始になった時に、目次を読んで内容に興味を持ったことと、社内でも展開できれば今以上に開発チームとして監視についての十分な知識や体制が作れるかも、と思ったのがきっかけです。

任意参加にして、毎週金曜の18時から一時間程度で読書会をやりましょうと社内で参加者を募り、本が発売したその週から社内読書会を開催しました。

社内読書会の進め方

ざっくり、以下の流れで進めました。

  • 本を黙読する (35分くらい)
    • 毎回、1章ずつ読み進めていた
  • 参加者から一言ずつ感想をもらう (5分くらい)
  • 参加者全体による感想戦 (適当に満足するまで)

気軽に参加できることを目標に、事前に読んでおくということはしませんでした (もちろん個人でどんどん読み進めるのはOK) 。

また、弊社では名古屋・松江オフィス勤務だけでなく親会社である弥生本社(東京秋葉原)や自宅からのリモートワークで各地から仕事をしてる社員もいることを考慮して、Zoomを使ったビデオ通話で集まるようにしました。普段のミーティングも基本ビデオ通話なので、特に違和感なく進められました。

さて、本を黙読する と書きましたが、もくもくと読み進めている中で、実はとある場所でメンバー同士議論や感想を交わしていたのでした。

Scrapboxを活用した非同期かつ互いに干渉しない読書と議論の両立

その場所とはScrapboxというドキュメントサービスです。

本の内容に関する感想や疑問に思ったことなどは、Scrapboxのプロジェクトページに参加者みんなで書き込むようにしました。

scrapbox.io

Scrapboxを採用した理由としては

  • 複数人のリアルタイム編集ができる
  • 箇条書きが書きやすく、メモやコメントに良さそう
  • テキストベースにしてオフィス・リモート間のコミュニケーションコストを統一させる
    • 口頭ベースだとどうしても物理にいる人同士がつよくなってしまいがちなので

があり、黙々と読みつつ分からなかったり気になったことはScrapboxにみんなで書き込むというスタイルは読書会と相性が良いのではないかと思ったからです。

また、/shokai/ぜんぜんわからん分野をゆるく読書会する という記事の中でScrapboxを使った読書会について書かれていて、うまく活用できるような雰囲気を感じ取りました。

実際に使ってみると、読書中はみんな黙って本を読んでいるので集中できるし、でも実際はScrapbox上で気になったことを書いていたり、質問を書く・回答するといったことが行われていて、読書会として非常に新鮮な体験で、快適に読書を続けられることができました。

ビデオ通話だと小さな声で近くの人に相談するということが難しく(マイクを通して話すとどうしても音量が大きくなる)、読書に集中してる人の邪魔をしたくない気持ちから口頭ベースの相談や感想がやりにくくなってしまいます。テキストベースにすることでこうした問題を解消でき、数あるドキュメントツールの中でも同時編集可能・気軽に箇条書きで書ける特徴を持ったScrapboxは読書会にはピッタリなツールであったと個人的には思いました。

f:id:mizukmb:20190529134212p:plain
メモの一部。このようにアイコンを後ろに付けることで会話してる雰囲気が出て楽しい

学び、アクション

最初は、インフラ分野にちょっとだけ興味があるのでまあ読んでおくかぐらいの気持ちでいたのですが、読み終わると、特に私達のようなWEBサービスを開発・運用する開発者たちは、フロントやアプリケーションといった領域を問わず読んで損はない内容だなと思いました。

なかでもビジネスの観点で監視をするという視点は、目から鱗の内容でした。ビジネスと連動させてアプリケーションやサーバの状態を見るということに気付けたことが個人的には本を読んだ中で一番良かったかなと思います。

また、読み終えた後に何かアクションにつなげていきたいと思い、以前からやろうと構想していた『Mackerelのグラフにアプリケーションのリリース日時を記録する』を導入してみました。これは、『7章 アプリケーション監視』にある ビルドとリリースとパイプラインの監視 を実行に移したものになります。

f:id:mizukmb:20190528202433p:plain
構想を書いた社内のesa記事

終わりに

入門 監視という本の社内読書会の開催とその進め方、学びやアクションについて書きました。

全体のページ数も多くなく、『入門』というタイトルにふさわしい良い一冊であると思います。

採用

監視や読書が好きな方を募集しています。

www.wantedly.com

「Misocaのリモートワーク」を支える仕組み

こんにちは。 今年4月にMisocaにジョインしました@KawamataRyoです。

最初に自己紹介を。
少し変わったキャリアで消防士歴が6年、エンジニア歴は1年と半年です。*1
入社後は、こちらの記事のTypeScript化や、開発合宿の副産物(Print.jsを使った印刷ダイアログ表示)のリリースを行ったりしていました。
今は茨城県からフルリモートで開発をしています。

リモートワークはメリットだけではなくネガティブな意見を聞くこともあります。
私自身、エンジニアとしての経験が浅いだけに入社前はリモートワークに不安がありました。
ですが、今はとても充実した開発ライフを送っています。
それもMisocaのリモートワークの仕組みのおかげだと思ったので、今回紹介します。

f:id:ba068082:20190523062444j:plain
昼休みに走っている家の近所のランニングコース。どこまでも続く田んぼ道。

常時接続のWebミーティング

出勤から退勤までZoomのwebミーティグRoomに常時接続しています。
こちらのRoomは名古屋オフィスにも繋がっており、常にオフィスの様子が見られます。
  
「リモートワーク = 孤独」というイメージが強かったのですが、Misocaの場合はそんな事はないですね。
顔の見れる関係?なので、詰まった時なども気軽に質問しやすいです。

f:id:ba068082:20190523134356p:plain

ペアプロ・モブプロ文化

Misocaはペアプロ・モブプロが盛んでワイワイ開発しています。
入社前はもっと黙々と開発すると思っていたのですが、 自宅にいる妻に「仕事中なのに、笑いすぎじゃない??」と小言いわれるほどワイワイしてます。

主に2〜4人でZoomに繋いでプログラミングすることが多いです。
あとはVSCodeのLiveShareを使ったりもします。
モブ・ペアでやることで初期キャッチアップのコスト削減、コードの属人化の排除など利点が多いなと思いました。
もちろんずっと繋いでいるわけではなく、一人で黙々と開発する時間も十分あります。

f:id:ba068082:20190523135940j:plain

今の気持ちを共有する分報

current_(名前)というslackチャネルを開設し、その時思ったことなどを随時共有しています。*2
そちらでつぶやいた内容は、全員がメンバーに入っているcurrent_allチャネルに流れ、そこで皆の今の状況がわかります。
こちらのつぶやきから詰まっている状況が共有され、ペアプロ・ペアオペに発展していくなどもあります。
あとはここから始まる雑談も多いですね。 リモートワークのつらみとして「雑談できなくて辛い」というのを聞くことがありますが、Misocaでそれを感じたことはないです。

f:id:ba068082:20190523155152j:plain

毎日の朝会・週次の振り返り(KPT)

毎日、全員参加の朝会があり連絡・相談事項の共有などを行います。
(11:30から開催なので、もはや昼会な気もしますが。。)
前述した常時接続のZoomで行います。
以前の記事でも紹介した通り、タスク管理ツールのTrelloを使い効率的に進めています。

またプロジェクトごとに週次の振り返り(KPT)もあり、問題点の共有、改善策の提案なども行っています。

f:id:ba068082:20190523160530j:plain

誰でもどこでも働ける会社

物理オフィスが名古屋と松江、東京(弥生オフィスの一部スペース)にあり、いつでもそちらへの通勤が可能です。
Misocaはリモートワークの会社というより、誰でもどこでも働ける会社というのが正しいですね。
また、年に一度の全員オフ会の時は、名古屋オフィスに皆で集合します。
今年の全員オフ会は、こちらの記事で紹介されています。

f:id:ba068082:20190522091954j:plain
全員オフ会時の名古屋オフィス。この後皆で紙飛行機ワークショップを行いました。

おわりに

以上、Misocaのリモートワークを支える仕組みでした。

来る6月13日19時30〜から、「もくテク powerd by Misoca」にてリモートワークの座談会を行います。
東京、名古屋、松江、富山サテライト会場(自宅)の4拠点から、普段の仕事の感じでZoomのRoomに集合してパネルディスカッションを行います。

今回の記事で紹介した内容以外にも、リモートワークを効率的に進める知見など幅広く共有できると思うので、ぜひ興味あればご参加ください。(私もリアルで登壇します)

mokuteku.connpass.com

Misocaではリモートワークでも幸せに働きたいエンジニアを募集中です。

www.wantedly.com

*1:詳しいキャリアはこちらよりhttps://note.mu/ryo_kawamata/n/n4fc0fa900314

*2:分報が必須なわけではないです

Misoca❤️TypeScript

こんにちは、@mugi_unoです。

GWはリスと遊んできました。たのしかったです。

f:id:mugi1:20190504123132j:plain:w500


さて、長きに渡ってコツコツと手を入れてきたMisocaのフロントエンドですが、 先日、新たに大きな改善を行いました。

f:id:mugi1:20190513182316p:plain:w600

というわけで、令和一発目のエントリーは MisocaのフロントエンドにTypeScriptを導入したお話です。

🤔なぜTypeScriptを?

金額処理触るの怖すぎ問題

Misocaは請求書の発行・管理サービスという性質上、各所で金額に関する処理があります。 そして、最近はさまざまな事情により修正が頻繁に行われていました。 以前のエントリでもご紹介したレガシーコードのリファクタリングなども該当します。

tech.misoca.jp

エンジニアの方なら「おおぅ...」となりそうですが、金額を触る処理というのは怖いものです。 そしてフロントエンドが絡んでくると「ここは文字列?数値?」といった疑心暗鬼も発生し、気軽に足し算もできません。

そのため、機能修正やリファクタリングを行うにあたって、あらかじめ大量のテストコードを用意するなど、安全のために多くのコストが発生していました。

そのようなテストコードや目視確認といった手法で安全を確保するアプローチに対し、TypeScriptなどの型システムによるアプローチでは、設定や記述によっては完全にすべての値や計算結果を保証することはできないとはいえ、「ある程度」は静的なチェックで保証することができます。

今後も似たような変更をする状況は容易に想像できますので、つらさを感じてから出来るだけ早いうちに、 そのつらさを解消するための仕組みを入れておいたほうがいいと判断しました。

時代の流れにもちゃんと乗りたい

「そんな理由で!」と怒られそうですが、 個人的には「世の中の流行りを追う」も技術選定において重要な要素だと考えています。

一瞬の流行りに飛びつくと怪我をするので慎重さも必要ではありますが、 トレンドとなっている技術を利用することで開発者(主に私かもしれない)のモチベーションが上がりますし、 そこから発展した新しい技術要素が登場した場合にも検証・導入しやすくなります。

主観ですが、最近のフロントエンドではTypeScriptが主流になっている感覚があり、 「Misocaでも追従すべきだろうな」と以前から考えていました。

そんな中、上記の金額処理怖い問題も重なり「やるか!」と決意したのでした。

💪TypeScript導入のながれ

実験用PRを作ってみる

何はともあれ、一旦実験用PRを作ってみました。

f:id:mugi1:20190513182858p:plain:w500

方針を決める前に、現状のコードベースにTypeScriptを導入した場合にどういったことが起きるのかを知るのが目的です。 最終的にはこのPRがそのままマージされましたが、試しに小さく一回やってみるのは大事ですよね。

方針をきめる

TypeScript導入時に意見が大きく分かれそうなのが、noImplicitAny の存在ではないでしょうか。 型が不明な場合にany型に推論させるかどうかという設定です。

これを無効化することは敗北だという意見を目にしたこともあります。

私も最初は「型でバッチリ固めて守るぞ〜!」と意気込んでいましたが、 上記の実験用PRを作ってみたところスクロールしきれないほどのエラーが噴出し、「あっ、これ無理だわ!!」 と感じたので noImplicitAnyはfalse(any型に推論させる)ではじめることにしました。 また、noImplicitAnyに限らず、基本的にanyの利用は禁止しないことにしています。

このあたりはSlackなどでチームメンバーとも相談し

  • any推論を許容しても、自動推論で受けられる恩恵は十分大きい
  • まずは全体をTypeScriptコンパイルが通っている状態にすること自体が大事
  • 徐々に型を整えていって固めていけばいい
  • それでも現状と比べると遥かに良くなる

といった考えに基づいています。

@t_snzkさんや@__gfx__さんの提唱されている「がんばらないTypeScript*1」も参考にさせていただきました。(ありがとうございます!)

なお、strict オプション自体は trueのままで、noImplicitAny以外のstrict関連のオプションはすべて有効化した状態でスタートしました。 これも実際に有効にして型チェックを通してみた結果「これぐらいならサクっと対応できそうだな」という肌感を得ての判断でした。

ADRを書く

Misocaでは開発時の意思決定をADR(Architecture Decision Records)*2という形でソースコードと一緒にドキュメント化して残しています。

いきなりTypeScriptを導入するのではなく

  • 現在はどういった背景事情があるのか
  • なぜ導入するのか
  • どういった形で導入するのか
  • 何が変わり、何が影響を受けるのか
  • どういったメリット・デメリットがあるのか

といった情報を整理して残しておくことで、問題意識の共有もできますし、 後から新しく入ったメンバーも過去の意思決定を遡って知ることができます。

参考までに、実際のADRをまるごと貼っておきます。

(内部共有仕様なので、もし不備とかがあったら見逃してください。)

f:id:mugi1:20190514181547p:plain:w700 f:id:mugi1:20190514181600p:plain:w700

実験PRを通して見えてきたさまざまな方針をADRとして整理し、PR上でチームでレビューした内容が反映されています。

テストコードから対応していく

方針が決まったので、まずはテストコードから置き換えを行いました。

テストコードなので本番への影響もほぼありませんし、 わりと単純なコードが多いので差分の理解もしやすいです。 作業者自身だけでなく、レビュワーの目を慣らすためにもテストの書き換えから行うのはアリでしょう。

Vue.jsをどうしたか

Vue.jsでTypeScriptの恩恵を受けるため、

を導入し、クラス&デコレータを利用した形に全コンポーネントを書き換えることにしました。

Vue&TypeScript導入方法は、Vue.extends を利用する方法もありますが、 この場合は型で保証できる範囲に一部制約が発生します。 どうしようか悩みましたが、Propsはしっかり型で守りたいな〜と考えていたため、 vue-property-decorator を使うことにしました。

実際置き換えをやってみるとなかなか大変で、クラスコンポーネント形式固有で注意すべき挙動なども対応していく中で踏み抜きました。 このあたりは知見として、最終的にはesaにガイドラインとして整理しておきました。

(踏み抜いたundefinedによる初期化に関する記録の例)

f:id:mugi1:20190514115531p:plain:w600

エンジニアへの知見共有

全体をTypeScript化するにあたって、コード自体の変更だけではなく、 エンジニア全体への知見の共有も併せて検討していかねばなりません。

TypeScript自体は良いものだと思いますが、 今まで利用していなかったのであれば、もちろん学習コストが発生します。

そこで、作業時には常に社内でライブ配信することにしました。

f:id:mugi1:20190513184638p:plain:w400

変更前後をリアルタイムで比較することができますし、 何よりも修正と共有がまとめて出来てお得ですね!

終わった後は学びを簡単にまとめてみるなど、なかなかよい試みでした。

f:id:mugi1:20190513184919p:plain:w400

🏃‍♀️プロジェクト化して一気にゴールまで走る

コツコツと一人で書き換えを続けていましたが、 残り40〜50%程度になった段階で@KawamataRyoがJoinし、 二人でプロジェクト化して一気にすべてを片付けることにしました。

f:id:mugi1:20190513185326p:plain:w500

そこからはおおよそ一ヶ月弱程度で、すべてのJSファイルをTypeScriptに書き換えることができました!

🎉TypeScript化(ひとまず)完了

というわけで、anyを使って緩めている箇所は残っていますが、無事全体をTypeScript化することに成功しました。 現在は新たにフロントエンドのコードを書く場合はすべてTypeScriptを利用しています。

VSCodeでコードを書いているときにメソッドや引数の補完が出るのもありがたいですし、 単純なタイポも即座に指摘してくれているので非常に快適です。

がんばってよかった!

次の課題

いや〜、導入できてよかったよかった、と言いたいところですが、課題は残っています。

やはり最大の問題はanyで、noImplicitAnyを無効化しているのに加えて、ひとまずany定義をして逃げたコードも多く残っています。 直近でやるべき作業は次のようなものかな〜と考えています。

  • noImplicitAnyの有効化
  • anyはunknown型利用に置き換え

理想の構成を手に入れるまで、引き続きコツコツやっていきたいと思います💪

...というわけで!

採用

Misocaではコツコツ改善するのが好きなエンジニアを募集しております!

www.wantedly.com

#RubyKaigi 2019 に参加して屋台メシを食べてきました

こんにちは Misoca 開発チームの id:mallowlabs です。 RubyKaigi 2019 に参加してきたのでその報告をしたいと思います。 私個人としては、RubyKaigi は初参加でした。

ちなみに Misoca は RubyKaigi 2019 の Silver スポンサーです!

f:id:mallowlabs:20190422172543j:plain

開催地

今回は福岡での開催でした。 福岡の屋台でとんこつラーメンを食べれたらいいな…と思いつつ参加したら、ランチスポンサーがまさかの屋台提供で驚きました。

他にも初日の Official Party の会場が商店街全体だったり、初参加の私は RubyKaigi のスケール感に驚くことが多かったです。

#findmisoca キャンペーン

tech.misoca.jp

事前に告知させて頂いたとおり、昨年同様に御朱印帳風のステッカー帳をノベルティとして配布しました。 今年は更に Misoca 社員が「福岡」「名古屋」「東京」「松江」の各地のステッカーを持ち、探してもらうことで、スタンプラリーの要素も追加するという試みも行いました。

Twitter で #findmisoca を検索する と楽しんでいただけた方も多かったようで嬉しく思います。 私は「東京」ステッカーを持ってウロウロしていたのですが、「名古屋ですか?」「いえ、東京です、名古屋の人はさっき二階に行きましたよ」という RPG の村人のようなコミュニケーションが発生して面白かったです。 お話させていただいた参加者のみなさま、ありがとうございました!

4つ揃えたら何が起こるかは別の機会に発表予定です、お楽しみに!

セッション

どのセッションも面白かったですが、個人的に興味深かったセッションを紹介します。

State of Sorbet: A Type Checker for Ruby

Stripe 社を中心に開発が進められている Ruby 向けの型チェッカーである Sorbet の紹介です。 Stripe 社ではヘビーに使われているようで、かなり実用段階にある印象を受けました。 発表の目次の時点で「Announcements」という文字があり、ここで公開されるのでは…?とドキドキしていましたが、オープンソース化は2019年の夏だそうです。 楽しみですね。

発表スライドはこちら

Crystalball: predicting test failures

Rails の特定のファイルを編集した際に、影響がありそうな spec ファイルを自動で特定してそれだけを実行できる gem の Crystalball の紹介です。 Misoca はテストをしっかり書く文化があるので、テストの数がとても多く、このような gem を使うことでテスト駆動開発がより快適に行えそうという印象を受けました。

発表スライドはこちら

Cleaning up a huge ruby application

クックパッドの巨大なアプリケーションの中の未使用コードを特定するために Ruby 2.6 から導入された Oneshot Coverage という仕組みを使って、5万行以上のコードを削除した事例の紹介です。 Misoca のコードも、クックパッドほどではないですが、そこそこに大きくなっているので、Oneshot Coverage を使って未使用コードを特定したいと思いました。

発表スライドはこちら

次回の開催地

次回の RubyKaigi2020 の開催地は松本だそうです。

これは Matsumoto が Nice な街かどうかを確認しに行く必要がありますね。 来年の RubyKaigi でお会いしましょう!

採用

Misoca では RubyKaigi 等の勉強会参加費・交通費が支給されます! Misoca では会社のお金で RubyKaigi に行きたいエンジニアを募集しています!

www.wantedly.com