コーポレートエンジニアリング部の id:sora_h です *1。今回は 3 ヵ月ほど前に実施した、Google Workspace テナントのプライマリドメイン変更について、記録を兼ねて説明します。 クックパッドは 2009 年頃 *2 より Google Workspace *3 を利用しています。当社の対外的なメールアドレスは cookpad.com ですが、Google ではプライマリドメインとして cookpad.jp が設定されています。各ユーザーには cookpad.com のアドレスを別名 (エイリアス) として登録されていて、メールアドレスとしては cookpad.com を利用、ただ Google へログインする時だけ cookpad.jp を利用する運用になっていました。想像が出来ると思いますが、これが様々な面で不便・混乱を発生させていました。どうしてこうなった… *

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 ネ

インフラストラクチャー部の青木峰郎です。 最近はDWH運用の傍ら、所属とまったく関係のないサービス開発のためのデザインスプリントをしつつ、 Java 10でgRPCサーバーを書きつつ、 リアクティブプログラミングを使った非同期オーケストレーション層を勢いだけで導入したりしています。 ですが今日はそれとはあまり関係なく、クックパッドの中核サービスであるレシピサービスの アーキテクチャ改善プロジェクト、「お台場プロジェクト」の戦略について話します。 これまで、お台場プロジェクトで行った施策について対外的に発表したことはあっても、 全体戦略について話したことはありませんでした。 その一番の理由は、正直に言って、プロジェクトオーナーであるわたしにもプロジェクト全体の姿が見えていなかったからです。 しかし現在プロジェクト開始から1年半が経過してようやく全貌が見えてきたので、すべてをお話ししようと思い

技術部開発基盤グループのシム(@shia)です。 最近は cookpad のメインレポジトリを開発しやすい環境に改善するために様々な試みをしています。 この記事ではその試みの一つとして不要な gem を検出し、削除した方法を紹介したいと思います。 背景 cookpad は10年以上にわたって運用されている巨大なウェブアプリケーションです。 巨大かつ古いアプリケーションには昔は使っていたが、現在は使われてない依存性などが技術負債として溜まっています。 事業的観点から技術的負債を完全返却するのはコストとのバランスが悪いことも多いです。 これは20万行を超えるプロジェクトを幾つも抱えている cookpad のメインレポジトリも例外ではなく、その規模から使ってないと思われる依存性を探しだすのも大変な状況でした。 どうするか 人が頑張るより機械に頑張らせたほうが楽ができるし、何より確実です。 ですの

こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、

こんにちは。サービス開発部の丸山@h13i32maruです。 今日はGitHub/GHE(GitHub Enterprise)で快適なIssue生活をおくるために作ったJasperというツールと、それを実際にどうやって使っているかを紹介させていただきます。 ストレス GitHub/GHEを日々の業務の中心として使っていると、すごくたくさんのIssueやPull Request(以下PR)が流れてきます。 これらのIssueを処理する方法としては主に「メール」と「通知ページ(github.com/notifications)」の2つだと思います。 僕もこれらの方法を使っていたのですが、以下の点ですごく困っていました。 多すぎてメンションされたものやコメントしたものを見逃してしまう あとで見ようと思って、忘れる ブラウザのタブを大量に開いた状態になる 知らないところのIssueで議論が進んでい

こんにちは、みんなのウェディングに出向中の小室 (id:hogelog) です。 今回はクックパッドとみんなのウェディングで利用しているデータベースドキュメント管理システム dmemo を紹介します。 https://github.com/hogelog/dmemo dmemo を作成し導入した経緯 私は2016年3月頃からみんなのウェディングで Redshift, bricolage, embulk, re:dash 等を利用したデータ分析基盤の構築を進めています。 (みんなのウェディングのデータ分析基盤の現状 - みんなのウェディングエンジニアリングブログ) 社内の誰でも扱えるデータベース、データの集約・計算・加工、ダッシュボードの作成、クエリの共有などは上記ブログ記事でも書いたように Redshift, bricolage, embulk, re:dash 等を組み合わせることで実現

インフラ部の荒井（@ryot_a_rai）です。 今年の4月、弊社には11名の新卒エンジニアが入社しました。そして現在、3ヶ月間の研修を受けています。ビジネスマナーから技術研修まで幅広く行われていますが、その中で5月下旬におこなったインフラ研修とその後の社内ISUCONについてご紹介します。 インフラ研修（講義） インフラ研修はインフラ部に配属されるエンジニアに限らず、全新卒エンジニアが参加する研修です。日常業務でコードを書いてサービスを開発していくうえで知っておいてほしい、インフラに関する基礎知識や共通言語を獲得することを目的としています。合計3日間をインフラ部の@kani_bと分担して講義しました。研修内容の内容はざっくりと以下のようなものです。 1日目 インターネットとは ブラウザでウェブサイトを閲覧する際になにが起きているのか IPからHTTPまでざっくりと Webインフラアーキテ

インフラストラクチャー部の宮下（@gosukenator）です。 クックパッドでは一部のサーバで Ubuntu を使い始めており、 apt リポジトリをどのように管理するのが良いのか、試行錯誤しています。aptリポジトリ管理で実現したいことは、主に次の2点です。 自前でビルドしたパッケージの管理 リモートリポジトリから削除された旧バージョンパッケージの保全 このあたりをいい感じにできるツールはないかな、と社内で話していたところ、カルビ生焼け王 に教えてもらったのが aptly です。 aptly とは 公式サイトに「aptly is a swiss army knife for Debian repository management」とあるように、aptly は多機能な apt リポジトリ管理用ツールです。外部リポジトリのミラー作成、ローカルリポジトリの作成、リポジトリのスナップショット

id:sora_h です。今回はクックパッドの社内 apt リポジトリ管理・deb パッケージビルド・リリースフローについて紹介します。 クックパッドではいままで CentOS 6 を利用していましたが、最近は Ubuntu への移行を進めています。現在は CentOS / Ubuntu 両方が共存したインフラになっています。 CentOS では社内に yum リポジトリを置き、本家リポジトリから消えてしまったパッケージや、独自でビルドしたパッケージのホストを行っていました。Ubuntu 導入以降も同様に、社内 apt リポジトリを設置し、必要があれば独自でパッケージをビルドすることにしました。具体的には、わたしは ruby2.1 パッケージや ruby2.2 パッケージをメンテナンスしています。 (なお、わたしは rpmspec および ebuild の方が慣れていて、未だ deb パッ

投稿推進部の外村（@hokaccha）です。 クックパッドブログの開発でRails上にECMAScript6などのモダンなJavaScript開発環境を導入した経験を元にノウハウを紹介したいと思います。 RailsはSprocketsというgemでJavaScriptやCSSをコンパイルする仕組みが提供されています。Sprocketsによるasset管理の仕組みは非常によくできており、AltJSのトランスパイルやファイルの結合、minifyなど、assetのコンパイルに必要な機能を一通り備えています。 しかし、JavaScriptにおけるモジュールの依存関係の解決や、ライブラリの管理などについてはモダンなJavaScript開発と乖離してきているのが現状です。そこで、Railsでも以下のようなことを実現できることを目標に環境を作りました。 ECMAScript6のシンタックスを使う モジュ

会員事業部の有賀(id:chezou)です。 今年一年、社内では勝手に"Jupyterの伝道師"を標榜してJupyter notebookの普及活動を展開してきました。 先日、社内でハンズオンも行ったおかげもあり、かなり社内のマシンにPython環境が構築されてきました :) Jupyter notebookとは？ ひとことで言うとブラウザで動くすごい便利なREPL*1です。 百聞は一見にしかず、見てみましょう。 このように、Rubyの対話環境であるpryを触っているようにインタラクティブにコードを書くことができます。 以降で説明をしますが、Jupyter notebookは記録・共有・再現がとても得意です。特に図表があるときにその効果を発揮します。 Jupyter notebookの良い所 過去のコードを改変、再実行できる セルと呼ばれる入力部分にはMarkdownやコードが記述できます

こんにちは！クックパッド編集室メディア開発グループ長の @yoshiori です。 たまにネットやイベントなどで「たかがレシピサイトになんでこんな技術力が必要なのか」と言われることがあるので今日はそれに真正面から答えてみようと思います。 例えばどういうところで技術使ってるか 他の人の話はこのブログの他のエントリを見てもらえればわかると思うので、僕の所属しているクックパッド編集室での取り組みの中から今回は料理動画を例に説明します。 Adaptive bitrate streaming での配信 クックパッドで配信している動画は基本的に「料理動画を支える技術」でも触れられている配信プラットフォームを利用しています。 ここでは裏で動画を「低画質」「普通」「高画質」の 3 パターンでエンコードして、回線状況に応じて最適な画質の動画を HTTP Live Streaming (HLS) で配信してい

クックパッドの広告エンジニアは何をやっているのか こんにちは、新規広告開発部の武田(@cnosuke)です。 私は、今年の7月より新規広告開発部に配属されました。 例えば花金などに、社外のWebエンジニアの人達とお酒を飲みに行ったり、ひさしぶりに大学時代の友人にあったりして 「最近はクックパッドの広告を担当している」というと、みんな「あぁアドテクね。ふ〜ん」みたいなリアクションをします。 興味があるのか無いのかわかりませんね。そんな時は、だいたい「あぁそうそう、アドテクアドテク〜」と返します。 確かに、私が所属している新規広告開発部は、いわゆる「アドテク」と呼ばれる領域のことは行ってはいますが、 そもそも「アドテク」という用語が完全にバズワード化していますので、具体的に「クックパッドの広告エンジニア」が何をやっているかをほとんどの方はご存じないのではないでしょうか。 そこで、今回はクックパ

こんにちは。ユーザーファースト推進室ディレクターの大黒です。 私が所属しているユーザーファースト推進室では、「クックパッドに訪れた全てのユーザーが、期待する以上の品質に常に触れている状態にする」というミッションを持っています。今回はその中の取り組みの一つである「気になる！報告」という仕組みをご紹介します。 「 気になる！報告」とは スタッフが普段、何気なくクックパッドを使っている中で、気になったことを簡単に報告することができる仕組みです。休日や外出先などでは、気になったことを後で担当部署にフィードバックしようと思っていても、ついつい忘れてしまいます。そこでサイト内に「気になる！報告」のリンクを設置し、いつでもどこでも報告できるようにしています。 スタッフアカウント*1でログインすると、クックパッドのフッターエリアにスタッフにしか見えないリンクがあり、どのページにいてもすぐに報告をすることが

こんにちは、検索・編成部の五味と申します。 現在はディレクターとして、クックパッドiOS／Androidアプリを使いやすくするための施策を主に担当していますが、年初に異動して来るまでは、広告クリエイティブ制作というまったく異なる仕事をしていました。 サービス開発に関しては初心者状態だった私にとって、貴重な学習機会を与えてくれている、クックパッドのディレクター同士の情報共有の仕組みをご紹介します。 ディレクター同士の連携は難しい？ まずはじめに、現在クックパッドでは事業部制が採用されており、ディレクターは複数の部署に数名ずつ分かれて働いています。 ところが、ディレクターは同職間での連携が難しい職種でもあります。通常1つの施策を複数名で担当することはないので、お互いの業務進捗を報告しあってもいまひとつ理解しきれませんし、担当する施策の内容もバラバラであることが多いため、業務フローに問題があって

インフラストラクチャー部の成田です。2015年10月現在、インフラストラクチャー部には私を含め7人のインフラエンジニアが所属しており、このメンバーでクックパッド本体サービスをはじめ様々な新規事業やいくつかの子会社のサーバを運用しています。私自身もエンジニアではありますが部のマネージャも兼ねているため、立場上、社外の方からインフラエンジニアのマネジメントについて質問されることがよくあります。今回は、私自身の考え方とクックパッド社における事例を紹介したいと思います。 「インフラエンジニア」とは 「インフラエンジニア」という言葉の定義はあいまいで、しばしば議論の的になります。傍目からは明らかにインフラエンジニアであるように見えるにも関わらず「私はインフラエンジニアでは無い」と主張する人たちもいます。このような状況になっているのは、サーバ運用に関する業務分掌が会社ごとに異なるからであると私は考えて

新規広告開発部の大野です。今回は、「目標を達成するための施策を数字で考える」ということについて、普段やっていることを書きます。 施策の評価に関しては Rを使う などいろいろなノウハウがありますし、Web上の行動改善などはそれはそれで、世にノウハウがたくさんあります 。 今回は、例えば、期初に事業目標を決めた次のステップとして、全体の優先度を決めるあたりの段階の話をしましょう。 分解： 数字から取り組む施策を決める まず、どの施策をするかを決めるわけですが、必ず、最初に目標を因数分解しています。 広告なら「収益 = 単価 × 在庫 × 販売率」といういつもの式があるので、これが元です。例えば 単価がCPCなら在庫はクリック回数。つまり、imp（表示回数） × CTR 単価が表示なら、在庫は単純に imp となります。で、販売方法によって、どの項をあげるのが有効か、つまり、現実的に伸びるか、ど

目次 はじめに 技術選択の基本的な方針 技術選択の各論 HTTP Client Dependency Injection View Injection Asynchronous Control Flow Object Relation Mapper Logging Fragment はじめに 技術部の id:gfx です。 Android版クックパッドアプリのリニューアル*1 から約1年たちました。現在はリリースごとに5人程度がコミットし、2週間に1度リリースを行う開発体制となっています。プログラミング言語はJavaで、コメントも含めたアプリのソースコードの行数は約15万行です。 本エントリでは、Android版クックパッドアプリで使っている技術、具体的にはライブラリやフレームワークについて紹介します。また、そのための技術選択のアプローチについても概説します。 技術選択の基本的な方針 まず