トレタ開発者ブログ

飲食店向け予約/顧客台帳サービス「トレタ」、モバイルオーダー「トレタO/X」などを運営するトレタの開発メンバーによるブログです。

「データサイエンティスト協会3rdシンポジウム」に参加しました

f:id:serihiro:20161018145628p:plain

トレタのAPIをメンテしている芹沢です。
2016年10月14に開催されたデータサイエンティスト協会3rdシンポジウムに参加してきたので本シンポジウムの発表内容を簡単にご紹介します。

発表内容について

産学問わず様々な登壇者があつまっており、私は以下のセッションを拝聴させていただきました。

  • 「計算機視覚技術:人工知能の古くからの問題と新たな可能性」
  • データサイエンスアワード2016 最終プレゼンテーション
  • 「実務者達のデータサイエンティスト「業」 フリートークセッション~結局、実際の業務やデータ分析チームで必要なスキルって何?~」
  • 「統計学・計算機・データサイエンス」
  • 「滋賀大学データサイエンス学部で学ぶこと」
  • 「限られた情報から精度良く:機械学習技術の最近の発展」

自分自身の統計学や機械学習のスキルは嗜み程度なのであまり専門的なことは理解できませんでしたが、その中でも 「統計学・計算機・データサイエンス」 のプログラムが印象的でした。

本プログラムでは、2009年にgoogleがインフルエンザ流行予測を行うために立ち上げたGoogle Flu Trendsの予測結果と、米国政府が発表したデータを組み合わせて新たな予測モデルを作ったところ、Google Flu Trendsより正答率の高い予測モデルを実現できたという事例を元に、古典的な統計学とビッグデータ・機械学習とがどのように関わっていくべきかについて語られていました。古典的な統計学と機械学習を勉強中の身としては非常に考えさせられるものがありました。(Google Flu Trendsについては2013年出版の『ビッグデータの正体』という書籍で詳しく説明されているそうなので後で読んでみます)

その他、実際にデータ分析サービスを提供している企業の方々によるパネルディスカッションもあり、実務的な側面と学問的な側面から多くのことを学べたイベントでした。

トレタのカンファレンス参加補助制度について

話は変わりますが、トレタにはカンファレンス参加補助制度があります。具体的には、会場までの交通費(海外の場合は渡航費含む)とカンファレンス参加費を会社で負担する制度です。
この制度を使って過去にWWDC16hashiconf2015に弊社エンジニアが参加しています。今回もこの制度を利用して参加してきました。ありがたいことです。

トレタは飲食店の予約・顧客データから新たな価値を生み出す仲間を募集します

さて、さすがに業務と何も関係がないカンファレンスに会社のお金で行かせてもらえるほど世の中甘くない訳でして、今回自分が本シンポジウムに参加したのもちゃんとした業務上の理由があります。

トレタでは、現在トレタのサービスに蓄積された予約情報・顧客情報を用いて新たな価値を提供する方法を模索しています。
具体的には、過去の予約情報から学習して店舗の運用に活かしたり、店舗を予約するお客様の情報から効果的なお店のPRにつながるアクションをサポートするような機能を提供できないか、といったことを考えています。

しかしながら、トレタには現在機械学習のスキルを持った社員がいない状況です。。私が普段のRails業の合間にその手の実現可能性について考えたりもしているのですが、さすがに手が足りません。

そこで、機械学習を用いて新たな価値を生み出すスキルを持った仲間を募集します!
正式なポジションとしてはまだ募集を開始していませんが、機械学習で飲食業界に貢献するチャレンジに興味のある方は、お気軽に採用問い合わせフォームからお問い合わせください。

Rubyを2.0から2.3にバージョンアップした効果とか

インフラをチョメチョメしている佐野です。今日はRubyを現最新バージョンの2.3.1にアップデートしたのでその効果について書きます(2.0、とっくにEOLですしね...)。gemのバージョンアップはserizawaニキがやってくれました。結論から言いますと、

  • CPU使用率が劇的に下がり、メモリ使用率が少し上がった。
  • サーバ台数削減できる。

です。

CPU

f:id:hiroakis:20160907163559p:plain

9/6の昼過ぎくらいに2.3に切り替えたのですがそれ以降、CPUが下がっていることがわかります。

メモリ

メモリについては使用率が上がっています。

  • 2.3

f:id:hiroakis:20160907163610p:plain

  • 2.0

f:id:hiroakis:20160907163625p:plain

何が使っているのかというと、Ruby2.3なプロセスのメモリ使用量が全体的に増えました。次のtopコマンドは左ペインが2.3、右ペインが2.0なのですが、rubyないしbundleとなっているものがunicorn, sidekiqになります。これら全般的に2.3の方がメモリ使用量が多いです。 ちょっと気にしていたら、TLにてhttps://github.com/ko1/nakayoshi_forkなるものがあると教えていただいたのですが、まだ試していません。

f:id:hiroakis:20160907163546p:plain

性能

簡易的に測定しました。ヘルスチェックパス(DBアクセスあり)に10000発のHTTP GETを投げてみた際の処理時間です(3回ほど試行)。2.3選手の方が3回ともかなり早い結果となりました。

  • 2.3
counts: 10000 total time: 120.01s
counts: 10000 total time: 128.66s
counts: 10000 total time: 120.59s
  • 2.0
counts: 10000 total time: 207.34s
counts: 10000 total time: 199.82s
counts: 10000 total time: 230.72s

なのでバージョンageていったらいいと思います。簡単ですが以上です。

おわり

Excelなテスト仕様書をMarkdown/GitHub/CircleCIに移行した話

こんにちは、QAエンジニアの井上恵一です。好きな飲み物は一番搾りと韃靼そば茶です。

初回からニッチなネタではありますが、昨年入社した直後に行った、 iPad アプリのテスト仕様書の管理方法を見直したときの話を紹介しようと思います。

見直しのきっかけ

トレタは飲食店向けの予約/顧客台帳アプリです。だれでもかんたんに使いこなせるシンプルさを追求してはいますが、製品の進化に伴ってそのテストケース数はすでに数千という単位にまで膨れあがっています。

製品の品質を安定させるためには、テストの内容自体をブラッシュアップすることが重要なのは言うまでもありません。ただ、安定した製品を永続的に提供していくためには、それに加えて、膨大なテストケースを効率よくメンテナンスし続けるためのプロセス作りも欠かせません。

入社のタイミングでトレタのテスト設計を担当することになったので、テストケースの管理方法についてもいちから見直すことにしました。

当時の問題点

当時、トレタのテスト仕様書は Excel で管理されていました。 Excel は閲覧性が高くテスト仕様書の管理ツールとしても一般的ですが、テストケース管理という意味では不便を感じることがあります。たとえば、こんなところです。

  • そもそも手元に Office が無いとテストケースの閲覧・メンテナンスができない
  • バイナリファイルなので git などでバージョン管理しにくい
  • 複数人で共同編集しにくい
  • テストケースのレビューがしにくい
  • テストケースの変更履歴や変更の経緯を残しにくい

今後テストケース数も関わる人も増えていく予定だったので、メンテナンスしやすく継続しやすい管理方法を検討することにしました。

Excel から Markdown へ

もろもろ検討した結果、Excel ではなく Markdown (GFM) 形式で記述して、プロダクトのコードと同じように GitHub 上で管理してみることにしました。そうすることで、

  • テキストエディタでどこでも気軽に編集できる
  • テキストファイルなので GitHub でバージョン管理・変更管理がしやすい
  • 複数人で同じファイルを編集しても git がよしなにマージしてくれる
  • Pull Request を使ってテストケースのレビューを行える
  • プロダクトの Issue/PR とテストケース変更の Issue/PR を紐付けておくことで、テストケース変更の経緯を後から git blame で追いかけることができる

といった効果が狙えます。記述ルールは、GitHub のプレビュー上でもそれっぽく見えるように下記のようにしてみました。

記述ルール

  • 大項目(画面名) : h2
  • 中項目(機能名) : h3
  • テスト内容: li
  • 確認内容 : checkbox

書き方の例

## ログイン画面

### ログイン機能
- 正しいメールアドレスとパスワードを入力してログインボタンをタップする
  - [ ] ホーム画面に遷移する

GitHub での表示

f:id:dreamagicjp:20160705014751p:plain

テスト実行時は Spreadsheet で

テストケースを管理する際は Markdown の方が扱いやすいですが、いざテストを実行する時は Excel 的な形式の方が一覧して見やすく、テスト時に気付いたことをメモとして残したりもできて、何かと便利なことがあります。そこで、Markdown 形式のテストケースを Google Spreadsheet に変換するための仕組みも準備しました。

具体的には、テストケースを GitHub に push したときに CircleCI で構文をチェックしつつ OK だったら、 google_drive gem で Google Spreadsheet に展開するようにしています。こんな流れです。

デプロイの流れ

f:id:dreamagicjp:20160705021057p:plain

Spreadsheet 上の表示

f:id:dreamagicjp:20160705143345p:plain

たかがテストケース管理だけのためには少々大げさかもしれませんが、これによってひとつのテストケースを Markdown 形式でも Spreadsheet 形式でも参照できるようになり、テストの編集時と実行時とで形式を使い分けることができるようになりました。

さいごに

今回は、テストケース管理について紹介しました。今後また、テストプロセス、テスト自動化への取り組み、CIまわりの取り組みなどこの場でお話できればと思っています。

そしてお約束。トレタは iPad アプリを Swift に移行しつつ、Testability の高い設計・コードに書き換えている真っ只中にあります。iOS エンジニア絶賛募集していますので、ご興味があれば一度オフィスに遊びにきてみてください。

© Toreta, Inc.

Powered by Hatena Blog