Markdown と GitHub で社内規程を便利に管理 - クックパッド開発者ブログ
VP of Technology の星 (@kani_b) です。技術基盤や研究開発領域などを担当しつつ、社内の色々なことを技術の力でいい感じにする仕事をしています。セキュリティや AWS の話が好きです。 さて、みなさんは、ご自身が勤務する会社の就業規則を読んだことはあるでしょうか。 エンジニアに限らず、会社の全スタッフが仕事をする上で関わってくるのが、就業規則や情報セキュリティドキュメントなど、会社のルールや規程を記す文書です。 特にセキュリティやインフラに携わるエンジニアは、その改訂も含め携わったことがある方もいるのではと思います。 よくある文書管理 こうした文書は、以下のように管理されていることが多いようです。 ベースドキュメントは Word 保存時は PDF で保存 版管理は Word の編集履歴 + PDF に保存する際のファイル名 編集は担当部門, 担当者のみが行う かつての
開発環境のデータをできるだけ本番に近づける - クックパッド開発者ブログ
こんにちは。技術部の吉川です。 今回はクックパッドの開発環境構成、特に開発用データベースの構成についてご紹介します。 開発環境の構成 クックパッドのシステム環境は以下のようなフェイズに分かれています。 ※ これはcookpad.comの構成で、サブシステムや個別のサービスはその規模や特性に応じて構成が異なります。 development 開発者が実際に開発を行う環境です。クックパッドでは仮想環境は用いず、手元のマシンでRailsアプリケーションを動かして開発を行っています。 データベースはローカルではなく、開発者全体で共通の開発用データベースに接続しています。 test 手元でテストを実行する場合は、ローカルマシンのデータベースを利用します。CI（rrrspec）などの場合も同様で、テスト実行サーバーのデータベースが利用されます。 staging stagingといえば準本番環境として、本
巨大なWEBアプリケーションに巨大な変更を取り入れるためにやったこと - クックパッド開発者ブログ
会員事業部ユーザー基盤チームエンジニアの井口(@iguchi1124)です。 ユーザー基盤チームでは、クックパッドのサービス開発者のあらゆる要望に答え続けられるような『柔軟でいい感じのユーザー基盤』を目指し、サービス開発者およびユーザーさんの課題と向き合いながら日々開発を進めています。 第一弾として、普段の開発の様子や一部のユーザーさんに向けてユーザー登録機能をリリースするまでの話も公開されていますので是非そちらもご覧いただければと思います。 今回は、上述の記事にも触れられているようにクックパッドでユーザーさんのアカウント登録や認証情報として電話番号を利用できるようになりましたので、そのためにやってきたことの一部をご紹介したいと思います。 一口に電話番号を利用出来るようになったと言うと簡単そうに聞こえますが実際にはそうでもありません。 クックパッドではこれまで連絡先情報あるいはアカウントの
サーバーレスなバックアップシステムを AWS SAM を用いてシュッと構築する - クックパッド開発者ブログ
こんにちは。昨晩のお夕飯は鮭のカレー風味ムニエル定食だったインフラ部 SRE グループの @mozamimy です。 鮭のカレームニエル定食 pic.twitter.com/G2c1ij2wpp— ᕱ⑅ᕱ もざみ (@mozamimy) February 6, 2018 今回は、SRE グループでの取り組みのひとつであるマルチクラウドバックアップを題材にして AWS SAM、CodePipeline (CodeBuild および CodeDeploy を含む) を用いたサーバーレスアプリケーションの構築、ビルドおよびデプロイについて書いていきたいと思います。また、1月に Lambda で Golang が利用可能になった こともあり、CodePipeline の進捗を Slack に投稿する Lambda function を Golang で作ってみたので、そちらもあわせて解説したいと思
ユーザー基盤を作り直しながらRailsでのサービス層に向き合う - クックパッド開発者ブログ
こんにちは。パートナーアライアンス部の諸橋 (@moro) です。 突然ですが、わたしはいまクックパッドの「ユーザー基盤」を再構築しようとしています。 一口に「ユーザー基盤の再構築」といっても、そのゴールが何を指すかは(わたし自身にとってもまだ)漠然としており、固定されたゴールは見いだせていません。しかし後述するように、いくつかの問題は明確な形を取っています。言い換えると、それら明確な問題と向き合いながら『柔軟でいい感じのユーザー基盤を目指す』というのがこの再構築プロジェクトの目的です。 その第一歩目として、ユーザー登録部分を現状のクックパッド本体とは別の小さなRailsアプリケーションとして実装を進め、つい先日、一部の限定された利用者の方に向けて公開することができました。 今後も様子を見ながら公開範囲を拡大していく予定です。 再構築の背景 ではその「明確な問題」とはなんでしょうか。 最大
非SPAなサービスにReactを導入する - クックパッド開発者ブログ
投稿開発部の外村（@hokaccha）です。今回はReactについてのお話です。 ReactとSPA 最近JavaScriptやそれを取り巻くフレームワークなどの話題では、サーバ側はAPIのみを提供し、View(HTML)は全てJavaScriptで描画するような、いわゆるシングルページアプリケーション（以下SPA）についてよく語られます。 一方で、SPAを構築するにはコストがかかることも事実で、特にフロントエンドエンジニアが多くない環境では、従来通りサーバーサイドでViewを書きつつ動的な部分だけJavaScriptで処理するというアーキテクチャのほうが現実的な場合も往々にしてあります。 今回はこのような、サーバー側でHTMLを生成し、一部の動的な部分だけをReactで書くためのTipsを紹介します。 なお、基本的にサーバーサイドはRails前提ですが、RailsにおけるReactの開発
ディレクターがSQLを使えてよかった話 - クックパッド開発者ブログ
こんにちは。ディレクターの川原田です。 クックパッドでお気に入りレシピを保存する「MYフォルダ」のサービス開発や、保存・記録に関する新規サービスの検討・開発を担当しています。 ディレクターの仕事は様々ありますが、今回は私が身につけたことで仕事領域が広がった！と感じているSQLについてお話ししたいと思います。 いきなりですが、SQLが使えてよかった点をまとめると以下です。 よかったこと 数値抽出から分析まで自己完結 エンジニアとのコミュニケーションがスムーズに 仕事が増えていそうで実は効率アップ 周囲の知的好奇心を刺激 それぞれ具体例を交えてお話します。 数値抽出から分析まで自己完結 事例１：ログ構造を理解でき後の仕事がスムーズに 昨年、アプリのサービス開発を担当した際、エンジニアの設定したログが、実際に送信されるかどうかを事前チェックをしました*1。 アプリのリリースはタイミングが決められ
安心してRailsアップグレードを行うための工夫 - クックパッド開発者ブログ
こんにちは。技術部の国分 (@k0kubun) です。 3/28にクラウドワークスさんで行なわれたRails Upgrade Casual Talksで、Railsアップグレードの際にクックパッドが行なっている工夫について紹介しました。 影響範囲の予測が難しいRailsのアップグレードを安全に行なうための動作確認のやり方について参考になればということで、本記事でも改めて紹介いたします。 CookpadのRailsアップグレードの流れ Rails 4.1から4.2にアップグレードした際の例を紹介します。 CIにRails 4.2用ジョブを用意 まずはRails 4.2にアップグレードするためのrails42ブランチでテストを通します。リリースするまでこのブランチはmasterからrebaseし続けるので、リリースまでテストを通る状態を保つため、CIにrails42ブランチ用のジョブを用意しま
クックパッドにおける最近のMicroservices事例 - クックパッド開発者ブログ
こんにちは。技術部の吉川です。 最近ではMicroservicesという言葉もかなり浸透し、そのテクニックも体系化されつつあります。 一方でMicroservicesについての話は概論や抽象的な話が多く、具体像が見えないという方もいらっしゃるのではないでしょうか。 当ブログでは1年半ほど前にMicroservicesへのとりくみについてご紹介しました。 当時社内ライブラリだったGarageはその後オープンソースとして公開され、また社内のシステムも当時と比べ飛躍的な進化を遂げています。 そういったクックパッドにおける最近のMicroservices事例を先日Microservices Casual Talksで紹介しました。 Microservicesの抽象的な話は一切割愛し、具体的な事例に終始した内容となっています。 Microservicesの基本となる考え方はわかったものの、実践方法で
チームメンバーとの信頼関係を築く：定期個人面談の薦め - クックパッド開発者ブログ
こんにちは。新規広告開発部所属エンジニアのレオ（@lchin）です。 ここ2年ほどは、大きな事業部のなかの小規模なエンジニアチームのリーダーを務めてきました。エンジニアリーダーとしては、1人のエンジニアとしてソフトウェア開発をしつつ、チームのメンバーの力をまとめて、事業部のゴールを推進しました。事業部のマネージャほど、マネジメント業務が中心になるわけではありませんが、多くのエンジニアが苦手な人間関係スキルはエンジニアリーダーにも必要です。 メンバーは何か大きな不安を抱えていないのか？ポテンシャルを発揮できていないメンバーにどうフィードバックするのか？メンバー間に何かトラブルはないのか？見えないところで仕事の妨げはないか？チームでソフトウェア開発を行う上のよくある悩みだと思いますが、皆さんはどう解決していますか？私は、個人面談はこういった悩みを解消するための大変有効な手段だと思います。 なぜ
アラートエスカレーションシステム"Waker"の紹介 - クックパッド開発者ブログ
インフラストラクチャー部の荒井（@ryot_a_rai）です。今回は社内で利用しているアラート通知システムであるWakerの紹介をします。 Wakerはアラートを受け付けて、指定されたユーザに電話などの手段でアラートを通知するためのアプリケーションです。 PagerDuty アラートのエスカレーション・通知といえばPagerDutyが有名ですが、弊社では主にコスト面でPagerDutyを利用していません。日本国内への電話発信はGlobal Phone Alertsとしてカウントされ、通知数にもよりますが1ユーザ当たり$29〜49/月かかります。これを高いとするか、安いとするかはそれぞれかと思いますが、ユーザが増えてくると高くなるためユーザの追加がしづらく監視の委譲・分業がすすめづらいという点がありました。 また、弊社ではシンプルなエスカレーションと電話通知のみが必要されていた、という背景が
マイクロサービス時代を乗り越えるために、Rack::VCRでらくらくアプリケーション間テスト - クックパッド開発者ブログ
新規アプリケーションの構成 Rack::VCR リクエストの記録 リクエストのモック リクエストの再生 おまけ: Androidアプリのテスト 弊社での利用例 未来 こんにちは、会員事業部の小室 (id:hogelog) です。気づけば弊社に入社してから２年と2ヶ月が経っていました。 今回はその2年2ヶ月で初めて会社プロダクトを rails new したRailsアプリケーションと、そのアプリケーションで利用したRack::VCR (https://github.com/miyagawa/rack-vcr) について簡単に解説します。 新規アプリケーションの構成 今回私が新規に作成したRailsアプリケーションは仮にここではomoikane（仮）と呼ぶことにします。omoikaneはリクエストがあると社内の汎用APIサーバにアクセスし、APIサーバから取得した情報を元にレスポンスを返すアプ
nginx で omniauth を利用してアクセス制御を行う - クックパッド開発者ブログ
インフラストラクチャー部 id:sora_h です。クックパッドでは、社内向けの Web アプリ (以降 “社内ツール”) を社外のネットワークから利用する際、アプリケーションレベルでのアクセス制御とは別に、リバースプロキシでもアクセス制御を実施しています。*1 これまで BASIC 認証あるいは VPN による社内ネットワークを経由した接続という形で許可していました。しかし、iOS の Safari などでは BASIC 認証時のパスワードを保存できない上、頻繁に入力を求められてしまいますし、VPN はリンクを開く前に接続をしておく必要があります。これにより、社内ツールを社外で開く時に手間がかかってしまう問題がありました。 これに対し、一部では typester/gate などを導入し Google Apps での認証を行なっていました。しかしいくつか問題があり、非アドホックな対応では
ディレクターの知見共有の仕組み - クックパッド開発者ブログ
こんにちは、検索・編成部の五味と申します。 現在はディレクターとして、クックパッドiOS／Androidアプリを使いやすくするための施策を主に担当していますが、年初に異動して来るまでは、広告クリエイティブ制作というまったく異なる仕事をしていました。 サービス開発に関しては初心者状態だった私にとって、貴重な学習機会を与えてくれている、クックパッドのディレクター同士の情報共有の仕組みをご紹介します。 ディレクター同士の連携は難しい？ まずはじめに、現在クックパッドでは事業部制が採用されており、ディレクターは複数の部署に数名ずつ分かれて働いています。 ところが、ディレクターは同職間での連携が難しい職種でもあります。通常1つの施策を複数名で担当することはないので、お互いの業務進捗を報告しあってもいまひとつ理解しきれませんし、担当する施策の内容もバラバラであることが多いため、業務フローに問題があって
クックパッドの本番環境で使われている Ruby のバージョンが 2.2 になりました - クックパッド開発者ブログ
技術部の鈴木 (@eagletmt) です。 先日、クックパッドで使われている Ruby のバージョンを 2.0.0 から 2.2 にアップグレードしました。 アップグレードは主に @sorah と私で進めました。 今回はアップグレードまでの過程やアップグレード当日の流れ、そして今のところ見られているアップグレードによる効果などについて紹介します。 アップグレードまでの準備 テストを通す Ruby 2.1 がリリースされたときから 2.1 にアップグレードできないか検証環境でテストを回していました。 しかし、当時はクックパッドの全テストを実行すると必ず途中で Ruby がクラッシュする現象に悩まされていました。 Ruby の GC のバグ、拡張ライブラリのバグを疑いながら色々やってみたものの結局解決できず、Ruby 2.2 がリリースされてからもこの状況は改善されませんでした。 しかしある
安全なリリースのために心がけていること - クックパッド開発者ブログ
こんにちは。会員事業部の高田です。今回は安全にリリースをするために、アプリケーションエンジニアとして心がけていることについて書きます。 クックパッドではなるべく早くユーザーに価値を届けることを大切にしているため、1 日に何度も安全にリリースできるしくみや、リリース後に発生したエラーにすぐに気付けるしくみがあります。しかし、アプリケーションレイヤーの問題はアプリケーションエンジニアが気をつけなければいけません。私個人としては、少し気をつければ防げた問題を起こしてユーザーや会社に迷惑をかけてしまった経験があるため、注意深くなっています。 プロジェクトの大きさや目的はさまざまあり、早くリリースして検証したい施策などもあると思います。今回は慎重にリリースしたいプロジェクトの例として、有料会員の解約の前に特定のユーザーにのみクーポンを配布するという架空のプロジェクトを元にお話します。 1. 準備 リ
いまさら聞けない「コードの英語」超入門 - クックパッド開発者ブログ
広告事業部の鈴木達矢です。コーディングをしてると変数やメソッド名の付け方に悩むことって多々ありますよね。逆にコードを読んでいると単語の選択がこれでいいのかなという時や、動詞の活用形が間違っていてよく意味がわからない、時に潔く日本語の変数名になっていることも見かけます。でもプログラミング言語の単語が英語をベースにしていますし、Railsを使っている場合は日本語が規約（Convention）に合わなかったりします(複数形が無いなど)。それから動詞の活用形が違っていると主語（動作の主体）が変わってしまい、意味が変わってしまいます。その結果コードの可読性が落ち混乱を招きやすくなります。 いくつかの基本的な法則だけおさえておけばコーディング中に可読性の高い単語の選択ができるようになります。今回はそれを目的に、英語の扱いに都度時間を費やしてしまうような方に向けていくつかの法則をご紹介します。*1 変数
Dokumi (日本語) - クックパッド開発者ブログ
(English version here) 技術部モバイル基盤グループのヴァンサン(@vincentisambart)です。今日は最近作ったツール「Dokumi」の話をしようと思います。 紹介 他部署のエンジニアの仕事をもっと楽にすることが、技術部の重要な目的の1つです。その中で、Dokumiはモバイル開発者のコードレビューの負荷を減らすためのツールです。 なぜ「毒味」という名前にしたかと言うと、人間がレビューする前に、コードに毒(バグ、不自然なコードなど)が入っているかどうか毒味するツールだからです。別の言葉で言うと、少し進化したCI用のlintツールですね。pull requestが出る度に、Jenkinsがそのpull requestにDokumiをかけます。現在はDokumiはiOSアプリだけに対応してしていますが、今後はAndroidアプリへの対応も考えています。 現時点でDo
エンジニアのキャリアの方向性 - クックパッド開発者ブログ
CTO の舘野 (id:secondlife) です。丁度1年半ほど前に、クックパッドの CTO になり、自分が20代の時に憧れていたいわゆるハッカーとは違う道を歩んだという事もあり、ソフトウェアエンジニア*1のキャリアってどんな物があるんだろうと改めて考えた時期がありました。 しかしながら一人悶々と考えても、答えが見つかる物でも無かったので、私の先を行く方々の話を聞きたいんですよね、みたいな事を md2inao で有名な WEB+DB PRESS 編集長の稲尾さんとしていたところ、じゃあそれ連載記事でどうですか、とお話を貰ったので記事として連載させて頂きました*2。 その時、連絡させていただいたメールにはこんなことを書いていました。 背景としては、今やエンジニアは、サーバサイドは AWS/heroku 等 IaaS/PaaS の台頭、github を中心とした OSS フレームワーク・ラ
シンプルで移行しやすいデータベースシャーディング - クックパッド開発者ブログ
技術部の小野(taiki45)です。クックパッドではこれまで様々なデータベースの負荷対策を行ってきましたが、シャーディングは行われていませんでした。しかし先日クックパッドの認可サーバーが利用している MySQL サーバーの負荷分散のためにクックパッドで初めてのシャーディングを行ったので、Rails アプリケーションでのシャーディングの事例のひとつとしてその際の手法をご紹介したいとおもいます。 構成 Before データベースは1マスター、1ホットスタンバイ、バッチ用の1リードレプリカで構成されています。Read オペレーションのほとんどはキャッシュ層に逃しています。 After データベースの各ロールにつきそれぞれ1台ずつマシンが増えています。 シャーディングが必要になった背景 認可サーバーのアクセストークンの作成・削除時の Write オペレーションが急増し、レコード数自体も急増していて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
