こんにちは、レシピ事業部プロダクト開発グループの渡邉（@taso0096）です。 クックパッドは最近、One Experienceというプロジェクトによって日本版とグローバル版のシステムが統合されました。 どちらのシステムもRailsで実装されているという点は同じですが、統合先となったグローバル版ではHotwireが使われていました*1。そのため、One Experience関連の開発ではHotwireが積極的に活用されています。本記事ではそんなHotwireの多くの機能が使われたデスクトップ版のサイドバーについてご紹介します。 デスクトップ版で表示されるサイドバー ちょっと複雑なサイドバー One Experienceに伴い、グローバル版にもともと存在したUIのまま移行するのではなく、いくつか画面構成の変更を入れる事になりました。特にデスクトップ版においては、自分のコンテンツにより素早く

こんにちは。SRE の小川 (@coord_e) です。先日の投稿にあった通り、クックパッドはレシピサービスをグローバル版に統合しました。サービスの統合に伴って、開発や運用のインフラもグローバルチームで利用されているものを使うことになりました。 運用インフラの中でも特に大きな違いとして、日本とグローバル版ではコンテナオーケストレーションの仕組みが異なっています。日本では Amazon Elastic Container Service (ECS) を使ってコンテナを実行していますが、グローバル版では Amazon Elastic Kubernetes Service (EKS) の上でコンテナを実行しています。 また開発面ではデプロイフローに大きな違いがあります。日本では、アプリケーションの新しいリビジョンのデプロイは ChatOps によって行なっていました。main ブランチに PR

SRE の鈴木 (id:eagletmt) です。先日、この開発者ブログで赤松から One Experience プロジェクトについての紹介がありました。 自分もこの One Experiene プロジェクトに携わっており、このプロジェクトが始まったちょうど1年くらい前にはイギリスにあるオフィスに行き、グローバル版のシステムを開発・運用しているメンバーと直接顔を合わせたりもしていました。自分は One Experience プロジェクトにおいて主にデータ移行について担当していました。データ移行に必要な作業はいくつかありますが、この記事ではその中から日本版のシステムのデータベースで発生したデータの変更をどのようにしてグローバル版のシステムのデータベースに継続的に反映したかの部分について紹介します。 One Experience でのデータ移行 赤松の記事にも書かれていたように、日本版とグロー

こんにちは、レシピ事業部プロダクト開発グループの赤松(@ukstudio)です。 昨年の10月頃からレシピ事業部ではひとつの大きなプロジェクトに取り組んでいました。このプロジェクトは社内ではOne experienceと呼ばれています。本記事ではこのOne experienceについてご紹介します。 追記: これまでに投稿された One Experience 関連の記事をまとめました。あわせてご覧ください。 Web ちょっと複雑なサイドバーをHotwireで簡単に作りたい - クックパッド開発者ブログ レシピIDリンク移行の話 - クックパッド開発者ブログ モバイル モバイルアプリの One Experience - クックパッド開発者ブログ Simple Custom Compose Layout - クックパッド開発者ブログ iOSアプリにおける複数リリースに跨った機能改善の開発事例紹

こんにちは。レシピ事業部バックエンド基盤グループの石川です。 2014 年、このブログに『開発環境のデータをできるだけ本番に近づける』というタイトルの記事が投稿されました。 クックパッドでは、ユーザーさんが実際に体験している状況と近い状況を再現しながら開発することに価値があると考えています。技術的には、最初からレコードがたくさんあることによってパフォーマンス問題に気付きやすくなるなどの長所がありますし、サービス開発としても、実際のユーザーさんの体験を最速でなぞって素早くフィードバックループを回せるようになるという長所があります。 この慣習は 2014 年の記事から 10 年経った今でも続いています。一方でその実現手法については変化を続けてきました。現在のクックパッドでは状況に応じていくつかの手段を使い分けています。それらの手段については今まであまり公開されていなかったような気がするため、こ

こんにちは。機械学習グループの深澤(@fukkaa1225)です。 先日、Amazon Bedrock が一般利用できるよう(GA)になりました 。本記事ではこちらを用いて RAG(Retrieval-augmented generation) アプリケーションを作成してみた様子と、他 LLM モデルとの比較結果についてご紹介します。 Amazon Bedrock とは aws.amazon.com 公式サイトより文言を引用します。 Amazon Bedrock は、Amazon や主要な AI スタートアップ企業が提供する基盤モデル (FM) を API を通じて利用できるようにする完全マネージド型サービスです。そのため、さまざまな FM から選択して、ユースケースに最も適したモデルを見つけることができます。Amazon Bedrock のサーバーレスエクスペリエンスにより、すぐに FM

こんにちは。レシピ事業部のkaorun343です。我々のチームではレシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話 - クックパッド開発者ブログにて紹介したとおり、レシピサービスを Next.js ベースの新システムへと移行しています。今回は、この新システムのCSS in JSをEmotionからゼロランタイムのvanilla-extractへ変更した話です。 vanilla-extract.style 背景 以前書いた レシピサービスのフロントエンドに CSS in JS を採用した話 - クックパッド開発者ブログでは、CSS in JSライブラリとして Emotion（@emotion/react）を採用した経緯と開発環境整備を紹介しました。採用理由としては以下の通りでした。 セレクタに一意なIDが割り振られるので、スタイルを適用した要

こんにちは。レシピ事業部の新井（@SpicyCoffee）です。 クックパッドではこれまで、レシピを投稿してから検索結果に反映されるまで最長で 24 時間程度の時間がかかっていました。今回、この時間を 5 分程度、最長でも 10 分程度に短縮することに成功しました。本記事では、プロジェクトオーナーの立場で関わった私が代表してその開発について紹介します。 プロジェクトの目的と数値目標 本プロジェクトでは上記の「レシピを投稿してから検索結果に反映されるまでの時間短縮」が目的とされました。しかし、時間短縮といっても現状 24 時間であるものを "1 時間" にするのか、"1 分" にするのか、"1 秒" にするのかでは話が全然違います。この数値目標は設計を始めとした後の意思決定に大きく影響を与えるため、しっかりとした意図を持った状態で明確に定めておく必要がありました。 そこで、私とプロダクトオー

こんにちは、技術部の石川です。 ある日、社内の各種アプリケーションを眺めている中で、とあるクローズしたサービスの管理画面を担っていたウェブアプリが今も動いていると気付きました。簡単にヒアリングしたところ、サービス自体はクローズしたものの、保有していたデータが次のチャレンジに生かせるため管理画面だけ残しているとのことでした。 一方で、その管理画面へのアクセスはそう多くありませんでした。毎日ちょっとだけのリクエストを処理するためだけにデータベースとサーバーが動いており、少し無駄がある状態になっていました。 やや気になったので検討した結果、最終的にこの管理画面アプリを Next.js 製の静的なデータビューワーサイトとしてリニューアルし、社内向けの GitHub Pages として提供されている状態にできました。この記事ではその顛末をご紹介します。 技術選定 いくつか事前調査をした結果、今回の管

こんにちは、モバイル基盤のヴァンサン(@vincentisambart)です。 半年くらい前に、iOSクックパッドアプリで画像非同期取得を自作することになりました。導入してから何ヶ月も問題なく動いているので、どう動いているのか紹介しようと思います。でもその前に自作することになった経緯を説明しましょう。 自作経緯 長年画像非同期取得に既存のライブラリを使っていましたが、昨年ライブラリの不具合で画像の取得が稀に失敗していたバグがいくつかありました。バグが修正されて、その数ヶ月後にまた似た問題。 この状態が好ましくなかったので、以下の選択肢のどれかにしようと議論しました。 使っているライブラリのメンテナンスにもっと直接参加する コードが古くメンテナンスしやすくなさそうでした。 使っているライブラリのバージョンを固定する 自動的に更新をやめても、バグ修正や最新のOSの対応のために定期的に更新した方

id:sora_h です。最近は RubyKaigi の Organizer や Wi-Fi NOC をやっていましたが… 何屋なんだろう? 一応 Software Engineer (Site Reliability, Corporate Engineering) を名乗っていますが…。あっ RubyKaigi から戻ってからは学者をやってますね。落ち着いたら本業を思い出していこうと思います。 さて、Cookpad は 2010 年より RubyKaigi に協賛していますが、近年は Wi-Fi Sponsor など*1として携わっています。実体的には、 id:sora_h (筆者) が RubyKaigi 前にほぼフルタイムで Wi-Fi の準備に提供されたり、細々とした機材、一部の回線・ラックスペースの提供を行っています *2。 本稿では RubyKaigi 2023 Wi-Fi ネ

エンジニアの成田（@mirakui）です。最近はクックパッドマートの流通基盤エンジニアとして、商品の流通に関わるソフトウェアやハードウェアに携わっています。 さて、クックパッドは先日長野県の松本で開催された RubyKaigi 2023 にスポンサーとして参加しました。そのスポンサーシップの一環として、参加者に配られるドリンクを冷やすための冷蔵庫を提供しました。 会場に設置した6台の冷蔵庫は、私たちが「マートステーション」と呼ぶ、クックパッドマートにおいてユーザーが購入した商品を受け取るための冷蔵庫です。現在は都内を中心に、駅やコンビニエンスストア、マンションの共用部といった生活動線に設置しています。マートステーションの技術的な詳細は下記の記事をご覧下さい。 techlife.cookpad.com 今回設置したのは、上記の記事中で "JCM-Mk4" と呼んでいる、現行型である第4世代の

こんにちは、メディアプロダクト開発部のマーケティングサービス開発グループ(通称msdev)の id:asonas です。msdevウィーク最後の記事です。チームメンバーの記事も是非読んでみてください。 クックパッドの toB 向け事業における ChatGPT API の活用事例紹介 - クックパッド開発者ブログ ポリモーフィック関連を活用し、森羅万象の「いいね」を実現する手法 - クックパッド開発者ブログ マーケティングサービス開発グループでは毎週月曜日13時から17時の決まった時間にモブプログラミングを実践しています。 このモブプログラミングの枠は1年以上継続していて、毎週様々な課題の解決や機能の開発をしています。この記事ではモブプログラミングを長く継続するためのコツをお伝えします。 モブプログラミングとは まず、モブプログラミングとは、チームメンバーが同時にコーディングを行う手法です。

レシピサービス開発部の新井（@SpicyCoffee66）です。いろんなゲームが好きなのでどれも中途半端にしか上手くならないことに 10 年以上悩んでいます。 この記事では、クックパッドのレシピサービス開発に導入している "オーナーエンジニア" と呼ばれる制度について紹介します。 クックパッドでサービス開発をしているエンジニアがどういう働き方をしているのか知りたい ディレクターやデザイナーと上手く協業する方法が知りたい サービス開発エンジニアはやることが多すぎてどうやって仕事をすればいいか悩んでいる といったような方の参考になると思いますので、興味があれば是非ご一読ください。 制度導入の背景 オーナーエンジニアという役割について述べる前に、まずはレシピサービスの開発を取り巻く環境について軽く解説します。 現在クックパッドのレシピサービスは、エンジニアが 10 名と少し、デザイナーが 5 名

技術部の笹田です。Ruby 3.2 無事にリリースされて良かったよかった。 Rubyインタプリタは複雑なプログラムなので、当然のごとくバグが入ってきます。Rubyインタプリタ開発者は、これに対していろんな対策をしています。たとえば、テストを書いて、CI環境でチェックするとか、今となっては当然のことを、当然のごとくやっています（RubyCIやchkbuild、ruby/spec: The Ruby Spec Suite aka ruby/specなどの整備や、実行環境の日々のメンテナンスの成果です）。 これに追加して、個人的にテストをとにかくたくさん繰り返し行うマシン群を用意しています。テストの実行頻度をなるべくあげて、「時々しか発生しない」というバグを炙り出して、Rubyインタプリタの品質向上を目指すためです。本稿ではそんな、ちょっとだけ変わったテスト環境についての話をご紹介します。 この

9月からRuby開発チームにインターンシップとして参加している@makenowjustです。 総合研究大学院大学の学生で、普段は情報セキュリティに関する研究をしています。 インターンシップでは、キャッシュ (メモ化) を利用したRubyの正規表現の高速化を行いました。 ReDoSと呼ばれる、バックトラックが爆発することでマッチング時間が膨大になる脆弱性があります (ReDoSについては、拙作ですがWEB+DB PRESSに掲載された記事があります)。 近年、ReDoSは多く報告されており、Rubyもその例外ではありません (参考1、参考2)。 今回実装した最適化は、ReDoSを防ぐことを目的としたもので、多くの正規表現のマッチング時間が文字列の長さに対して線形となります。 ReDoSが起こる正規表現の例として、/^(a|a)*$/が挙げられます。 今回の修正の前後での実行時間を比較すると、

CTO の成田（@mirakui）です。 クックパッドはいま、2017年からの10年間を投資フェーズとして位置づけていて、ミッションである「毎日の料理を楽しみにする」を実現するため、長期的に成長していけるための事業づくり、組織づくりに投資をしています。 クックパッドは価値のあるプロダクトをユーザに届け続けることが事業の中心にあり、そのためにはエンジニアの活躍が不可欠です。クックパッドにおけるエンジニアというのは、単なる「実装担当」ではなく、自発的に課題を発見し、一人ひとりの専門性や創意工夫をもって開発をしていくことが求められます。強い個人が集まって、それぞれの能力のうちの高い部分をお互いに引き立て合って、一人ひとりでは解決できないような大きな課題に取り組めるようになる。私は CTO として、クックパッドのエンジニア組織をそのように強化していきたいと考えてきました。 エンジニアリングにおいて

こんにちは。レシピサービス開発部のkaorun343です。クックパッドではスマートフォン向けページにおける開発者体験向上のために、レシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話にて紹介したとおり、Next.jsとGraphQLを用いたモダンな環境へと移行を進めています。例えばモバイル端末からのアクセスでURLがトップページの / であれば Rails、レシピ詳細ページの /recipe/:id であれば Next.js アプリにルーティングされるようになっています。現在ではレシピ詳細ページだけではなく検索結果ページやつくれぽ詳細ページ、MYフォルダページなどもNext.jsアプリケーションに置き換わっています。今回はその移行により生じた課題と取り組み方、それから併せて実施したモノレポ環境整備について紹介します。 共通コンポーネントの導入背

技術部 SRE グループの @s4ichi です。ここ最近は本業に加えて Overwatch2 のヒーローとして戦いに明け暮れています。救わなければならないレートがある。 GitHub flow に従った開発では GitHub Actions が非常に便利です。特に最近では CI 用途だけでなく、ソフトウェアのデリバリーなども Actions で完結させる事例も見かけます。しかしながら、クックパッド社内では GitHub Enterprise Server を使っているため、GtiHub Actions の利用には self-hosted runnner の利用が不可欠になっています。 そこで、社内では Amazon ECS 上に ephemeral で汎用的な self-hosted runner を提供しています。実行する job の数に応じた autoscaling を備え、runn