React / Remix への依存を最小にするフロントエンド設計 - 一休.com Developers Blog
CTO 室の恩田(@takashi_onda)です。 一休レストランのフロントエンドアーキテクトを担当しています。 Intro 一休レストランでは、以前ご紹介したようにフロントエンドで React / Remix を利用しています。 user-first.ikyu.co.jp 一方、設計方針としては、React / Remix への依存が最小になるように心掛けています。 今日は、そんな一見矛盾するような設計方針について、ご紹介したいと思います。 この記事を読んでいただき Remix に興味をもたれたら、明後日 2024/8/7(水) 19:00〜 のオンラインイベント offers-jp.connpass.com にもご参加いただけると嬉しいです。 この記事でご紹介している疎結合なフロントエンドアーキテクチャを実現する Remix の魅力についてお話します。 なぜ依存を最小にするのか？ R
E2EテストをSelenium Webdriver からCypress.io に移行した話 - 一休.com Developers Blog
こんにちは。 一休.comの開発基盤を担当しています、akasakasです。 今回は、E2EテストをSelenium WebdriverからCypress.ioに移行した話をしたいと思います。 一休のE2Eテスト事情 あれから、数年が経過して、、、 どうしてこうなった？？？ SeleniumではSPAへの対応が難しくなってきた なんでもかんでもSeleniumで頑張ろうとした弊害 いざリプレイスへ・リプレイスをする上で気をつけたこと 開発者フレンドリー 安定性 然るべきレイヤーでテストする（何でもかんでもブラウザテストにしない） 技術選定 Cypress.io とは？ Cypress.io のいいところ セットアップが楽 テストを書くことだけに集中できる CI連携が楽 Cypress.io の頑張って欲しいところ その他、移行に関しての細かい話 重複テストケースの排除 Page Objec
一休の1 to 1マーケティングを支えるプラットフォーム - 一休.com Developers Blog
データサイエンス部・大西 id:ohke です。 一休の1 to 1マーケティングを支えるプラットフォームについてお話したいと思います。 1 to 1マーケティング 一休の主力である宿泊予約サービスは今年で19年目、レストラン予約サービスも13年目を迎え、会員数も800万人を超えました。 一休のサービスを「知らなかった」から「知っている」という成熟フェーズに入ってきますと、集客に加えて、1 to 1マーケティングがより重要になってきてます。 一休の1 to 1マーケティングで大事にしていることは3点です。 施策に必要なデータは全てデータウェアハウス (DWH) へ集約する オートメーションツール (内製のWebアプリケーション) でターゲットの抽出、コンテンツの作成、配信を一元管理する ユーザごとにコンテンツを最適化する (レコメンド) DWHとETL 1 to 1マーケティングでは、ユー
履歴テーブルについて - 一休.com Developers Blog
この記事は一休.com アドベントカレンダーの25日目の記事です。 レストラン事業部エンジニアのid:ninjinkunです。 一休.com及び一休.comレストランはユーザー向けのシステムだけではなく、店舗や一休内の管理者向けの業務システムという性格も持っています。 業務システム経験の無かった自分が一休に転職して最初に驚いたのが、DBに履歴を保持するための履歴テーブルが大量にあることでした。 そこから履歴テーブルの存在に興味と疑問を持ち、社内外のエンジニアと履歴テーブルについて議論してきました。このエントリではそれらの議論をまとめた結果について書いていきます。 履歴テーブルのパターン まず以下の図をご覧ください。 込み入った図かつ事例が一休特化で恐縮ですが、左上の起点から始まって、右のオレンジの部分が最終的な実装パターンです。 図にあるとおり、たいていのユースケースでは以下の3パターンの
インフラエンジニアからSREへ ～クラウドとSaaS活用が変えるサービス運用のお仕事～ - 一休.com Developers Blog
2018年4月、データセンター完全クローズ 一休は、今年の4月にデータセンターを完全にクローズしました。現在、すべてのサービスをAWSを使って提供しています。 この過程で各種運用ツールやビルド/デプロイのパイプラインなどをすべて外部サービスを使うように変更しました。 これによって、インフラエンジニアやサービス運用担当者の役割や業務が大きく変わりました。本稿では、その背景を簡単に紹介したいと思います。 ざっくり言えば、 物理サーバのセットアップ&データセンターへの搬入のような仕事はなくなった。 アプライアンスの保守契約、パッチ適用、運用ツールのバックアップのような仕事もなくなった。 各種メトリクスを見ながら、Infrastructure as Codeでクラウドリソースの管理や調整をする仕事がメインになった。 必要に応じて、プロダクトのソースコードに踏み込んで必要な改修を行い、サービスの安定
一休.comレストランのスマートフォン検索ページがSPAになりました - 一休.com Developers Blog
一休.com レストランは今年の 7 月 18 日、スマートフォン向け検索ページのリニューアルを行いました。このエントリーでは、その中身について少し紹介させていただきます。 検索ページの課題 一休.com レストランではスマートフォン向け検索ページに対して「遅い」という課題意識がありました。これは技術面で少しブレイクダウンすると; パーソナライズドを含む複雑な処理を行っているため、サーバーサイド処理が重い。 UI 上無駄な遅延処理を行っているため、クライアントサイドの描画が遅い。 というサーバー側とクライアント側両方の課題がありました。クライアントサイドの「無駄な遅延処理」というのは; 検索結果取得が REST API 化されているにも関わず、再検索の度にページリロードを行い、サーバーサイドの描画からやり直している。 という実装に問題がありました。下図がリニューアル前のページ描画の様子です
一休.comスマホサイトのパフォーマンス改善（サーバサイドとQAとリリース編） - 一休.com Developers Blog
こんにちは。 一休.comの開発基盤を担当しています、akasakasです。 今回は、一休.comスマートフォンホテルページリニューアルをリリースし、パフォーマンスが改善した話を書きます。 概要編はこちらになります。 user-first.ikyu.co.jp JavaScriptパフォーマンス改善編はこちらになります。 user-first.ikyu.co.jp CSS・その他パフォーマンスチューニング編はこちらになります。 user-first.ikyu.co.jp この記事ではスマートフォンホテルページリニューアルで実施したサーバサイドチューニングについて書きます。 ここでお話しする内容 サーバサイドチューニング前後のOverview プロジェクトの大まかなタイムライン ボトルネック洗い出し 対策 SQL改善 不足インデックスの設定 => 600msの改善 複雑なselect文をシン
一休.comスマホサイトのパフォーマンス改善（JavaScript編） - 一休.com Developers Blog
宿泊事業本部の宇都宮です。 一休.com スマホサイトのホテルページパフォーマンス改善プロジェクトでは、フロントエンドには以下のような要件がありました。 デザイン面は既存を踏襲する 機能はほぼ従来通り 日付等を変更した際の再検索は、画面遷移を挟まず、画面内で行えるようにする パフォーマンスをできるだけ改善する 要するに、従来と同様の機能+αを実現し、かつ、従来と同等以上のパフォーマンスを実現する、というミッションです。 このために、どのような取り組みを行ったか、紹介します。 パフォーマンス目標値の設定 まず、パフォーマンスの目標値を設定する必要があります。モバイルでは、ユーザの帯域幅は回線や時間帯によって大きな変動があります。多少回線状況が悪くても、閲覧を妨げない程度のパフォーマンスを実現する必要があります。 一休へアクセスするユーザのモニタリングを見ると、極端に遅い回線を使っているユーザ
一休レストランPython移行の進捗 - 一休.com Developers Blog
レストラン事業部エンジニアの id:ninjinkun です。 一休レストランでは10年以上動いているシステムをPython 3で書かれた新システム（以下restaurant2）に順次移行する作業を進めています。現在ではPC用のレストランページ や主要な API を含め、いくつかのページがrestaurant2で提供されるようになっている状態です。本記事ではこの移行の経緯と、restaurant2システムの詳細、Pythonを選んだ理由、現在の進捗状況をお伝えします。 経緯 一休レストランはサービスローンチ時よりClassic ASP（言語はVBScript）でシステムが構築されてきました（こちらに驚かれる方も多いと思いますが、歴史的経緯という言葉で強引にまとめて話を先に進めます）。このシステムは現在も一休レストランを支えているのですが、長年の改修による複雑性の増加、言語の古さ、言語機能の
一休のSQL Server AWS移行事例（前編） - 一休.com Developers Blog
一休.comではオンプレミスで動かしていたサーバー群をAWSに移行する作業を2016年末から2年がかりで進めてきました（以下、クラウド移行と呼びます）。2017年7月にまず全サービスのアプリケーションサーバー移行が完了、2018年2月にデータベースであるSQL Serverの移行が終わり、クラウド移行が完了しました。 一休のシステムは予約や決済などのミッションクリティカルな基幹業務を担ってるため、大規模なシステム移行は難易度が高い仕事でした。また、一休のサービスは予約を取り扱うECの一種であるため、トランザクション機能をはじめとする、DBに対する品質要求水準や機能要件も比較的厳しい環境です。 本記事ではこのクラウド移行の中でも特に難易度が高いDBの移行を牽引したkudoyに、移行計画の設計や勘所についてインタビューします。 インタビュイー kudoy デジタルマーケティング部エンジニア（写
一休のETL処理をAirflowで再構築しました - 一休.com Developers Blog
一休のデータサイエンス部に所属しています小島です。 以前データ分析基盤の構築で記事を上げていましたが、今回はETL*1周りの話をしようと思います。 user-first.ikyu.co.jp 今回ETLのツールとして導入したのはAirflowというツールです。 2017年のアドベントカレンダーでも紹介させていただきました。 一休のデータフローをAirflowを使って実行してみる 一休のETLの現状について 一休のETL周りは以下の画像のようになっていました。 課題 ETLの処理時間が伸びた（出社後も処理が続いていた） エラーのリカバリ作業に時間がかかる（ログが確認しにくい, サーバーに入って作業しなければいけない） 複雑な依存関係の定義がしにくい（どれとどれが依存しているかわからない） リソース負荷（全て並列で実行していた） 処理毎のボトルネックが把握できない ツールの問題というよりは正し
一休.com で 1 年半の間に取り組んできた改善内容について - 一休.com Developers Blog
この記事は一休.comアドベントカレンダー2017の 8 日目です。 一休.com の宿泊開発基盤のお手伝いをしている id:shiba-yanです。 はてなインターン時代の縁で naoya さんから声をかけていただき、基本フリーランスですが一休で週に 3 日ほどの作業を 2016 年 4 月から行っています。 最近は shibayan とも一緒に改善を進めている 4ヶ月の間に一休.comで起きた変化 - zimathon blog 2016 年 4 月末から現在までに、一休社内でどのようなことに取り組んできたか、公開できる範囲で思うままに書いていきます。長いです。 ユニットテスト基盤 新しいメールテンプレート メール配信基盤 宿泊クラウド移行 移行方法の調査・検証 実行環境の調査・検証 アプリケーションの分離と整理 AppVeyor での CI / CD 本番環境の移行 その後の運用 宿
一休.comのJavaScriptユニットテスト環境 - 一休.com Developers Blog
この記事は一休.com Advent Calenrad 2017の2日目です。 宿泊事業本部フロントエンドエンジニアの宇都宮です。 一休.comの宿泊予約サービス（以下、一休）では、以下のようなスタックでWebフロントエンドの開発を行っています。 言語：ES 2017 ライブラリ・フレームワーク：古いところはjQuery、新しいところはVue.js ビルドパイプライン：Webpack + Babel 一休では、主要導線のE2Eテストは整備されています*1。一方、フロントエンド(JavaScript)のユニットテストは発展途上といったところです。 本記事では、一休のJSユニットテスト環境の変遷と現状について紹介します。 AVA 2017年4月の時点で、一休のJSユニットテスト環境は以下のような状況でした。 テスティングフレームワーク：AVA Babelでビルドされているコード：1,000行程
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
