一休.com Developers Blog

一休のエンジニア、デザイナー、ディレクターが情報を発信していきます

Send With Confidence Tour で一休.com の事例を話してきました

こんにちは。一休.com の宿泊開発基盤のお手伝いをしている id:shiba-yanです。

先週の話になるのですが、SendGrid の日本国内代理店の方から「一休.com での SendGrid を利用した運用について事例を話してほしい」とお願いされたので、簡単に出したが話してきました。

当日は SendGrid 本社から技術系の偉い人が来日して、世界初の話を含めていろいろと話してくれました。

様々な話がありましたが、中でも Geopod*1 が東京にもあることは知りませんでした。昔はシンガポールを使っていたみたいですが、今は日本からでも低レイテンシーで送信できるようになっているようでした。

おそらく開催ブログは公開されると思いますが、先にスライドを公開しておきます。メインは 2017 年に発生した、割と大規模な SendGrid 障害時の話です。

一休.com ではメールが非常に重要な役割を果たしているので、多少の送信エラーが発生したとしても、出来るだけリカバリーが行えるように実装しています。

しかし、障害発生時にはいろいろな問題が発覚したため、反省しつつ対応を行っていきました。

割と当たり前のことが出来てなかったと今では思いますが、当たり前を当たり前に行うのは非常に難しいことだと再認識し、今後の開発にも繋げていきたいと考えています。

参考

*1:SendGrid が世界中に用意しているエンドポイントの一つ

Renovateによるnpmパッケージ定期更新

一休.com・フロントエンドエンジニアの宇都宮です。

JavaScriptを使ったWeb開発では、様々なライブラリを使います。開発の活発なライブラリであれば、毎週のようにバージョンアップが行われます。ライブラリのバージョン更新は、それを行ったからといって価値に直結するわけではありません。しかし、以下のような理由から、一定の頻度での定期更新が必要です。

  1. バージョンアップに追従しないと、古いバージョンにロックインされる
  2. 差分が大きいバージョンアップはリスクが高い
  3. ライブラリに脆弱性が見つかった際は速やかにバージョンアップが必要

本記事では、JavaScriptライブラリ管理の標準的ツールであるnpmと、GitHub AppのRenovateを使用した、ライブラリを定期的に更新する仕組みの作り方について解説します。

npmによるパッケージ管理

npmは、JavaScriptライブラリの管理ツールです。

npmでは、使用するライブラリの名前とバージョンをpackage.jsonというファイルで管理します。

以下のように、dependencies(本番環境で使用するライブラリ)と、devDependencies(開発環境でのみ使用するライブラリ)を分け、それぞれのライブラリ名と、バージョン番号を指定します。

{
  "dependencies": {
    "vue": "2.5.16"
  },
  "devDependencies": {
    "vue-loader": "14.2.2"
  }
}

npmパッケージのバージョン番号は原則としてsemverという仕様に基づいており、x.y.zのxがメジャー、yがマイナー、zがパッチバージョンを意味します。メジャーバージョンアップは後方互換性のない変更、マイナーは後方互換性のある新機能追加、パッチは後方互換性のあるバグフィックスです。

依存ライブラリのバージョンには、幅を持たせることが可能です。たとえば「^2.5.16」は、「2.5.16以上のバージョンで、3.0未満」という意味になります。この指定方法はライブラリ向きです。他からライブラリとして参照されることのないアプリケーションでは、バージョン番号を固定しても良いでしょう。

実は、package.jsonだけでは、インストールされるライブラリのバージョンが毎回同じになることは保証されません。vue 2.5.16をインストールしたとしても、vueが依存しているライブラリのバージョンまで、全て同じになるとは限らないからです。

そのため、全ての依存ライブラリのバージョンを記録したファイルを別途用意する必要があります。npm 5以上では、npm installの実行時にpackage-lock.jsonというファイルが生成されます。このファイルには、全ての依存ライブラリのバージョンが記録されます。package.jsonpackage-lock.jsonが存在する状態でnpm installを実行すれば、正確に同じバージョンのライブラリがインストールされます。

これはnpmコマンドの代替であるyarnでも同様で、yarn.lockに全ての依存ライブラリのバージョンが記録されています。

npmパッケージの更新手順

更新の必要なnpmパッケージを探すには、npm outdatedまたはyarn outdatedコマンドを使用します。

yarn outdatedは、semverに基づいてメジャー/マイナー/パッチの分類を行う等、よりリッチな機能を備えています。個人的にはyarn outdatedを好んで使っています。

バージョンアップの必要なライブラリを見つけたら、yarn upgrade vue 等で、ライブラリのバージョンを更新します。あとは動作確認して、リリースするだけです。

簡単そうに書きましたが、実際のところ、npmパッケージの更新は面倒です。バージョンアップしても問題ないか確認するには、CHANGELOGの確認が欠かせません。

一休の宿泊予約サービス開発チームでは、週に1回程度の頻度で、以下のようなプルリクエストを作成して、npmパッケージの定期更新を行っていました。

f:id:ryo-utsunomiya:20180427145703p:plain:w320

この作業は地味に面倒で、毎週1時間程度の時間をアップデートに割いていました。そこで、パッケージ更新作業の省力化を図るための手段をいくつか検討した結果、Renovateの導入を決めました。

Renovateとは

Renovateは、GitHub上で動作するアプリ(bot)です。Renovateを導入したリポジトリでは、以下のようなプルリクエストが自動的に作成されます。

f:id:ryo-utsunomiya:20180501110718p:plain:w320

github.com

↑のスクリーンショットは、yarnのリポジトリから取得しています。Renovateは、yarnをはじめとした様々なオープンソースプロジェクトや、Uber等の企業まで、幅広く利用されています。

publicリポジトリでは無料、organization + privateリポジトリでは$15/month~で使えます。更新の必要なライブラリの確認 => CHANGELOGまとめ => プルリク作成という定型作業を代わりに行ってくれるので、十分に元が取れる価格だと思います。

また、Renovate本体はOSSであり、自前でホスティングすることも可能です。

Renovateを導入する

RenovateはGitHub Marketplaceから導入できます。Marketplaceからrenovateを探したら、まずはプランを選びましょう。ここでは、私が個人で開発しているオープンソースプロジェクトにRenovateを導入するため、「Open Source」を選んでいます。

f:id:ryo-utsunomiya:20180501112032p:plain:w320

次の画面では、有料プランの場合、支払い情報の入力が必要になります。会社のGitHubリポジトリに導入する際は、個人アカウントの請求情報を入力しないよう注意しましょう。

f:id:ryo-utsunomiya:20180501112420p:plain:w320

最後に、インストールするリポジトリを選択します。ここでは、「ryo-utsunomiya/amazon-block」を選択しています。

f:id:ryo-utsunomiya:20180501112659p:plain:w320

1時間ほど待つと、以下のようなOnboading Pull Requestが作成されます。

f:id:ryo-utsunomiya:20180501120900p:plain:w320

github.com

このプルリクでは、renovate.jsonというRenovateの設定ファイルをリポジトリに追加します。デフォルトでは以下のような動作をします。

  • メジャーバージョンアップは別々のプルリクに分割する
  • パッチ・マイナーアップデートを区別しない
  • アップデート用ブランチの名前には renovate/ プレフィックスをつける
  • マージは自動では行わない(人間が手動でマージする)
  • package.json が更新された場合にのみlockファイルを更新する
  • プルリクの作成は2時間毎に1回を上限とする
  • Renovateが作成したプルリクで、マージ/クローズされていないものの数が20を超えないようにする

このプルリクエストをマージすると、Renovate Botが動き始めます。

Pin Dependencies

パッケージのバージョンが固定されていない場合、以下のようなプルリクエストが作成されます。

f:id:ryo-utsunomiya:20180507191951p:plain:w320

github.com

ここでは、各パッケージのバージョン番号を固定(Pin)します。Pin Dependenciesプルリクをマージすると、パッケージの更新用のプルリク作成が始まります。

なお、依存ライブラリのバージョンをに幅をもたせたい場合は、以下のようにrenovate.jsonを変更すればOKです。

{
  "extends": [
    "config:base",
    ":preserveSemverRanges"
  ]
}

renovatebot.com

パッケージ更新の運用

Renovateによって、プルリクを作成するところまでは自動化されました。残りの作業は、安全を期して人間が行うようにしています。

具体的な手順は以下の通りです。毎週月曜の当番制にしています。

  1. 毎週月曜に、担当者がパッケージ更新の有無を確認する
  2. 更新があれば、パッケージ更新用ブランチを手元にpullして動作確認する
  3. 問題なければ、プルリクをマージする

マイナー/パッチアップデートはすぐに適用しています。一方、メジャーアップデートはソースコードの改修が必要なことが多いので、担当者をアサインして、一定の時間を確保してアップデートしています。

導入の効果

Renovateによる自動化によって、プルリク作成までの手順が標準化されたため、誰でもパッケージ更新作業が行えるようになったのが大きいです(従来は、有識者が気づいたときに更新するという体制でした)。

副次的な効果として、どのようなライブラリを使用しているか棚卸しできる、ライブラリの導入時に運用コストまで考慮できる、といったものもあります。

今後の課題

更新時の動作確認に属人性があるため、バグのある状態でリリースしてしまう危険性があります。

  • 自動テストの拡充
  • 動作確認手順の標準化

などによって、バグのある状態でのリリースを防ぐ対策を強化していきたいと考えています。

おまけ:マイナー/パッチアップデートをまとめる

デフォルト設定の場合、各パッケージ毎に更新プルリクが作成されます。しかし、週1回程度の更新頻度だと、マイナー/パッチアップデートは複数存在する状態になります。そこで、宿泊予約サービス開発チームでは、以下のようなrenovate.jsonの設定を行って、マイナー/パッチアップデートを1つのプルリクエストにまとめています。

{
  "extends": [
    "config:base"
  ],
  "minor": {
    "groupName": "all dependencies"
  }
}

↑のrenovate.jsonを使用すると、以下のようなプルリクエストが作成されます。

f:id:ryo-utsunomiya:20180507185539p:plain:w320

github.com

一休レストランの事業領域を理解するのに役だった本3冊

一休レストランiOSアプリチームのマネージャーをしているninjinkunです。自分は半年前に一休に入社したのですが、元々外食は好きだったものの、飲食に関わるサービスに関わるのは初めてでした。

そこで自分でサービスを使ったり、営業同行をしてみたりしながら、自分なりに事業領域を理解しようと試行錯誤をしてきました。このエントリではその活動の一環として読んだ本の中から、参考になったものを紹介します。

Hot Pepperミラクル・ストーリー

Hot Pepperミラクル・ストーリー―リクルート式「楽しい事業」のつくり方

Hot Pepperミラクル・ストーリー―リクルート式「楽しい事業」のつくり方

いきなり競合他社の本なのですが、まだ紙媒体だった頃のHot Pepperの話です。立ち上げから、全国展開してアクセルを踏んでいく経緯が事業責任者の視点で書かれています。

自分にとってこの本は、一休レストランの「営業」を理解するという意味で有益でした。飲食店の集客ニーズをくみ取って、そこにHot Pepperという広告媒体を提案しに行く話が具体的に書かれているのですが、ビジネスモデルは違えど一休の営業とも共通点は多いように思います。

他にも、できる営業を分析して、全員に展開していく様は勉強になりました。営業のトークを撮影してみんなで共有したり、社内でロールプレイングをやって営業力を他の社員に展開したり、営業ツールを作ったりと、全く門外漢で知らない手法だらけだったので面白く読めました。営業の活動を知りたい開発者にはおすすめだと思います。

ミシュラン

ミシュランガイド東京 2018

ミシュランガイド東京 2018

一休レストランはお値打ちなお店から高級なお店まで幅広いラインナップがありますが、やはり名店と言われるお店は社内での会話に良く出てきます(商品の文脈でも、プライベートで行ってみたいという文脈でも)。自分はそういった名店の知識がなかったので、定番のミシュランを買って勉強していました。掲載店が近所にあったりするのに気づくと、開拓する楽しみが増えます。

こちらはちょうど2018年版が出たところのようです。

東京カレンダー

東京カレンダー2018年1月号

東京カレンダー2018年1月号

雑誌です。最近は割とゲスめのコピーを採用していることで一部で話題ですが、自分がこの雑誌が優れていると思う点は「お店の利用シーン」を明確に提案している点にあります。

実際のお店を取り上げたデートや女性同士の飲み会、謎の男女の「お食事会」などが(相当誇張されている表現ではありますが)毎号たくさん載っており、飲食店を利用するイメージが湧きます。そして何より、この雑誌のターゲット層は一休レストランのユーザー層と丸かぶりしているのです。ネタだと思われそうですが、自分は最近東京カレンダーを参考にしてユーザーストーリーを考えました。

また、社内にもファンが多いようで、最近作られた社内Slackの #東京カレンダー はやたらと盛り上がっており、同僚とのコミュニケーションにも一役買っています。

おわりに

以上、一休レストランの事業領域を理解するのに役だった本たちでした。飲食店に関する本でおすすめがあれば教えていただけると嬉しいです。

iOSとAndroidの段階的リリース機能を比較する

この記事は一休.comアドベントカレンダー2017の25日目です。

一休レストランiOSアプリを開発しているid:ninjinkunです。

iOSでは今年の夏からiTunesConnectにて段階的リリース(Phased Releases)が導入されています。段階的リリースとは、アプリの新バージョンを提供する際に一部のユーザーから順にアップデートを適用していくリリース方法です。不具合があった際に全ユーザーに影響が及ぶことを防ぐことができ、リスクを低減することができます。

この機能にの詳細については、 iOSの段階的リリースについての注意点 - inFablic | Fablic, inc. Developer's Blog. が詳しく、本エントリは追試 + 以前に使用した経験があるAndroidの段階的リリース(Staged Rollout)との比較になります。

結論を先に書くと、この機能は段階的自動アップデートと呼ぶ方が適切だと思いました。そして使いどころが難しかったので、今後はあまり使わないでしょう。当初はAndroidと同じ機能を期待していたのですが、だいぶ違うものでした。

この情報は2017年12月時点のものなので、来年には状況が変わっている可能性がある点にご留意ください。

日数と公開割合が固定 📅

この機能を使う際には、iTunesConnectから段階的リリースを選択します。

f:id:ninjinkun:20171225130423p:plain

まず気になるのが、段階的リリースの日数が固定されている点です。7日間に渡って1日ずつ固定の割合で公開範囲が広がります。Androidの場合は公開の段階を引き上げる日と、公開する割合を自分たちで決めることができます(ただし手動)。

手動アップデートと新規ユーザーは全員新バージョン 🆕

もう一つ注目したいのが、段階的リリースの最中であっても、ユーザーが手動でAppStoreから新バージョンをダウンロードできるという点です。さらに、新規ユーザーは全員に新しいバージョンがインストールされます

Androidの場合は、公開範囲に含まれなかったユーザーは新バージョンに手動でアップデートすることができません。また、ここはきちんと検証できていないのですが、新規ユーザーについても新バージョンが適用される比率は同じであると思われます。

制御されているのは自動アップデートのみ 🆙

iOSの段階的リリースとAndroidの段階的リリースはどうやら根本的に実装方法が異なるようです。具体的には、iOSは新バージョンの自動アップデートを制御しているだけであり、自動アップデートではない手動アップデートと新規ユーザーの場合には新バージョンが適用されます。そしてどうやら、AppStore上に置かれるバイナリは新バージョンのみのようです。

他方Androidは新バージョンのバイナリを適用するユーザーを制御しており、自動/手動アップデート、新規/既存にかかわらず、公開範囲に含まれたユーザーしか新バージョンをインストールできません。そしてGoogle Play Store上には旧バージョンと新バージョンの両方のバイナリが配置されます。

ロールバック不可 🙅

この違いから、iOSの段階的リリースでは新バージョンに問題が発生しても、ストアが旧バージョンを保持していないためロールバックができません。できるのは自動アップデートの適用範囲を固定の状態で止めることだけです。その間にも新規ユーザーは問題がある新バージョンをダウンロードし続けることになります😓

修正リリースは再審査 👨‍⚖️

修正したバージョンをリリースする際は再度AppStoreの審査があります。このため、一般的に段階的リリースの目的の一つであると思われる、不具合のリスクを抑えながら頻繁にリリースを行ってスピード感を出す目的には使えません。

また、修正したバージョンを提出する際に段階的リリースを選択すると、また1%からやり直しです。今回の使用では、前回の段階的リリース当選ユーザーに新バージョンが配布されているかは確認できませんでしたが、おそらく実装されていないのではないかと睨んでいます。

Androidはこの部分でも先行しており、段階的リリースの対象ユーザーのみに修正バージョンを配布することができます。

一休レストランでの利用事例

一休レストランでは、予約情報を入力する画面のリニューアルを行う際に、リスク低減の目的で段階的リリースを使用してみました。そして危惧していたとおり、リリース後に一部のレアなケースで予約ができないという不具合が見つかりました(事前に可能な限り確認はしていたので、発見できなかったのは仕方なかったと考えています。損害も軽微でした)。

ここで段階的リリースやってて良かった…となると良いのですが、実際は不具合が新規ユーザーのみに起こるものだったため、段階的リリースは全く意味が無かったという結果になりました 😭

おわりに

以上、Androidとの比較を交えながらiOSの段階的リリースについて解説しました。

自分の意見としては、

  • 新規ユーザーには新バージョンが渡ってしまう
  • ロールバックができない
  • 修正リリースがやりづらい

という点から、積極的に使うことはないと思います。今後のアップデートに期待しています。

最後にiOSとAndroidの比較について表にまとめておきます。

  iOS Android
呼称 Phased Releases Staged Rollout
公開日程 7日間で固定 手動で随時変更
公開範囲 1%, 2%, 5%, 10%, 20%, 50%固定 0.5%, 1%, 5%, 10%, 20%, 50% から選択任意
段階的リリース中の全公開 できる できる
段階的リリースのサスペンド できる(ただし手動アップデートは可能 & 新規ユーザーには新バージョンが出続ける) できる
制御できるユーザー 自動アップデートユーザー 全ユーザー
ロールバック できない できる(ただし新バージョンをインストールしてしまったユーザーは戻せない。審査がないので上げ直しで対応)
対象ユーザーへの修正版配布 不明(おそらくできない) できる
ストアに置かれるバイナリ 最新版のみ 新旧複数バージョン

それでは、今年も一年おつかれさまでした。新年会のご予約に、一休.comレストランをぜひご利用ください。

レストランを簡単予約!一休.comレストラン

レストランを簡単予約!一休.comレストラン

  • IKYU Corporation
  • フード/ドリンク
  • 無料

2018/1/11 追記

Androidの段階的リリースの公開範囲は、現在は任意の%で指定できるようになっているとのことです。ご指摘感謝。

一休における開発組織の変遷(目的型組織への移行)

メリークリスマスイブ! 皆様クリスマスイブはいかがお過ごしですか。

データサイエンス部所属のエンジニア 笹島 id:sisijumi です。

年末ということもあり、今日は一休という会社のエンジニア組織の変遷を振り返るとともに、現状に関してもお話させていただきます。 (現状はデータサイエンス部ですが、今年の10月までは宿泊事業部のエンジニアのマネージャーをやっておりました。)

一休における収益の変遷

宿泊事業に関してですが、過去発表した資料を元に説明させていただきます。 (近年非上場になった為、直近の収益に関しては資料はありません。)

f:id:sisijumi:20171224173112p:plain

創業期、成長期を経て、一時停滞したものの、きちんと再度成長していることがわかりますね。

事業のステージに合わせて変化してきました

創業期、成長期を支えてきた組織構造

各部署内に宿泊・レストランチームが存在しています

f:id:sisijumi:20171224172217p:plain

各部署が都度エンジニアのマネージャーとコミュニケーションと会話して開発を進める、というスタイルになっています。

f:id:sisijumi:20171224172210p:plain

この頃、中心となるマネージャーがボトルネックになってしまうと開発の全体のスピードが遅れるという課題がありました。 また、宿泊予約やレストラン予約等それぞれのサービスがより成長し、上記の開発スタイルがそのスピード感にマッチしなくなってきました。

再成長を支えた事業部の設立

それぞれのサービスをより成長させることへコミットできるように、一休という会社としても事業部制への移行を実施しました。 それとともに事業部毎にエンジニアを配置する形に変更になっています。

f:id:sisijumi:20171224172429p:plain

事業責任者とエンジニアのマネージャーでプロダクト開発優先順位を意思決定し、開発メンバーを調整するという流れでした。 以前の形と異なる点は、エンジニアのリソースをどう活用すれば事業の成長に最も寄与できるかをきちんと意思決定しながら開発を進めている点です。 (以前の形では依頼ベースで開発を進めてしまうところがあり、事業の成長に最も寄与するためのエンジニアのリソースの配置をどうするか、という視点が欠けていたと思っています。)

f:id:sisijumi:20171224172347p:plain

目的型組織への移行

ミッション毎にプロダクト開発チームの枠組みを作りました

事業を成長させるためのミッションを作成し、ミッション毎にチームを配置しました。この形にすることで、それぞれのチームごとにミッションに集中できる構造になっています。
以前の形ですとビジネスオーナーとエンジニアの間にエンジニアのマネージャーが間に挟まってしまい、不要なコミュニケーションが発生してしまっていました。ビジネスオーナーとエンジニアの距離をより近づけることで、開発時のコラボレーションがより活発になることを目指しました。

f:id:sisijumi:20171224172750p:plain

事業部長が作成したミッションごとのチームそれぞれで、プロダクト開発が進む体制になっています。 この構造においては、マネージャーはエンジニアを後方支援する形になっています。また事業部長とのコミュニケーションも何をやるかではなく、事業の成長に各ミッションへのエンジニアのリソースは最適化できているか、という視点が主になっています。

f:id:sisijumi:20171224172757p:plain

最後に

エンジニアの枠組みとしてこうあるべき、というビジョンも必要ですが、それに囚われずチーム構造を柔軟に変化させる必要があります。 自分がマネージャーだと、現状のチーム構成から変化させることに心理的負荷はやはりあります。(チームでやってもらっているメンバーにきちんと説明し、合意をした上できちんと進めないといけないということが頭をよぎり、反射的に反対することもある)
しかし、今の立場に縛られず現状の事業をどうやって伸ばすか、成果を最大化させるためにエンジニアチームでやるべきことはなんなのか、など事業にきちんと貢献できているかを客観的に継続的に判断する必要があります。事業的な成長をプロダクト開発において牽引していきたいと思います。

明日は id:ninjinkuniOSとAndroidの段階的リリース機能を比較する です

一休.comスマホ版予約入力画面リニューアルの舞台裏

本記事は、一休.com Advent Calendarの23日目です。

宿泊事業本部フロントエンドエンジニアの宇都宮です。

先日(12/19)、一休の宿泊予約サービス(以下、一休.com)のスマホ版の予約入力画面リニューアルをリニューアルしました。本記事では、

  • どのような方針で
  • どのような技術を使って
  • どのような設計で
  • どのように実装していったか

を紹介します。

Before/After

リニューアル前

ファーストビュー

f:id:ryo-utsunomiya:20171220082307p:plain:w320

エラー通知

次の画面へ進む前に、alert()

f:id:ryo-utsunomiya:20171220082328p:plain:w320

リニューアル後

ファーストビュー

f:id:ryo-utsunomiya:20171220083829j:plain:w320

エラー通知

項目の上に表示&自動フォーカス

f:id:ryo-utsunomiya:20171220083838j:plain:w320

主な変更点

  • デザインの刷新
  • エラー通知の改善
  • クレジットカード入力画面、オプション注文画面の統合

実装面では、ASP.Net Web Formsのユーザーコントロールを大幅に削り、Vue.jsのコンポーネントに置き換えました。

以前の画面の課題

リニューアル前の予約入力画面には、いくつかの課題がありました。

  • UIが使いにくい 特にエラー通知が不親切
  • 画面の表示が遅い(サーバサイドで大量のデータを読み込んでいるため)
  • ユーザーコントロールの変更が難しく、生産性が低い

エンジニアの観点からすると、特に生産性の低さが気になっていました。ユーザーコントロールとはASP.Net Web Formsフレームワークの機能で、再利用可能なコンポーネントを定義する機能です。

ユーザーコントロールは、上手に活用すれば生産性を向上させる機能だと思いますが、残念ながら一休の予約入力画面では、生産性を低下させる原因となっていました。というのも、数千行規模のユーザーコントロールが複数存在し、それぞれが密結合していたのです。

4月に、フォームの入力欄の順番を入れ替える作業を行いました。表面上は簡単な調整で、普通のHTMLなら30分でできそうな作業でしたが、実装1日+テスト0.5日という工数を費やす必要がありました。

あるユーザーコントロールから別のユーザーコントロールに入力欄を移動するには、その入力欄のために定義されているフィールド/プロパティやメソッドを、まるごと別のユーザーコントロールに移す必要があったためです。

↓は当時のプルリクのスクリーンショットですが、3項目の移動で+3,571 −166という大きなdiffが生じています。

f:id:ryo-utsunomiya:20171220090931p:plain:w320

また、予約入力画面のaspxファイルは単体で5,000行(※)ほどあり、ファイル内で行きつ戻りつするのも非常に大変でした。

※:JSが3,000行、残りはHTMLとASP.Netのコードナゲット

このような理由から、予約入力画面のリニューアルを検討しました。

リニューアルの方針と実装

スコープ

予約の画面は膨大な業務ロジックに支えられているため、実装工数が膨らむことは避けられません。そこで、以下のようにスコープを限定して進めました。

  • 対象はスマホ版の予約入力画面のみ
    • PC版や、スマホ版でも予約確認画面や完了画面には手をつけない
  • サーバサイドの業務ロジックにはできるだけ手をつけない。レスポンス速度の改善はスコープ外

技術選定

予約入力画面のリニューアルでは、EFO(Entry Form Optimization)の観点から、JavaScriptでリッチなエラー通知を行うことを目指しました。あわせて、開発者の生産性を向上させる必要性も感じていました。そこで、JavaScriptフレームワークのVue.jsを導入しました。

既存の画面で使用しているjQueryではなく、Vue.jsをメインに据えた理由は、生産性が大きな要因です。Vue.jsの単一ファイルコンポーネントを使用すると、画面上の要素(コンポーネント)ごとに、関連するロジック(js)とスタイル(css)をひとまとめにすることができます。コンポーネントを小さく保ちながら実装を行えば、コードのメンテナンス性を大きく向上させることができると考えました。

実装

Vue.js + Vuex + VeeValidateというスタックで実装を行いました。

Vuexを導入するかは迷いましたが、予約入力画面で使用する膨大なデータを一元管理できるのは大きなメリットでした。VeeValidateはpluggableな構成になっていて、独自のバリデーションを簡単に定義できるようになっているのが良かったです。

テストには vue-test-utils を使用しています。Vueコンポーネントのテストは一部のメソッドと算出プロパティだけで、レンダリングのテストは行っていません。

現在のところ、コンポーネントの構成は以下のようになっています。

f:id:ryo-utsunomiya:20171220094116p:plain:w320

大枠から作っていって、徐々にコンポーネントを分割していくという方針を採ったため、コンポーネントの粒度は大きめです。また、本来はコンポーネントにすべきなのに、コンポーネント化できていない部分もあったりします(たとえば、お知らせメール受信設定)。

目安として、.vueファイルが100行を超えたらコンポーネントを分割できないか検討するようにしていました。最も大きなコンポーネントで.vue 200行 + .js 300行ほど、平均的なコンポーネントのサイズは100行程度に抑えることができたため、コードの見通しはかなり良くなりました。

また、以前は5,000行ほどあった予約入力画面のaspxファイルは、リニューアルによって200行にまでスリム化しました。

残る課題

本ページのリニューアルに関しては一区切りというステータスですが、以下のような課題が残っていると認識しています。

  • 一休.com全体でのデザイントーンがバラバラ
  • 画面の表示は相変わらず遅い
  • コンポーネントの粒度はもう少し細かい方がよさそう
  • JavaScriptの単体テストが不足している
  • CSS Modulesがまだ使いこなせてない

デザイン面の課題はデザイナーと協力して、プログラムの課題は他のエンジニアとも認識を合わせながら、引き続き改善していきたいと考えています。

明日はzimathonさんの「開発組織の目的型組織への移行」です。

KMLを元にしたSolrの空間検索に挑戦

この記事は一休.comアドベントカレンダー2017の22日目です。

いよいよ今年も終わりですね。 みなさん クリスマスの、忘年会のご予約はすみましたか?

というわけでアドベントカレンダー2打席目、一休.comレストラン 検索 & 集客担当のにがうりです。

一休の本社は赤坂見附の駅からほど近くにあり、お昼ごはんの選択肢が非常にバラエティに富んでいるのが嬉しいところです。 もちろん、その中には一休.comレストランにご加入いただいている店舗様もたくさんあります。

本エントリでは

  • 筆者のお昼休み中に通える範囲内にあり
  • 一休.comレストランでランチが予約できる

レストランがどのくらいあるのか、Solrの空間検索( Spatial Search )を利用して調べてみました。

なお、前回のエントリ同様、Solrのバージョンは7.1.0を前提としています。

事前準備

Solrのスキーマ構成

ひとまず、以下の項目を用意します (restaurant_idがuniqueKey)

  <field name="restaurant_id" type="string" indexed="true" required="true" stored="true"/> <!-- レストランのID -->
  <field name="restaurant_name" type="string" indexed="true" stored="true"/>  <!-- レストランの名称 --> 
  <field name="lat_lon"           type="location"   indexed="true" stored="true" /> <!-- 緯度、経度 -->
  <dynamicField name="*_coordinate" type="pdouble" indexed="true" stored="false"/>

対象となるデータ

「赤坂・永田町・虎ノ門」エリアで12時に予約できるお店が120件ほど見つかりました。 これらの店舗のID, 名前, 緯度経度をSolrに登録しておきます。

Solr検索のテスト

試しに3件取得

URL

http://localhost:8888/solr/ikyu-advent-2017-spatial/select?wt=json&echoParams=none&fl=restaurant_id,restaurant_name,lat_lon&q=*:*&rows=3

取得結果

無事に登録されていました

{
    responseHeader: {
        status: 0,
        QTime: 5
    },
    response: {
        numFound: 120,
        start: 0,
        docs: [{
            restaurant_id: "100152",
            restaurant_name: "春秋 溜池山王店",
            lat_lon: "35.6736091,139.740132"
        }, {
            restaurant_id: "100195",
            restaurant_name: "沖縄懐石 赤坂潭亭",
            lat_lon: "35.6685154,139.732890"
        }, {
            restaurant_id: "100197",
            restaurant_name: "赤坂浅田",
            lat_lon: "35.6738200,139.738229"
        }]
    }
}

オフィスの位置を中心に範囲検索

Spatial Searchのgeofilt を使い、

  • オフィスの場所を中心に
  • 半径400メートル以内の店舗を
  • 近い順に

探してみます

URL

http://localhost:8888/solr/ikyu-advent-2017-spatial/select?wt=json&echoParams=none&fl=restaurant_id,restaurant_name,lat_lon,geodist:geodist()&spatial=true&sfield=lat_lon_rpt&q={!geofilt}&pt=35.675471,139.737937&d=0.4&sort=geodist()%20asc&rows=3

pt=35.675471,139.737937 が一休本社オフィスの緯度経度、d=0.4 が400メートル以内という指定です

取得結果

{
  "responseHeader": {
    "status": 0,
    "QTime": 0
  },
  "response": {
    "numFound": 36,
    "start": 0,
    "docs": [{
      "restaurant_id": "100729",
      "restaurant_name": "個室会席 北大路 赤坂茶寮",
      "lat_lon": "35.6752587,139.738609",
      "geodist": 0.06510001  /* geodistは中心地からの距離 (km) */
    }, {
      "restaurant_id": "106301",
      "restaurant_name": "土佐料理 祢保希 赤坂店",
      "lat_lon": "35.6751768,139.737050",
      "geodist": 0.086561576
    }, {
      "restaurant_id": "107172",
      "restaurant_name": "赤坂 金舌",
      "lat_lon": "35.6746016,139.737555",
      "geodist": 0.10269355
    }]
  }
}

無事取得できました。 一見、後は半径を調整すればいけそうに思われます・・・が、一休本社の周辺マップはこのようになっています。

一休周辺地図 ※ 赤いピンが株式会社一休本社

ご覧の通り、

  1. 東側には大通り
  2. 大通りを抜けても日枝神社や大使館
  3. 北側もガーデンテラスの方向に抜けるためには何回か信号を渡る必要がある

となっているため、単純な半径の調整で良い具合に、というのは中々厳しいものがあります。 ここは、円形ではなく任意の範囲を指定して検索したいところです

任意の範囲を指定して検索

任意の範囲を検索するためには、

  1. どうやって任意の範囲を指定するのか
  2. 任意の範囲を使った検索をどのように行うか

という2つの課題をクリアする必要があります。 幸い、1はGoogleマイマップ、 2はJTSを利用したSpatial Search を使うことで対応できました。

Googleマイマップで範囲データを作成

Googleマイマップでは地図上に自由にラインを引くことでき、さらにそれをKML形式のデータとして出力することが可能です。 ※ Googleマイマップの使い方については本稿の主旨と異なるため、割愛します

ランチタイムの徒歩行動圏をこのような枠線で表現しました。 お昼の行動半径

こちらをKML形式でエクスポートした結果が以下です。

ikyu-advent-2017-spatial.kml

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
  <Document>
    <name>ikyu-advent-2017</name>
    <Style id="poly-000000-1200-77-nodesc-normal">
      <LineStyle><color>ff000000</color><width>1.2</width></LineStyle>
      <PolyStyle><color>4d000000</color><fill>1</fill><outline>1</outline></PolyStyle>
      <BalloonStyle><text><![CDATA[<h3>$[name]</h3>]]></text></BalloonStyle>
    </Style>
    <Style id="poly-000000-1200-77-nodesc-highlight">
      <LineStyle><color>ff000000</color><width>1.8</width></LineStyle>
      <PolyStyle><color>4d000000</color><fill>1</fill><outline>1</outline></PolyStyle>
      <BalloonStyle><text><![CDATA[<h3>$[name]</h3>]]></text></BalloonStyle>
    </Style>
    <StyleMap id="poly-000000-1200-77-nodesc">
      <Pair><key>normal</key><styleUrl>#poly-000000-1200-77-nodesc-normal</styleUrl></Pair>
      <Pair><key>highlight</key><styleUrl>#poly-000000-1200-77-nodesc-highlight</styleUrl></Pair>
    </StyleMap>
    <Placemark>
      <name>ランチエリア</name>
      <styleUrl>#poly-000000-1200-77-nodesc</styleUrl>
      <Polygon>
        <outerBoundaryIs>
          <LinearRing>
            <tessellate>1</tessellate>
            <coordinates>
              139.7344959,35.6802109,0
              139.7360516,35.6778317,0
              139.7344422,35.6766465,0
              139.7351772,35.6739926,0
              139.7361803,35.6719924,0
              139.7388196,35.67116,0
              139.7404772,35.672341,0
              139.7392058,35.673352,0
              139.7372103,35.680516,0
              139.7344959,35.6802109,0
            </coordinates>
          </LinearRing>
        </outerBoundaryIs>
      </Polygon>
    </Placemark>
  </Document>
</kml>

「coordinates」の中に経度、緯度の羅列が入っています。こちらが枠線の情報のようです。

ちなみに、この地図に対して前述の120件のレストランをプロットするとこのようになりました

f:id:ikyu_com:20171222135449p:plain

範囲広すぎましたね・・・ 気を取り直して続けます。

検索の下準備

インストール直後のSolrでは空間検索ができない状態でした。 空間検索を行うためには、JTSを入手する必要があります。

JTSの入手 & 設定

  1. https://repo1.maven.org/maven2/com/vividsolutions/jts-core/ より jts-core-{バージョン}.jar をダウンロード (本稿作成時点では1.14.0)
  2. SOLRインストールディレクトリ/server/solr-webapp/webapp/WEB-INF/lib/ にコピー ※ SOLRインストールディレクトリ/server/lib と間違えないように

SolrにJTSを反映

1. 定義済みの型「location_rpt」に対しspatialContextFactory="JTS" を追記 (これをやらないとエラーになります)
<!-- 変更前 -->
<fieldType name="location_rpt" class="solr.SpatialRecursivePrefixTreeFieldType" geo="true" maxDistErr="0.001" distErrPct="0.025" distanceUnits="kilometers" />
<!-- 変更後 -->
<fieldType name="location_rpt" class="solr.SpatialRecursivePrefixTreeFieldType" geo="true" maxDistErr="0.001" distErrPct="0.025" distanceUnits="kilometers" spatialContextFactory="JTS"/>
2. location_rpt型の列を追加

lat_lon_rptという列を追加しました。 データを作り直すのは面倒なので、copyFieldでlat_lonの値をコピーさせています

  <copyField source="lat_lon" dest="lat_lon_rpt"/>
  <field name="lat_lon_rpt"  type="location_rpt"   indexed="true" stored="true" />
3. Solr再起動

この後データを再度登録し、lat_lon_rptにデータが入っていることを確認して下準備は完了 

任意の範囲を検索

説明 を読むと、

&q=:&fq={!field f=geo}Intersects(POLYGON((-10 30, -40 40, -10 -20, 40 20, 0 0, -10 30)))

という指定で範囲の指定ができるようです。 つまり、Intersects(POLYGON((...))) の中に、先のkmlのcoordinatesの内容を使えばいけそうです。 手で加工するのも面倒なので、Pythonの力を借りて検索しちゃいましょう。

ikyu-advent-2017-spatial.py (Python3.6.xで実行)

import re
import urllib.request
import urllib.error
import xml.etree.ElementTree as et

def main():
    root = et.parse('ikyu-advent-2017-spatial.kml').getroot()  # 先程のkmlファイルを読み込み
    polygon = root.findtext(".//{http://www.opengis.net/kml/2.2}coordinates")  # coordinates内の文字列を取得

    polygon = re.sub(r'\s+', '\n', polygon)  # スペースをトリミング
    polygon = re.sub(r',0$', '', polygon, flags=re.MULTILINE)  # 行末の.0を削除
    lon_lats = [_.split(",") for _ in polygon.split('\n')]
    lon_lat_str = ",".join([f'{_[0]} {_[1]}'  for _ in lon_lats if len(_) == 2])  # lon1 lat1,lon2 lat2,lon3 lat3... の組み合わせの文字列を生成

    query = (
        ('wt', 'json'),
        ('echoParams', 'none'),
        ('rows', '120'),
        ('fl', 'restaurant_id, restaurant_name,lat_lon'),
        ('q', '*:*'),
        ('fq', f'{{!field f=lat_lon_rpt}}Intersects(POLYGON(({lon_lat_str})))'),
    )

    url = "http://localhost:8888/solr/ikyu-advent-2017-spatial/select?" + urllib.parse.urlencode(query)
    print(url)
    print("-------------------")

    with urllib.request.urlopen(url) as req:
        try:
            response = req.read().decode('utf-8')
            print(response)
        except urllib.error.HTTPError as e:
            print("HTTPError")
            print(e.reason)
        except Exception as e:
            print(e)

if __name__ == '__main__':
    main()

出力されたURL

http://localhost:8888/solr/ikyu-advent-2017-spatial/select?wt=json&echoParams=none&rows=120&fl=restaurant_id, restaurant_name,lat_lon&q=*:*&fq={!field f=lat_lon_rpt}Intersects(POLYGON((139.7344959 35.6802109,139.7360516 35.6778317,139.7344422 35.6766465,139.7351772 35.6739926,139.7361803 35.6719924,139.7388196 35.67116,139.7404772 35.672341,139.7392058 35.673352,139.7372103 35.680516,139.7344959 35.6802109)))

取得結果

45件取得されました

{
  "responseHeader": {
    "status": 0,
    "QTime": 1
  },
  "response": {
    "numFound": 45,
    "start": 0,
    "docs": [{
      "restaurant_id": "100197",
      "restaurant_name": "赤坂浅田",
      "lat_lon": "35.6738200,139.738229"
    }, {
      "restaurant_id": "100729",
      "restaurant_name": "個室会席 北大路 赤坂茶寮",
      "lat_lon": "35.6752587,139.738609"
    }, 
    /* ---- 略 ---- */
    {
      "restaurant_id": "107172",
      "restaurant_name": "赤坂 金舌",
      "lat_lon": "35.6746016,139.737555"
    }, {
      "restaurant_id": "107347",
      "restaurant_name": "ビストロMATSU",
      "lat_lon": "35.6760843,139.735606"
    }, 
    /* ---- 略 ---- */
    {
      "restaurant_id": "108549",
      "restaurant_name": "鉄板焼877",
      "lat_lon": "35.676792,139.73558"
    }, {
      "restaurant_id": "108862",
      "restaurant_name": "焼肉しゃぶしゃぶシャンボール",
      "lat_lon": "35.6745112,139.736611"
    }]
  }
}

この45件のみで地図にプロットしなおすとこの通り。

f:id:ikyu_com:20171222135928p:plain

見事、徒歩圏内のレストランのみに絞り込むことに成功しました。 45件、コンプリートの道は遠そうです。

まとめ

  • 範囲指定の情報の作成はGoogleのマイマップを使うと楽
  • 任意の範囲で検索するためにはJTSが必要
  • KMLデータをSolrの検索条件に変換する処理はPythonなりで自動化可能

この結果を活かして、検索をもっと使いやすく、便利にしていきたいと思います。

明日は id:ryo-utsunomiya さんの「一休.comスマホ版予約入力画面リニューアルの舞台裏」です。

Dev旅のススメ。オフサイト・開発合宿におすすめな宿3選

この記事は一休.comアドベントカレンダー2017の 21日目です。

qiita.com

一休コンシェルジュ(https://www.ikyu.com/concierge/)のディレクターをしているid:aitamxです。2017年1月に一休にJoinし、もうすぐ1年となります。
アドベントカレンダーの一枠をいただいたので、『月1でのリリースサイクルの回し方』的な投稿も考えましたが、 それは別の機会とし、メディアっぽい内容のエントリーにしました。
箸休め的な形で愉しんでいただければ幸いです。

今回は一休.com掲載施設で、オフサイトや開発合宿、ハッカソンといったエンジニアが使うシーンに合いそうな宿をご紹介します。

\オフサイト・開発合宿で必要な設備/

◆ 何はなくともWi-Fi環境
◆ プロジェクタ・モニター・ホワイトボード
◆ 非日常な滞在

オフサイト・開発合宿におすすめな宿3選

オフサイトミーティングや開発合宿をするにあたり、自分たちで機材を持ち込む方もいらっしゃると思いますが、とはいえホワイトボードを持ってくのは何かとツラいですよね。
それに何かとかさばる荷物は少しでも減らしたいところ。
また、「非日常な滞在」=絶景やオシャレなインテリア、美味しい空気の中で得られるフレッシュな感覚は、クリエイティビティを必要とされる開発者の皆さんにこそ体験していただきたいので、必要項目に入れました。

しかし、条件をクリアした施設は、探してみると意外にありません。

\ マ ジ か マ ジ で か /

焦りながら結構な時間を費やし、営業の方にもアドバイスをいただき、バケーションレンタル(貸別荘)・リゾートホテル・旅館の3施設を厳選しました。

団体旅行にも。千葉の「バケーションレンタル(高級貸別荘・コンドミニアム)」

Cairns House (ケアンズハウス) オフサイト・開発合宿におすすめな宿3選

【おすすめポイント】
・とっても豪邸
・「ホワイトボード」「スクリーン」の貸出付きの宿泊プランがある
・一棟貸し切りなので、会議室代がかからずに作業に没頭できる

こちらは千葉の館山に位置する施設で、一棟貸し切りなので自分たちが自由にアレンジできます。
とてもゴージャス&オシャレな空間で、柔軟なアイデアが生まれそう。
別館を含めて利用すると、最大15名利用ができます。

人数少なめなスタートアップ企業の合宿にいかがでしょうか。
▼Cairns Houseについての詳しい紹介記事
こんなお家に住みたい!が叶う、憧れの豪邸 | 一休コンシェルジュ

箱根のリゾートホテルでオン&オフの滞在

ハイアット リージェンシー 箱根 リゾート&スパ オフサイト・開発合宿におすすめな宿3選

【おすすめポイント】
・広くて居心地のよい客室で、プライバシーが保たれる
・「ホワイトボード」「スクリーン」のある会議室では、窓越しに明星ヶ岳の大文字を見渡せる
・付属のレストランが美味しい

オフサイト・開発合宿におすすめな宿3選 強羅の自然を感じられるスパリゾート。上質な空間で、さすがハイアットといった安心感があります。
56平米という広々とした開放的な客室は、ゆったりくつろげる雰囲気。雑魚寝苦手な方が多いときには、ホテルは気楽です。
ホテル内のレストラン&バーが複数あるので、チームメンバーの好みに合わせたランチやディナーが楽しめるのもいいですね。
エグゼクティブな雰囲気に包まれ、濃縮したパワーミーティングをしたい方に。

友ヶ島、淡路島、四国を望む絶景宿でパワーチャージ

休暇村 紀州加太 オフサイト・開発合宿におすすめな宿3選 【おすすめポイント】
・紀淡海峡を望む絶景で湯ったりできる
・最大100名利用可能な和室の会議室
(ワイヤレスマイク・ホワイトボード・プロジェクター・スクリーン完備)
・紀州の旬の食材を使った豪快な海の幸を満喫

オフサイト・開発合宿におすすめな宿3選 高級宿泊施設のイメージがある一休.comですが、実は休暇村の予約もできることはご存知でしょうか。
こちらの「休暇村 紀州加太」は開放感のある眺望と、四季を感じる海の幸を堪能できる施設です。
露天風呂は最近はやりの「インフィニティ風呂」!
雄大な自然の中で煮詰まった頭をリフレッシュしたら、インスピレーションがわきそうですね。

まとめ

「オフサイト・ミーティング」といっても、各企業で解釈がさまざま。
「組織力向上」や「目標・ミッション理解」、「事業部毎の課題解決」を目的とし、チームビルディングに活用されている企業も多いと聞きます。(一休でも実施しています)
業務中の会話はSlackやhipchatだけということもあるかもですが、たまに場所を変えてミーティングをすると思わぬ発見があるかもしれません。

また、今回改めて施設を探しましたが、国内にはまだまだ開発合宿向きの施設が多くないと感じました。(特に、プロジェクター+ホワイトボード+Wi-Fiの貸し出しに対応している施設が少ない)
貸別荘等を利用するケースも多いかと思いますが、自分たちで何でもしないといけないのって結構大変だったり…。
新サービスのアイデアブレストや、プロトタイプ作成、興味のある技術やトレンドをみんなで味見…など、開発合宿といっても目的はひとそれぞれ。
ニーズに合わせた宿選びができるよう、おすすめ施設を見つけたら、定期的にご紹介していこうと思います。

明日はnigauryyyさんの「KMLを元にしたSolrの空間検索に挑戦」です。