料理動画事業室の @yoshiori です。前に「RESTful Web API 開発をささえる Garage」で紹介した RESTful Web API を開発する Garage のクライアント側のライブラリを公開しました。この記事ではその使い方を紹介したいと思います。Garage の設計思想やサーバ側の実装については上記記事を御覧ください。 今回は簡単にクライアント側の挙動を知っていただくために pry を使って説明したいと思います。 アクセスするサーバは先程の記事で作成したアプリケーションを使用してみます。 サーバの準備 https://github.com/taiki45/garage-example の README にも書いてありますので簡単に進めたいと思います。 まずは下準備としてコードを github から clone してきて、ライブラリのインストールと DB のマイグレ

モバイルファースト室の @slightair です。 先日、モバイルアプリのログ収集ライブラリ「Puree」をリリースしました という記事で Puree というログ収集ライブラリを紹介しました。 Android 版につづき iOS 版もリリースしたので紹介したいと思います。 puree-ios : https://github.com/cookpad/puree-ios モバイルアプリのログ記録の難しさや、それを解決するための Puree の思想についての説明は前回の記事におまかせします。 iOS 版の Puree も Android 版と同じようにフィルタリング、バッファリング、バッチ、リトライの機能を備えています。 ログのフィルタリングや出力の振る舞いをプラグインとして定義し、それらを組み合わせることで効率的なログ収集を実現します。 Puree iOS の使い方 Puree の導入方法

モバイルファースト室の山下( @tomorrowkey )です。 みなさんはAndroidアプリをビルドするときに AndroidStudioの実行ボタンを押すのと、ターミナルでgradleコマンドを実行するのと、どちらを使っていますか。 クックパッド社内のAndroidエンジニアでもどちらを使うか好みが分かれるのですが、私はたいていターミナルでgradleコマンドを使っています。 AndroidStudioの実行ボタンだとビルドを途中で中止できないことがあるからです。コマンドであればcontrol+cでいつでも中止できるという気軽さからコマンドを好んで使用しています。 開発するうえでIDEなどのGUIツールはとても便利なのですが、実はコマンドを実行する方がはるかに早くストレスなく開発を進めることができることがあります。 今回は私が実際に使っている便利なコマンドラインスクリプトを10個紹介

クックパッド 広告事業部の大野晋一です。責任範囲は広告事業の純広告およびネットワーク広告の商品開発担当で、事業部にはそれぞれの売上でコミットしています。 この記事では、動画変換の仕組みにおけるDockerの活用について紹介します。 クックパッドは8月8日、iOS/Androidのブラウザにおいて動画クリエイティブを掲出する広告商品を公開しました。広告商品としての詳細はプレスリリースやスライドを見ていただくのがわかりやすいのですが、本稿に関係する特徴としてスマートフォンのブラウザで自動的に再生が開始されるというものがあります。 スマートフォンのブラウザにおいては、現在のところ、動画を自動再生させることは出来ません。これはAppleやGoogleといったブラウザベンダが課している制約です。そこで、クックパッドでは、janiというライブラリを使い、特定の規則に基づいて作られた画像を、JavaSc

モバイルファースト室の山下(@tomorrowkey)です。 Androidアプリを開発していて、ふとした時に不具合を見つけたりしませんか。 クラッシュであればDeploygateやCrashlyticsなどでクラッシュレポートを送ることができますが、表示崩れを報告をするにはスクリーンキャプチャを撮ってメールアプリを開き、画像を添付して、送信する、といった手順が必要でなかなか面倒です 。 アプリを開発する側は不具合のあったスクリーンショットがほしい、不具合を報告する人は報告する手順がめんどうといったギャップを解決するためのライブラリを作りましたので、紹介します。 不具合報告する機能を作りました 冒頭のアニメーションgifで一通りの挙動を見ることができます。 このライブラリを使っているアプリを開くと通知領域に「不具合を報告する」という項目が増えます。 不具合を見つけた時にこの通知を選択すると

モバイルファースト室の @rejasupotaro です。 クックパッドでは、サービスをリリースしてログを収集して分析して改善してまたリリースして、というサイクルを素早く回すことでより良いものを作るということをウェブではやってきました。 クックパッドのサービス開発のフレームワークをモバイルアプリでも適用したいのですが、モバイルアプリにはウェブアプリと違ったロギングの難しさがあります。 今回はモバイルアプリのロギングの問題点とPureeというログ収集ライブラリについて話します。 モバイルアプリのロギングの難しさ ウェブアプリでは、基本的にはサーバー側でログを収集することができますが、モバイルアプリの場合は画面の制御はアプリ側で行われ、APIを介してデータを受け取るため、クライアント側でログを収集して送信する必要があります。 アプリのログを収集するのに、画面遷移をしたりタップするたびにサーバー

インフラ部の荒井（@ryot_a_rai）です。この記事ではインフラの振る舞いテストのツールであるInfratasterを使ってリバースプロキシの設定のテストをしてみたいと思います。 Infratasterとは Infratasterはインフラの振る舞いをテストするフレームワークで、RSpecのテストヘルパとして機能します。例えば、 特定のヘッダ付きのHTTPリクエストを送信した時にあるレスポンスヘッダが返ってくることをテストする Capybaraを使って実際のWebブラウザ上での挙動をテストする MySQLのSHOW VARIABLESの結果をテストする といったことが可能になります。 細かい概要についてはこちらのスライドやREADMEをご覧ください。 Serverspecとの違い インフラのテストといえばServerspecが有名かと思いますが、InfratasterはServersp

ユーザファースト推進部の丸山(@h13i32maru)です。 先日「撮るレシピ」というサービスを cookpad.com にて公開しました。「撮るレシピ」というサービスは料理本や雑誌のレシピを写真に撮ってクックパッド上に保存できるというものです。料理本や雑誌でレシピを良く見る方はぜひ使ってみてください(Androidアプリ版もあります)。 この「撮るレシピ」は全体公開前に一部のユーザに限定公開をしていました。そして全体公開をするにあたりフロント側のコードを全面的に書き換え高速化を行いました。その結果、最大で30倍高速化することができユーザの使い勝手が向上しました。以下が「書き換え前」と「書き換え後」の計測結果です(Android端末8機種 + iOS3機種で各操作のターンアラウンド時間*1を計測)。 閲覧系 最大: 30倍高速化(4.2秒→0.14秒) 平均: 15.7倍高速化(3.6秒→

モバイルファースト室の@sys1yagiです。 Android Studioに追加されたGoogle App Engineテンプレートを試そう 導入編の続きです。今回はCloud Endpointsのテンプレートを使ってAndroid Studio上でTodoアプリを作る例を解説します。 Google App Engineテンプレートの利点 Androidアプリケーションの開発においてGoogle App Engine(以下、GAE)テンプレートの利用には以下の利点があると考えられます。 Android Studioでバックエンドも同時に開発できる GAE関連の依存性をGradleで管理できる バックエンドとフロントエンド間のインタフェースの実装が省略できる バックエンドのモデル変更がすぐにフロントエンドに反映されるので迅速なプロトタイピングができる バックエンドはGAEなのでそのまま運用

こんにちは。技術部の松尾(@Kazu_cocoa)です。 主にモバイルアプリ開発において、数ヶ月前よりGitHubのWebhooksを使ったとある取り組みを始めました。HipChatやSlackなどをはじめとした様々なサービスとの連携サービスを提供しているGitHubですが、Webhooksの機能を使うことで、より自分たちの開発を支援する未来を創造できればと思います。以降では、実際の使用例、その実装よりな話しへと話しをすすめます。 クックパッドにおけるWebhooksの使用例 チェックリストによるセルフチェックをPR時に実施する モバイルアプリ開発はWebアプリ開発と異なる点が多々あります。例えば、開発対象の面では端末の多様性、端末システム側設定・通信状態の多様さなど、リリースの面ではデプロイに対する制限や更新がユーザ依存であることなど、です。そのため、当たり前品質の底上げのために不具合の

こんにちは。技術部の吉川です。 今回はクックパッドの開発環境構成、特に開発用データベースの構成についてご紹介します。 開発環境の構成 クックパッドのシステム環境は以下のようなフェイズに分かれています。 ※ これはcookpad.comの構成で、サブシステムや個別のサービスはその規模や特性に応じて構成が異なります。 development 開発者が実際に開発を行う環境です。クックパッドでは仮想環境は用いず、手元のマシンでRailsアプリケーションを動かして開発を行っています。 データベースはローカルではなく、開発者全体で共通の開発用データベースに接続しています。 test 手元でテストを実行する場合は、ローカルマシンのデータベースを利用します。CI（rrrspec）などの場合も同様で、テスト実行サーバーのデータベースが利用されます。 staging stagingといえば準本番環境として、本

こんにちは、技術部の福森 (@sora_h) です。 最近は環境変数に API トークンや credential といった認証情報を入れる事が増えてきています。 たとえば、AWS を利用するツールでは AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY といった環境変数にだいたいの場合で対応しています。 そのため、~/.bashrc や ~/.zshrc などシェルの設定に export を書いておき常に使える状態にしている方も多いと思いますが、 それって実は危険ではないでしょうか? 例えば、下記のようなリスクが考えられます: 意図せず情報が利用されて意図しない副作用が発生してしまう危険性 本番に変更を与えるつもりはなかったけれど事故を起こしてしまう等 悪意のあるスクリプトを実行した際に環境変数を送信などされてしまう危険性 事故や漏洩を防ぐためにも、筆者はかな