トレタ開発者ブログ

飲食店向け予約/顧客台帳サービス「トレタ」、超直前予約アプリ「トレタnow」を開発・提供するスタートアップ企業です。

builderscon tokyo 2019に行ってきました

こんにちは!サーバーサイドエンジニアの川村です。
8/29(金)〜31(日)に行われたbuilderscon tokyo 2019に行ってきたので、(気づいたら丸1ヶ月経ってしまいましたが)その感想を書いていきます。

builderscon?

buildersconは、「知らなかった、を聞く」をテーマとした技術を愛する全てのギーク達のお祭りです

公式サイトより

言語などの縛りなしに技術で色々やってみた話をきく会となっており、色々な方向性の話があって楽しいカンファレンスでした。
今回、トレタは懇親会スポンサーとなっており、↓の2つのカクテルを提供させて頂きました。
(会場では手違いで名前が逆になっていたのは内緒です)

f:id:yosinani4472:20191002163906j:plain toreta on rails

f:id:yosinani4472:20191002163914j:plain toreta on kubernetes

私は所用で懇親会に出れなかったのでどんな感じの味だったのか分からないのですが、楽しんでいただけていたら嬉しいです!

印象的なセッション

今回聞いたセッションの中で特に印象に残っている3つについて紹介します。

8/30 13:20〜 コンパイラをつくってみよう

goでコンパイラをライブコーディングするセッション。

1時間の講演時間中に四則演算のコンパイルができるようにすることを目標に、 標準入力からソースを受け取ってgccで実行できるアセンブリを出力、パイプで渡して実行してみるという内容でした。

10回以上リハーサルを重ねただけあり、コーディングのスピードもすさまじく、バグったときに会場のいろんな人がどこが間違ってるかその場で指摘していく暖かみもいままでに見たことが無い光景で非常に印象的でした。

動画が公開されたらぜひ見て欲しいセッションです。

8/31 13:00〜 スーパーカミオカンデの開発と運用

ニュートリノ検出の実験装置、スーパーカミオカンデを構築・運用していく際の苦労などについてのセッション。

例えば、

  • 1万本のセンサー(光電子増倍管)から全く同時に値を受け取らないといけないが、ケーブルの長さが少し違うだけでタイミングがずれるので位置に関係なく全てのケーブルの長さが同じになっている

  • 大量のデータを送信する2GBごとに100Byte単位でデータがいれかわるのでハードウェア選定が大変だった(昔の話)

など、自分では一生原因に気づけなさそうな問題について話されていて、同じ「システム開発」という括りでも分野が違えば求められるものも全然違うんだなと感じました。

8/31 15:20〜 もしもハッカーの「サイバー攻撃日誌」が読めたら

登壇者さんが普段、業務としてやられているサイバー攻撃の具体例のセッション。

フィッシングメールやエクセルのマクロの危険性など、普段なんとなく聞いて知っているサイバー攻撃が実際どう使われて、最終的にどうなるかというのがリアルに分かって非常に面白いと同時に恐ろしくなりました。

エクセルのマクロからなんて大した攻撃できないのでは?と思ってましたが認識を改めました...。

全体的な感想

特定技術のカンファレンスでは出てこないような話が多く、来年もまたぜひ参加したいと思います!
「技術」というワードに対して多角的にセッションが配置されており、ITエンジニアと呼ばれる人はだいたい何か楽しめる要素があると思うのでこれを読まれた方もぜひ参加してみてください!

Ruby 2.5.1からRuby 2.6.3にバージョンアップしてCSV生成が高速化しました

SREチームの中村です。

弊社にはtoreta-railsというトレタ全体の8割ほどのサービスのロジックが書かれているコアAPIがあります。

先日、toreta-railsのRails versionを5.2.3にバージョンアップしました。 それに続き、今週はRuby versionを2.5.1から2.6.3にバージョンアップしたのですが、CSV生成ジョブの性能向上が顕著でした。

その内容について報告します。

処理の内容

toreta-railsはSidekiqを非同期ジョブとして利用しています。以下の2つのCSV出力ジョブもSidekiq Workerとして実装しています。

顧客データCSV出力ジョブ

トレタは様々な規模の飲食店さんに利用されています。

店舗数が多い法人さんは売上を上げるために、自社の店舗に来店した顧客を分析します。そのため、トレタに溜まった顧客データをダウンロードできるようにする必要があります。

顧客データCSV出力ジョブは各法人に溜まった顧客データを各法人ごとに出力するというジョブです。

在庫データCSV出力ジョブ

トレタでは在庫データを永続化しておらず、都度計算しています。

詳細については私がRails Developers Meetup 2019にて発表した資料に載っていますので興味がある方は御覧ください。

Rails Developers Meetup 2019 で飲食店のオンライン予約の仕組みについて発表しました #railsdm - トレタ開発者ブログ

そのため、在庫データを別のサービスに投入する必要があるときは、在庫を計算してそれを様々な形式で渡すというやり方を取っています。 現状在庫データが必要なサービスはCSV形式で渡す必要があったので、そのためのジョブを作成しました。

計測結果

Ruby 2.5.1 (2019-06-04)

worker 実行件数 合計実行時間(sec) 1workerあたりの実行時間(sec)
顧客データCSV出力ジョブ 1424 446685 313.68
在庫データCSV出力ジョブ 198241 611437 3.08

Ruby 2.6.3 (2019-06-11)

worker 件数 合計実行時間(sec) 1workerあたりの実行時間(sec) 1workerあたりの実行時間の性能比(%)
顧客データCSV出力ジョブ 1419 347767 245.07 22%
在庫データCSV出力ジョブ 212244 376997 1.77 43%

顧客データCSV出力ジョブでは22%、在庫データCSV出力ジョブではなんと43%も実行時間が早くなりました! Rubyを最新にバージョンアップすることで、DBやサーバへの負荷の軽減はもちろん、ユーザに高速に価値を提供できるようになりました。

まとめ

Rubyのバージョンアップをちゃんと行うことで、ユーザにとても良い価値を提供できるようになりました。 日頃からサービス開発を通してお世話になっているRuby開発チームの皆さん、本当にありがとうございます。

SeleniumConf Tokyo 2019 に行ってきました!

こんにちは、QAエンジニアの坂田です。

少し前になりますが、4月18〜19日にSeleniumの国際カンファレンス SeleniumConf Tokyo 2019 を聴講してきました。
今回は、2日間の参加を通して感じたことをまとめてみたいと思います!

f:id:asktn:20190426155520j:plain

Seleniumとは

Seleniumはブラウザを自動操作してWebアプリケーションをテストするツールです。
最近は主要コンポーネントであるWebDriverがW3C採択され各ブラウザ内に実装されつつあるなど、UIテストフレームワークとしての標準化が進んでいます。

国際セッションで受けた印象

国際カンファレンスということで、半分以上のセッションが海外の方の講演でした。
海外の方の講演で個人的に感じたのは「とにかくまずやってみることを後押し」「新しい技術に対する説明が具体的かつ丁寧」ということです。

  • 日本人:組織寄り
    • 開発体制や組織の成長、チーム内外のコミュニケーションなどが俯瞰的に語られる傾向
  • 海外:技術・個人の成長寄り
    • 技術的なチャレンジの後押しと、必要なことが具体的に語られる傾向

良し悪しではなく、純粋に国際カンファレンスならでは実感できた違いとして面白かったです。

組織内でのQAの役割

開発現場では、開発とQAの一体化が進んでいる印象でした。
体制的にも職能的にも、現場のQAは実装に携わるエンジニアとアジャイル開発プロセスを共有しつつ、プロダクトの提供スピードや品質向上を相互にサポートし合う関係性が求められているように感じます。

一方、大きな企業になると、現場から離れた専門チームにもQA人材が入り、プロダクト横断で Developer Experience 改善に取り組んでいるケースが多かったです。
講演では以下のような取り組みが紹介されました。

  • CI化支援
  • E2Eテスト支援ツールの提供
  • テストケース最適化によるデプロイ高速化
  • レポーティングツールの内製

テスト自動化のスコープ

QA目線で自動化しようとするとテストコストの削減を第一に考えがちですが、自動化によるメリットはコスト削減よりもむしろ下記の方が大きかった、という話もありました。

  • エンジニアへ即時フィードバックを返せる
    • 頭が温まっているうちに修正でき、スイッチングコストが低減される
  • コード変更への精神的な抵抗感(デグレリスク)が軽減される
    • 積極的な機能拡張・リファクタリングが可能になる
  • テスト自動化の過程でプロダクトの仕様・構造を深く理解できる

何を目指すかで自動化の方針も大きく変わりうるため、重要な学びになりました。

サービス・プロダクトの特性に応じたテストの配分最適化

サービス・プロダクトの特性に応じてテストピラミッド(テストの階層/役割/配分など)を最適化した実例も紹介され、面白かったです。

極力ローレベルのテストに落としていく原則は変わりませんが、単純なピラミッドの形だけが良いのではなく、状況に応じてintegration(APIテストなど)を厚くしたりE2Eを厚くしたりと、思ったより様々な印象でした。

QAにも高品質なコーディングが求められる

テストコードもプロダクト資産である、という点もいくつかのセッションに共通するメッセージでした。
TDDの大家である和田卓人(t_wada)さんがKeynoteに登壇したりと、開発プロセスやコードの保守性が重要なテーマに上がっていました。

さいごに

全体を通して、QAも他のエンジニアと同様に、技術を組み合わせて組織課題を解決したり、開発プロセスを最適化したり、といったアプローチを当然に求められていることを強く感じました。

個人的に、開発プロセスも成熟度も異なる複数のプロダクトに対しQAとしてどう関与・貢献すべきか課題を持っていたこともあり、とても有意義なカンファレンス参加になりました。

次回のSeleniumConfは2019年10月にロンドンで開催予定です。(海外!)
興味ある方がいらっしゃれば、ぜひ参加して感想をお聞かせください!

© Toreta, Inc.

Powered by Hatena Blog