こんにちは投稿開発部の丸山@h13i32maruです。 今日から5日間、本ブログに投稿開発部メンバーで連載記事を書かせていただきます！ いきなり「投稿開発部で連載記事」と言われても何のことかわからないと思うので、まず投稿開発部について簡単に紹介させてもらいます。 投稿開発部は「クックパッドに投稿されるコンテンツ全般」について責任をもっている部署なのですが、中でもレシピ事業の根幹であるレシピ投稿者向けのサービス改善に力を入れています。レシピ投稿者向けのサービス改善は「どうすれば継続的に投稿したくなるのか？」「どうすれば投稿をはじめてみたくなるのか？」の2点に答えを出すことを目標に日々サービス開発に励んでいます。 そこで、本連載では投稿開発部が今年メインで取り組んでいる「クックパッド MYキッチン」という新しいアプリについて5人のメンバーで紹介させていただきます。 1日目(vol1)では「クッ

研究開発部の画像解析担当のレシェックです。techlife を書くのは初めてです。よろしくお願いいたします。 最先端の機械学習を使うためには、常に自分のスキルアップが必要です。そのために、毎日論文を読んだり、新しいオープンソースのコードを試してみたり、クックパッドのデータで実験しています。これはちょっと料理の練習と似ています。新しいモデルを学習させるのは料理をオーブンに入れるのと同じ気持ちです。オーブンの温度は学習率と同じで、低すぎだとよく焼けず、高すぎだと焦げてしまいます。しかし、ちゃんと他のリサーチャーの論文やブログの中のレシピを見ながら自分のデータでモデルを学習させると、失敗せずに済むかもしれません。 このエントリでは、そういった機械学習のレシピの一例を紹介します。 このブログで使っているテスト画像はPixabayから取得した、Creative Commonsのライセンスの写真です。

会員事業部エンジニアの新井( @SpicyCoffee66 )です。 Splatoon2 で各ルール S+1 以上になるため日々奮闘中のところに MHW が発売されました。 加えて最近ぷよぷよを始めたので、どう考えてもいろいろ計算が合わなくなってきました。 本日おこなわれた Cookpad TechConf 2018 では「クックパッドの "体系的" サービス開発」と題し、社内でどのような点に気をつけて開発サイクルが回されているかをお話しさせていただきました。 動画・発表資料は後日アップロードされる予定ですので、よろしければ合わせてご覧ください*1。 今回は、TechConf 2018 での発表内容から、BML ループの運用について、多少の補足や要約を交えながら書きたいと思います。 サービス開発は難しい まず前提として、サービス開発は難しいです。 その難しさの大部分は、以下の２つの要因から

研究開発部の原島です。部のマネージメントのかたわら、自然言語処理関連の開発に従事しています。本エントリでは、最近社内で開発した自然言語処理システムを紹介します。 ■ 「しょうゆ」のバリエーションは 100 種類以上 クックパッドで以前から解決したかった課題の一つに材料の名前（以下、材料名）の正規化があります。 クックパッドのレシピは複数の材料から構成され、各材料は名前と分量から構成されています。例えば、上のレシピの一つ目の材料は「豚薄切り肉」が名前で、「200g」が分量です。 さて、この材料名はこのレシピでは「豚薄切り肉」という表現でした。しかし、他のレシピでは「豚うす切り肉」という表現かもしれません。「豚うすぎり肉」や「ぶた薄切り肉」、「豚薄ぎり肉」等の表現もありえますね。 これは異表記同義（いわゆる表記揺れ）の問題ですが、同様の問題は他にも沢山あります。例えば、以下のようなものです。

こんにちは、サービス開発部の荒引 (@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で議論が進んでい

SQL、書いてますか？ こと大規模データ処理の分野においてはSQLはもはや標準インターフェイスであり、 分析やらバッチやらに関わっている皆様は日々大量のSQLクエリーを生産していることと思います。 そこでちょっと気になるのが、 SQLのコーディングスタイルってどうするのが一般的なんだっけ……？ という点です。 イマドキはSQLなんてO/R mapperに吐かせることが多いからなのか、 それともコードを広い範囲で共有することがそもそもないからか、 SQLのコーディングスタイルについて見聞きすることは他のプログラミング言語に比べるとだいぶ少なく、 いまいち決定版と言えるスタイルがないなと感じています。 そんなわけで本日は、SQLのコーディングスタイルについての意識を活発化させるべく、 クックパッドでわたし（青木）が使っているコーディングスタイルから特徴的な点を紹介したいと思います。 特に、分析

検索事業部の須藤です。 クックパッドの検索周りのサービス開発を担当しています。 はじめに 最近ではプロトタイピングツールも充実し、コードを書かなくとも動的なモックアップが作れるようになるなど、思いついたアイデアをより早く、より最終的なアウトプットに近い形でメンバーに共有することができるようになったと感じています。 また、実際にコードを書いてユーザーに公開するための効率的な手法や、公開後の検証方法についても様々なツールや知見が共有されており、より精度の高い定量評価ができるようにもなってきたかと思います。 一方、これらの効率化が進んでも、実際に打った施策の数を増やせたか、最終的にサービスインできたプロダクトの数が増えたかというと、そこまで実感がありません。 その理由のひとつは、思いついたアイデアを具体化して作り始めるまでの初期段階と、実際にそのプロダクトを（テスト目的であっても）公開に耐えうる

会員事業部の有賀(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) で配信してい