いつもお世話になっております。エンジニア統括マネージャーの高井です。 クックパッドでは毎年恒例となりつつある、クックパッドのサマーインターンシップのうち「17day 技術インターンシップ」を開催しました。インターンに来てくれた学生のみなさんは本当に優秀で、毎日真剣に取り組んでくれました。本当に感謝しています！ インターンは、前半の「サービス開発講義・課題」パートと後半の「サービス開発実践」から構成されています。前半パートでの講義について資料を公開いたしますので、みなさまぜひご覧ください。 【1日目】サービス開発 初日は、クックパッドで実践されているサービス開発の手法について学ぶワークショップです。グループでのユーザーインタビューを通じてサービスの設計をしました。 【2日目】Rails・TDD・Git 昨年に引き続き、講義初日はGit、TDD、Railsを1日で一巡りするという、忙しい構成で

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

こんにちは、株式会社ビットジャーニーに出向中の出口 (@dex1t) です。ビットジャーニーでは、社内情報共有ツール Kibela*1のサービス設計やプロダクトマネジメントに責任を持ちつつ、エンジニアとして開発全般に携わっています。 今回は、新サービスの立ち上げ時にどのような考えで重要指標*2を設計し、それを実際の開発のなかでどう使っていくかという話をします。 なぜ検証をするのか そもそもなぜ新サービス立ち上げ時に、重要指標や検証といった考えが必要になるのでしょうか。それを考えるにあたって、クックパッド的なサービス開発の流れを改めて整理してみます。 企画と検証は表裏一体 サービス開発といえば、企画・開発・検証をぐるぐる回すというのが一般的だと思います。指標は検証段階で活用する道具です。企画で考えたことを確かめるのが検証段階であり、企画と検証は表裏一体です。 したがって、指標の設計をするにあ

こんにちは、投稿開発部の森川 (@morishin127) です。クックパッド、お料理アルバム、みんなのお弁当の iOS アプリの開発等に携わっています。 クックパッドでの開発は GitHub Enterprise 上で行われており、書いたコードをプロダクトに取り込む前には基本的に第三者のコードレビューが必須です。コードレビューはプロダクトの品質向上に貢献していますが、往々にして結構な時間と労力がかかるものです。Pull-Request を出してレビューをしてもらい指摘の修正を繰り返していると、場合によってはマージに数日〜1週間ほどかかってしまうこともあります。自分の開発速度を速めるため、また周りのエンジニアの開発速度を下げないためにレビューしやすい Pull-Request を出すことは重要です。この記事ではレビューしやすい Pull-Request のために心がけていることを紹介したい

こんにちは。技術部 開発基盤グループの諸橋です。 クックパッドでは昨今の多くのWeb企業と同じように、GitHub EnterpriseのPull Requestを使ったコードレビューを広範に実施しています。わたしたちのコードレビューでは、ソースコードの字面にとどまらず、サービスの機能として魅力的かどうかや、保守性を含めた設計が適切かといった議論に発展することも良くあります。 きょうはそんななかで話題に上がった「現在時刻」の扱いかたに関する設計の話を書きます。 背景 サービスを開発・運営している我々には、時間帯によって出し分けたり、特定の期間のみに表示したいコンテンツがたくさんあります。 そのたびにデプロイし直すというのはつらいので(特に24:00に出なくなるコンテンツなど)なんとかしたくなりますが、一方で時限式のコンテンツはその時になるまでちゃんと動いているか確証が取れないので怖いです。

こんにちは。技術部の吉川です。 最近ではMicroservicesという言葉もかなり浸透し、そのテクニックも体系化されつつあります。 一方でMicroservicesについての話は概論や抽象的な話が多く、具体像が見えないという方もいらっしゃるのではないでしょうか。 当ブログでは1年半ほど前にMicroservicesへのとりくみについてご紹介しました。 当時社内ライブラリだったGarageはその後オープンソースとして公開され、また社内のシステムも当時と比べ飛躍的な進化を遂げています。 そういったクックパッドにおける最近のMicroservices事例を先日Microservices Casual Talksで紹介しました。 Microservicesの抽象的な話は一切割愛し、具体的な事例に終始した内容となっています。 Microservicesの基本となる考え方はわかったものの、実践方法で

技術部の松尾(@Kazu_cocoa)です。 最近、 @moroや私を中心に、テストから開発を駆動するという方向で、とある活動を始めました。その活動の中では、 @t_wadaさん を 技術顧問 として巻き込んで活動を進めています。そんな取り組みを少しここにまとめます。 取り組みの前段階 先日、私はテストエンジニアというロールに焦点を当ててテストという言葉に対する2種類の話をいたしました。TDDのようにテストによって開発を駆動していく側面の話と、人の認知・感じ方に寄った仕様自体含めてテストしていく側面の話です。 クックパッドエンジニアトークナイト 〜クックパッドテストエンジニアのあり方〜 を開催しました！ クックパッドエンジニアトークナイト 〜クックパッドテストエンジニアvol.2 Testing編〜 を開催しました！ その際、会の傍でt_wadaさんらと私たちが開発するWebアプリケーショ

技術部の taiki45 です。 現在のクックパッドでは、cookpad.com 内のデータを利用するようなプロダクトでも、cookpad.com を提供しているアプリケーション(本体アプリケーション)とは別に新規のアプリケーションとして設計・実装しています。また、すでに本体アプリケーションの一部として実装されているプロダクトについても、トレードオフを考慮しながら場合によっては、本体アプリケーションから独立した別のアプリケーションとして設計・実装することが増えてきています。これらの本体アプリケーションや、新規にあるいは本体アプリケーションから独立させて設計・実装したアプリケーションのことを「サービス」と呼んでいます。また、この本体アプリケーションから独立させることを「サービス分割」と呼んでいます。 制御できないほどの巨大な複雑なまとまりを制御するために、その巨大なまとまりと単純なまとまりに

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

こんにちは、トレンド調査ラボの井上寛之（@inohiro）です。 クックパッドの検索ログを基にした法人向けデータサービス「たべみる」の開発を担当しています。 本稿では、現在開発を行っているスマートフォン向けウェブアプリケーション（Rails）で採用した、 JavaScriptチャートライブラリを選定するにあたって検討した観点について述べます。 また、実際に採用したライブラリと、その利用例を簡単に紹介します。 ウェブ上に無数にあるJavaScriptチャートライブラリから、最適なものを一つ選択するのは なかなか難しい作業ではないかと考えています。おそらく、これから記述する条件を満たすライブラリは数多く存在し、 今回私が選択したライブラリ以上に良いものがあるのではないかと思います。 「何を以って良いライブラリとするか」という議論もまた難しい話題です。 そのようなライブラリについては、はてブコメ

はじめに こんにちは、技術部の土谷です。 現在、私は2015年4月に総合職の新卒社員として入社したのですが、自ら希望してエンジニアに転向するために6ヶ月間の技術教育(トレーニング)を受けています。 この記事では、私が受けているトレーニングの内容に関してご紹介したいと思います。 なぜやっているのか トレーニングのゴールは「クックパッドで一人前のエンジニアとして働ける技術力を身につける」ことです。 クックパッドでは、ディレクターや営業職であってもサービスに関わるスタッフは全て最低限の技術的な知識を持っているべきと考えられています。 そのため総合職の新入社員研修にも、クックパッドで働く上で最低限の技術的な知識を持つために技術研修が組み込まれています。 ただ、私自身、総合職で内定をもらったものの、「自分でものづくりがしたい」「それも、手を動かして納得のいくものをつくりたい」という思いを持っていて、

こんにちは、特売サービスのうさぎ好きエンジニア、伊尾木です。 今回のエントリでは、特売情報サービス上で実施しているポジティブ・フィードバックを回す施策を紹介いたします。 お店へのポジティブなご意見をもらおう！ 特売情報サービス ( https://cookpad.com/bargains/ )とは、日本全国のスーパーやドラッグストアなど（クライアントと呼んでいます）が、クックパッド上でチラシを配信するサービスです（よく有料サービスだと誤解されますが、無料ですのでぜひ使ってみてください）。 スーパーなどのクライアントは、忙しい業務に加えてクックパッドにもチラシを投稿してくれており、特売情報サービスの品質は全国のクライアントのモチベーションによってなりたっているとも言えます。 そこで、クライアントのモチベーションを支援する施策として、一般ユーザからお店に対するポジティブなご意見を集められないか

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

技術部の鈴木 (@eagletmt) です。 先日、クックパッドで使われている Ruby のバージョンを 2.0.0 から 2.2 にアップグレードしました。 アップグレードは主に @sorah と私で進めました。 今回はアップグレードまでの過程やアップグレード当日の流れ、そして今のところ見られているアップグレードによる効果などについて紹介します。 アップグレードまでの準備 テストを通す Ruby 2.1 がリリースされたときから 2.1 にアップグレードできないか検証環境でテストを回していました。 しかし、当時はクックパッドの全テストを実行すると必ず途中で Ruby がクラッシュする現象に悩まされていました。 Ruby の GC のバグ、拡張ライブラリのバグを疑いながら色々やってみたものの結局解決できず、Ruby 2.2 がリリースされてからもこの状況は改善されませんでした。 しかしある

買物情報事業部の八木です。クックパッド特売情報のAndroid部分を担当しています。普段はクックパッドのAndroid版（以後、本体アプリとします）の開発プロセスの中で特売情報の機能を開発しています。 本エントリでは細かな技術的負債を解消する為に本体アプリの開発チームが行っている朝Lint活動を紹介します。 2年近く経つ本体アプリのコードベース 私が買物情報事業部に所属する前は本体アプリを1から書き直すチームで働いていました。書き直し始めたのは2013年10月からなのでそろそろ2年が経とうとしています。2年前に設計された本体アプリは現在ではおよそ17万行を越え、日々どんどん変更が加えられています。 それらの変更の中には残念ながら悪いコードが含まれている場合があります。テストしづらいコードやテストがないコード、レビューに対する場当たりな対応や緊急のbug fixのために追加された汚いコード、

会員事業部の森田です。 対象と内容 この記事は、クックパッドと同じような200～300名規模の組織で働く、「最近調整が多くてコードを書く時間がないなぁ」と思い始めた30代エンジニアを対象として、日々の調整の負担を減らすための「考え」と「行動」を整理し、まとめたものです。 組織における分業と調整 組織に所属する人たちは協力して組織目標の達成を目指します。みんなで同じことをしてもしょうがないので、必然的に役割を分担(分業)をします。分担した仕事はなんらかのタイミングで統合する必要があります。その統合が調整です。つまり分業と調整はセットです。じゃどういう分業があるのかといえばそれは組織構造によります。今回は私達が採用している事業部別組織下*1 での調整の話をします。 分業の種類 事業部別組織では垂直と水平の2つの分業が存在します。それぞれに少し毛色の違う調整が発生するわけですが、いくつかのことを

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

広告事業部の鈴木達矢です。コーディングをしてると変数やメソッド名の付け方に悩むことって多々ありますよね。逆にコードを読んでいると単語の選択がこれでいいのかなという時や、動詞の活用形が間違っていてよく意味がわからない、時に潔く日本語の変数名になっていることも見かけます。でもプログラミング言語の単語が英語をベースにしていますし、Railsを使っている場合は日本語が規約（Convention）に合わなかったりします(複数形が無いなど)。それから動詞の活用形が違っていると主語（動作の主体）が変わってしまい、意味が変わってしまいます。その結果コードの可読性が落ち混乱を招きやすくなります。 いくつかの基本的な法則だけおさえておけばコーディング中に可読性の高い単語の選択ができるようになります。今回はそれを目的に、英語の扱いに都度時間を費やしてしまうような方に向けていくつかの法則をご紹介します。*1 変数

CTO の舘野 (id:secondlife) です。丁度1年半ほど前に、クックパッドの CTO になり、自分が20代の時に憧れていたいわゆるハッカーとは違う道を歩んだという事もあり、ソフトウェアエンジニア*1のキャリアってどんな物があるんだろうと改めて考えた時期がありました。 しかしながら一人悶々と考えても、答えが見つかる物でも無かったので、私の先を行く方々の話を聞きたいんですよね、みたいな事を md2inao で有名な WEB+DB PRESS 編集長の稲尾さんとしていたところ、じゃあそれ連載記事でどうですか、とお話を貰ったので記事として連載させて頂きました*2。 その時、連絡させていただいたメールにはこんなことを書いていました。 背景としては、今やエンジニアは、サーバサイドは AWS/heroku 等 IaaS/PaaS の台頭、github を中心とした OSS フレームワーク・ラ