サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Appleイベント
user-first.ikyu.co.jp
CTO 室の恩田です。 今回は GitHub Copilot Enterprise を評価してみて、現時点ではまだ採用しないことを決めた、というお話をご紹介したいと思います。 きっかけ とあるエンジニアが Slack で自身の times チャネルに時雨堂さんの GitHub Copilot Enterprise のススメという記事を投稿したことが発端でした。特に感想はなく URL に 👀 だけが添えられていたので、後で見るぐらいのメモだったんだと思います。 それを見かけた別のエンジニアが技術雑談チャネルにその投稿を共有して、これは凄そうと話題を向けたところ、CTO の「評価してみる?」の一言で、有志が集って評価プロジェクトが始まりました。 雑談チャネルできっかけとなる投稿が共有されてから、30分足らずの出来事でした(笑)。 この話題が出たのは金曜日でしたが、週明け早々に稟議を終え、火曜
一休.comでWebフロントエンドを開発している宇都宮です。 先日、一休.comホテルページのスマホ版から、jQueryを取り除きました。jQueryを取り除いた経緯、やったこと、結果について書きます。 ちなみに、ホテルページには以下のURLでアクセスできます(スマホで開くか、PCの場合はUAをスマホに偽装する必要があります) https://www.ikyu.com/sd/00001290/ なぜjQueryを取り除いたのか? どうやったのか 何をやったのか jQuery.ajax() => fetch に置き換え fetchのpolyfillを採用した理由 DOM操作を標準APIに置き換え 要素の取得 show/hide addClass/removeClass html/text アニメーション $.ready() イベントフィルタリング jQueryの使用を防ぐ目印 jQuery削
レストラン事業部エンジニアの id:ninjinkun です。 一休レストランでは10年以上動いているシステムをPython 3で書かれた新システム(以下restaurant2)に順次移行する作業を進めています。現在ではPC用のレストランページ や主要な API を含め、いくつかのページがrestaurant2で提供されるようになっている状態です。本記事ではこの移行の経緯と、restaurant2システムの詳細、Pythonを選んだ理由、現在の進捗状況をお伝えします。 経緯 一休レストランはサービスローンチ時よりClassic ASP(言語はVBScript)でシステムが構築されてきました(こちらに驚かれる方も多いと思いますが、歴史的経緯という言葉で強引にまとめて話を先に進めます)。このシステムは現在も一休レストランを支えているのですが、長年の改修による複雑性の増加、言語の古さ、言語機能の
今から二ヶ月ほど前、10/1 に Yahoo! トラベル のリニューアルが完了しました。このリニューアルは、一休.com と Yahoo! トラベルの2システムを一つに統合することで実現しました。 ご存知の通り、ヤフーと一休は同じグループに所属する企業です。ざっくりいうと「同じグループで2つの宿泊予約システムを開発し続けるのは効率が悪いよね」という話があり、今回のシステム統合に至っています。 Yahoo! トラベルと一休のシステム統合は、(1) 2017年頃にホテルの空室管理や予約、決済、精算業務などを担うバックエンドのシステム統合を行い、そして (2) 今回 2021年春先から半年ほどをかけて、ユーザーが利用する画面も含めた全面統合を行いました。全面統合は総勢で 50名ほどのディレクター、エンジニア、デザイナーが関わる一休的には大きな規模のプロジェクトになりましたが、目立ったトラブルもな
この記事は一休.com アドベントカレンダーの24日目の記事です。 qiita.com 社内情報システム部の大多和(id:rotom)です。 一休には2018年8月に入社し、情報システムエンジニアとして、IT を活用した業務改善、オフィス環境の構築を中心とした社内の「情シス」業務全般を担当しています。 本エントリでは、表立って登場することの少ない「情シス」が普段何をしているか、ご紹介していきます。 情シスのお仕事 社内情報システム部は「システム本部」に所属しており、現在 6人 のメンバで業務を行っています。 一休における情シスは以下の2つの側面を持っています。 コーポレートエンジニアリング:社内ツールやシステムの導入及び管理運用、bot やスクリプト開発による業務の効率化などの業務改善の他、オフィスの IT インフラ環境の構築、改善など、IT を活用し、より社員がよりパフォーマンスを発揮で
一休.com レストランは今年の 7 月 18 日、スマートフォン向け検索ページのリニューアルを行いました。このエントリーでは、その中身について少し紹介させていただきます。 検索ページの課題 一休.com レストランではスマートフォン向け検索ページに対して「遅い」という課題意識がありました。これは技術面で少しブレイクダウンすると; パーソナライズドを含む複雑な処理を行っているため、サーバーサイド処理が重い。 UI 上無駄な遅延処理を行っているため、クライアントサイドの描画が遅い。 というサーバー側とクライアント側両方の課題がありました。クライアントサイドの「無駄な遅延処理」というのは; 検索結果取得が REST API 化されているにも関わず、再検索の度にページリロードを行い、サーバーサイドの描画からやり直している。 という実装に問題がありました。下図がリニューアル前のページ描画の様子です
フロントエンドエンジニアのid:ninjinkunです。この記事は一休.comアドベントカレンダーの1日目の記事です。 一休.comレストランの管理画面リニューアルプロジェクトにおいて、CSSフレームワークのBulmaを導入しました。結論としては、採用して良かったと思っています。 このエントリではBulmaを選定した理由と、採用後に見えたPros / Consについて述べたいと思います。 なお今回リニューアルした一休.comレストランの管理画面の概要は以下の通りです。 レストラン店舗向けの管理画面 店舗の方と一休スタッフの両方が使う DAUは数千の規模 主な用途は在庫の管理と、プラン(コース)や席の管理 現在は店舗を限定してリリース済み 具体的には以下のような画面で構成されています。 UIフレームワークは必要か? まずそもそもUIフレームワークは必要かという議論があります。 今回のプロジェ
こんにちは、一休.comスパ(以下、「スパ」)の開発を担当しているshibataiと申します🙏 今回はスパのデータベースの在庫の持ち方で試行錯誤した話をさせていただきます。 背景 2024-03-29追記: 一休.comスパにおける在庫の特徴について 一休.comスパが扱う「在庫」は、「ある日付の特定の時間に対する空き枠」です。以降の説明では、スパ施設ごと、日付ごと、また時間ごとに増えていく「在庫」をいかに効率よく扱うかについて説明しています。 詳細については次のスレッドも参照してください! https://t.co/Y0SPmDE4yZ この記事のコメントみてると、少し我々のシステムの要件が伝わってないというかそこの説明が記事に不足しているように思った。ので以下その補足— naoya (@naoya_ito) March 29, 2024 現在の実装 スパは予約を受け付けるために在庫の
はじめに こんにちは、一休.comデータサイエンス部の平田です。 みなさんChatGPT活用してますか? 一エンジニアとして便利に使ってはいるものの、自社サービスにどのように組み込もうか模索しているところも多いかもしれません。 一番の利用先として思いつくのが、自社の情報をもとに質問に答えるチャットボットではないでしょうか。 その中では、ハイコンテキストな検索(例えば、「東京から2時間以内で子供も楽しめるアクティビティがあって、景色も良い宿」のような)にも答えられるとボットの価値が増します。 ChatGPTが事前に学習した内容では古く、正確ではないためそういった検索に応えるのはかなり厳しいです。 そのため、こちら側が持っているデータを渡してあげる必要があるのですが、今回はその自社の情報をどう組み込むのか、という部分についてご紹介します。 素のChatGPTでは? ChatGPTに例えば「熱海
宿泊開発チームでエンジニアをしている @itinao です。 昨年の10月に入社しました。 今回は GitHub Projects を利用したタスク管理について記載します。 なんとなーく GitHub Projects 使うと、KANBANにしてみたり リストにして使ってみたり で終わってしまいます。 もっと色々できるんだよってことが伝えられればと思います。 背景 どんな機能があるか Custom Fields Views Group by Slice by Workflows ISSUEと Pull requestの紐づけ Insights タスクの進め方 タスクの洗い出し 見積もり 現状の課題と今後の展望 まとめ さいごに 背景 一休ではチームごとにタスクの管理方法が違い、 Google Spreadsheet・GitHub Projects・Jiraなど、チームごとにタスク管理の方法
こんにちは。宿泊事業本部の宇都宮です。 最近、とあるマイクロサービスをローンチしました。このアプリケーションの業務的な役割は諸事情により省略しますが、以下のような特性をもっています。 社内の多くのサービスから利用される 一休.com 一休.comレストラン 一休.comギフト 一休.com海外 このサービスが落ちると、主要サービスの予約処理が止まる 😱 想定されるリクエスト数は、平常時で30req/sec、ピーク時には60req/sec程度になります。行う処理はシンプルで、DBにいくつかSELECT文を投げて、ビジネスロジックに沿った結果を返すことです。 また、基盤系のアプリケーションなので、各開発者の開発環境(WindowsとMacが混在)でも動作する必要があります。 したがって、このアプリケーションに求められる要件は、 高パフォーマンス 高信頼性 クロスプラットフォームで動作すること
こんにちは。 一休.comの開発基盤を担当しています、akasakasです。 今回は、E2EテストをSelenium WebdriverからCypress.ioに移行した話をしたいと思います。 一休のE2Eテスト事情 あれから、数年が経過して、、、 どうしてこうなった??? SeleniumではSPAへの対応が難しくなってきた なんでもかんでもSeleniumで頑張ろうとした弊害 いざリプレイスへ・リプレイスをする上で気をつけたこと 開発者フレンドリー 安定性 然るべきレイヤーでテストする(何でもかんでもブラウザテストにしない) 技術選定 Cypress.io とは? Cypress.io のいいところ セットアップが楽 テストを書くことだけに集中できる CI連携が楽 Cypress.io の頑張って欲しいところ その他、移行に関しての細かい話 重複テストケースの排除 Page Objec
この記事は一休.comアドベントカレンダー2017の 8 日目です。 一休.com の宿泊開発基盤のお手伝いをしている id:shiba-yanです。 はてなインターン時代の縁で naoya さんから声をかけていただき、基本フリーランスですが一休で週に 3 日ほどの作業を 2016 年 4 月から行っています。 最近は shibayan とも一緒に改善を進めている 4ヶ月の間に一休.comで起きた変化 - zimathon blog 2016 年 4 月末から現在までに、一休社内でどのようなことに取り組んできたか、公開できる範囲で思うままに書いていきます。長いです。 ユニットテスト基盤 新しいメールテンプレート メール配信基盤 宿泊クラウド移行 移行方法の調査・検証 実行環境の調査・検証 アプリケーションの分離と整理 AppVeyor での CI / CD 本番環境の移行 その後の運用 宿
Apollo Client は複雑 Apollo Client が向いているケース 一休.com に Apollo Client は必要ないかもしれない では何を使えばいいの? 複雑なアプリケーションには Apollo を使えばいい? もう一つのリッチなクライアント、Relay の話 結局、何を使えばいいのか この記事は一休 × 出前館 Frontend Meetup でお話した内容をブログにまとめたものです。 user-first.ikyu.co.jp speakerdeck.com GraphQL クライアントと聞いて一番に思い浮かぶライブラリは何でしょうか? 多くの方にとっては Apollo Client ではないかと思います。npm trends を見ても Apollo Client のダウンロード数は urql や relay などほかのクライアントと比べ圧倒的です。 実際、一休
このエントリーは一休.com Advent Calendar 2023の15日目の記事になります。 CTO 室の恩田です。 現在は一休レストランのフロントエンドのリアーキテクトを手がけています。 今日はその中で Next.js App Router から Remix に乗り換えた話をご紹介したいと思います*1。 背景 6日目の記事で香西から紹介させていただきましたが、2023年10月に一休レストランのスマートフォン用レストラン詳細ページをリニューアルしました。 一休レストランの Rust バックエンドが正式リリースされました。https://t.co/7N4VGv5ej9 このページのスマートフォンビューはバックエンドが Rust で書かれた GraphQL になってます— naoya (@naoya_ito) 2023年10月4日 ちなみにフロントエンドも、旧バージョンは Nuxt v2
宿泊事業本部の宇都宮です。 一休.com スマホサイトのホテルページパフォーマンス改善プロジェクトでは、フロントエンドには以下のような要件がありました。 デザイン面は既存を踏襲する 機能はほぼ従来通り 日付等を変更した際の再検索は、画面遷移を挟まず、画面内で行えるようにする パフォーマンスをできるだけ改善する 要するに、従来と同様の機能+αを実現し、かつ、従来と同等以上のパフォーマンスを実現する、というミッションです。 このために、どのような取り組みを行ったか、紹介します。 パフォーマンス目標値の設定 まず、パフォーマンスの目標値を設定する必要があります。モバイルでは、ユーザの帯域幅は回線や時間帯によって大きな変動があります。多少回線状況が悪くても、閲覧を妨げない程度のパフォーマンスを実現する必要があります。 一休へアクセスするユーザのモニタリングを見ると、極端に遅い回線を使っているユーザ
宿泊事業本部フロントエンドエンジニアの宇都宮です。 2018年度下期は、一休.comホテルリストページ スマホ版の速度改善に取り組んできました。その結果、ページのデザインはそのまま、機能面はリッチにしつつ、プロジェクト開始前の約2倍のスピードでページが表示されるようになりました。 本記事では、高速化のためにどのような施策を行ったのか紹介します。 なお、Webサイトの高速化手法については、ホテル詳細ページ高速化プロジェクトを実施した際にも記事を書いています。これらの記事で紹介している手法(たとえば、Imgixによる画像最適化等)については、記述を省略しています。あわせてご覧ください。 一休.comスマホサイトのパフォーマンス改善(概要編) - 一休.com Developers Blog 一休.comスマホサイトのパフォーマンス改善(JavaScript編) - 一休.com Develop
宿泊開発チームでエンジニアをしている @kosuke1012 です。チームで ADR を書き始めて1年くらい経ったので、その感想を書いてみたいと思います。 この記事は 一休.comのカレンダー | Advent Calendar 2023 - Qiita の13日目の記事です。 ADRとは アーキテクチャ・ディシジョン・レコードの略で、アーキテクチャに関する意思決定を軽量なテキストドキュメントで記録していくものです。 出典はこちらで、 Documenting Architecture Decisions わかりやすい和訳は以下の記事が、 アーキテクチャ決定レコードの概要 | Cloud アーキテクチャ センター | Google Cloud アーキテクチャ・デシジョン・レコードの勧め | 豆蔵デベロッパーサイト アーキテクチャの「なぜ?」を記録する!ADRってなんぞや? #設計 -
一休.comではオンプレミスで動かしていたサーバー群をAWSに移行する作業を2016年末から2年がかりで進めてきました(以下、クラウド移行と呼びます)。2017年7月にまず全サービスのアプリケーションサーバー移行が完了、2018年2月にデータベースであるSQL Serverの移行が終わり、クラウド移行が完了しました。 一休のシステムは予約や決済などのミッションクリティカルな基幹業務を担ってるため、大規模なシステム移行は難易度が高い仕事でした。また、一休のサービスは予約を取り扱うECの一種であるため、トランザクション機能をはじめとする、DBに対する品質要求水準や機能要件も比較的厳しい環境です。 本記事ではこのクラウド移行の中でも特に難易度が高いDBの移行を牽引したkudoyに、移行計画の設計や勘所についてインタビューします。 インタビュイー kudoy デジタルマーケティング部エンジニア(写
2018年4月、データセンター完全クローズ 一休は、今年の4月にデータセンターを完全にクローズしました。現在、すべてのサービスをAWSを使って提供しています。 この過程で各種運用ツールやビルド/デプロイのパイプラインなどをすべて外部サービスを使うように変更しました。 これによって、インフラエンジニアやサービス運用担当者の役割や業務が大きく変わりました。本稿では、その背景を簡単に紹介したいと思います。 ざっくり言えば、 物理サーバのセットアップ&データセンターへの搬入のような仕事はなくなった。 アプライアンスの保守契約、パッチ適用、運用ツールのバックアップのような仕事もなくなった。 各種メトリクスを見ながら、Infrastructure as Codeでクラウドリソースの管理や調整をする仕事がメインになった。 必要に応じて、プロダクトのソースコードに踏み込んで必要な改修を行い、サービスの安定
この記事は一休.com アドベントカレンダーの25日目の記事です。 レストラン事業部エンジニアのid:ninjinkunです。 一休.com及び一休.comレストランはユーザー向けのシステムだけではなく、店舗や一休内の管理者向けの業務システムという性格も持っています。 業務システム経験の無かった自分が一休に転職して最初に驚いたのが、DBに履歴を保持するための履歴テーブルが大量にあることでした。 そこから履歴テーブルの存在に興味と疑問を持ち、社内外のエンジニアと履歴テーブルについて議論してきました。このエントリではそれらの議論をまとめた結果について書いていきます。 履歴テーブルのパターン まず以下の図をご覧ください。 込み入った図かつ事例が一休特化で恐縮ですが、左上の起点から始まって、右のオレンジの部分が最終的な実装パターンです。 図にあるとおり、たいていのユースケースでは以下の3パターンの
この記事は 一休.comのカレンダー | Advent Calendar 2023 - Qiita 10日目の記事です。 昨今は Web アプリケーション開発の世界でも、関数型プログラミングのエッセンスを取り入れるような機会が増えてきました。 とはいえ、一つのアプリケーションを 1 から 10 までがっちり関数型プログラミングで構成するというわけではなく、そのように書くこともあればそうでない従来からの手続き的スタイルで書くところもあるというのが現状で、どこまで関数型プログラミング的な手法を取り入れるかその塩梅もまちまちだと思います。まだ今はその過渡期という印象も受けます。 本稿ではこの辺りを少々考察してみたいと思います。 先日、Qiita Conference 2023 Autumn で以下のテーマで発表を行いました。 この発表では「関数型プログラミング最強!」という話をしたわけではなく、
この記事は一休.com Advent Calendar 2023 25日目の記事です。 一休レストランでは、よりスムーズな予約体験の提供を目的とするシステムのリニューアルを進めています。その一環として、2023年10月から、レストラン個別ページの表示から予約までのスマートフォンビューにおいて、バックエンドのサーバをRustで書かれたものに置き換えました。 一休レストランの Rust バックエンドが正式リリースされました。https://t.co/7N4VGv5ej9 このページのスマートフォンビューはバックエンドが Rust で書かれた GraphQL になってます— naoya (@naoya_ito) October 4, 2023 本番運用が始まって3か月近く経ちましたが、これまで安定して継続的な開発と運用ができています。これはRustだからと構えることなく、「ふつう」のバックエンド
こんにちは。 一休.comの開発基盤を担当しています、akasakasです。 今回は、一休.comスマートフォンホテルページリニューアルをリリースし、パフォーマンスが改善した話を書きます。 概要編はこちらになります。 user-first.ikyu.co.jp JavaScriptパフォーマンス改善編はこちらになります。 user-first.ikyu.co.jp CSS・その他パフォーマンスチューニング編はこちらになります。 user-first.ikyu.co.jp この記事ではスマートフォンホテルページリニューアルで実施したサーバサイドチューニングについて書きます。 ここでお話しする内容 サーバサイドチューニング前後のOverview プロジェクトの大まかなタイムライン ボトルネック洗い出し 対策 SQL改善 不足インデックスの設定 => 600msの改善 複雑なselect文をシン
レストラン事業本部の田中( id:kentana20 )です。 先週末にDevLOVE Xというイベントで開発組織改善の取り組みについて5年間の取り組みと今後、というテーマでお話しました。 5年間でどれくらい一休の開発組織が変わったのか 技術面 組織面 それぞれで実施した改善について、改善の裏側で起こっていたことや自分の所感も含めてお話しました。 現在の一休について7/4(木)にお話します 来週開催するエンジニア向けの説明会で、上記の5年間の取り組みを経て、現在の一休がどうなっているのかをCTOの伊藤がお話します。 ikyu.connpass.com 説明会と書いていますが、会社・事業や開発体制のお話だけでなく 現在の開発組織やプロダクトの状況がどうなっているか 今後どのように改善を進めていくのか を含めてお話する予定です。 一休で働くことに興味がある方だけでなく いまの現場を改善するため
一休.com レストランを開発している所澤です。この記事は一休.comアドベントカレンダーの10日目の記事です。 先日、一休.comレストランの管理画面をリニューアルしました。 この記事ではその際にAPIの実装方法として採用したGraphQLについてフロントエンド視点で利点や使い所について述べます。 GraphQLについて以下の記事がわかりやすかったです。 「GraphQL」徹底入門 ─ RESTとの比較、API・フロント双方の実装から学ぶ - エンジニアHub|若手Webエンジニアのキャリアを考える! 短いまとめ 新しくAPIサーバーを書くなら是非GraphQLで! というくらい良かった Apolloのエコシステムに乗り切らなくてもいい。ふつうのRESTfulなAPIサーバーの代わりに、くらいの気軽さでGraphQLを採用してもいい プロジェクトの概要 今回リニューアルした一休.comレ
ヤフー株式会社より出向しております、卯田と申します。 主務で、一休.comおよびYahoo!トラベルのフロントエンド開発を担当しています。 兼務で、ヤフー株式会社の全社横断組織でWebパフォーマンス改善の推進を行っております。 本稿では、直近半年弱(2023年2月〜8月)で、断続的に行っていた一休.comのパフォーマンス改善について振り返ります。 開始が2023年2月となった理由は、Nuxt3バージョンアップ以降にパフォーマンス改善活動に着手したためです。 一休.com/Yahoo!トラベルのNuxt3バージョンアップ詳細については、以下のブログをご覧ください。 user-first.ikyu.co.jp サイトパフォーマンス改善の意義 改善の方針 方針1: Core Web Vitalsを改善する 方針2: 重要課題から優先的に対応する 改善の進め方 可視化 ブラウザサイド サーバーサイ
一休.comレストランのエンジニアのkymmtです。 2023年度の下半期、一休.comレストランの開発チームでは開発プロセス改善に取り組みました。改善は小さい単位で徐々に進め、バックログの作りかたやカンバンの運用方法を改善することで、フロー効率の向上、開発ペースの把握、チーム内外からの進捗の見える化ができるようになりました。 この記事では、このようなインクリメンタルな開発プロセス改善の取り組みについて紹介します。 従来の開発プロセス 主に2023年度前半の開発プロセスは次のような形でした1。 プロダクトのリリースに必要なタスクが長いバックログとして存在し、ひたすらタスクを消化 その状況に課題を感じ、区切りを入れるために2週間のスプリントを導入 この時点では、スプリントは2週間ごとに状況を確認するためのもので、目標に対するふりかえりや、次のスプリントの計画を作るためのものとしては活用してい
こんにちは。宿泊事業本部の宇都宮です。この記事では、GraphQLをベースに、GoとTypeScriptでスキーマを共有しながら開発を進める方法について紹介します。 この記事は 一休.com Advent Calendar 2019 の16日目の記事です。 GraphQLとは ライブラリの選定 コードファースト vs スキーマファースト Goによるサーバ実装 TypeScriptによるクライアント実装 おわりに 参考文献 GraphQLとは GraphQLは、Facebookによって開発された、Web APIのための クエリ言語 です。その特徴もSQLに似ていて、データの取得や更新を宣言的な記述によって行うことが出来ます。 仕様は公開されており、リファレンス実装として graphql-js がありますが、それ以外にも様々な言語でGraphQLサーバを実装できます。 GraphQLでは以下の
次のページ
このページを最初にブックマークしてみませんか?
『一休.com Developers Blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く