モバイル基盤グループのヴァンサン(@vincentisambart)です。 iOSの設定画面の右側は一定の幅を超えないように作られています。 iPadでは: 新iPad Pro 12.9"では: iPadでTwitterのタイムラインのセルの中身も一定の幅を超えません。 このように、自分のアプリで広い画面でもコンテンツが広がりすぎないようにするためにはどうすればよいのでしょうか。AutoLayoutでいくつかの制約を使ってできるのですが、もっと簡単な方法はないのでしょうか。 iOS 9以上では、端末の種類を気にせず、複雑なAutoLayout制約を使わず、殆どのビューですぐ使える仕組みがあります。Appleのドキュメントで「readable content」や「readable width」と呼ばれているものです。以下日本語で「読みやすい幅」と呼ぶことにします。 注意点：下記の説明はAut

モバイル基盤グループのヴァンサン(@vincentisambart)です。 Swift 4 で JSON を読み込むための仕組みとして Swift.Decodable が追加されました。 iOS クックパッドアプリでは、 Swift での JSON の読込は以前 Himotoki が使われていましたが、新規コードでは Swift.Decodable が使われています。依存関係を減らすために、 Himotoki を使っているコードが少しずつ Swift.Decodable に移行されています。 ただし、この間、ユーザーの報告で分かったのですが、最近 Himotoki から Swift.Decodable に移行したコード辺りに一部のユーザーにエラーが出ています。 iOS 10 に限りますが。 調査 調べてみた結果、以下のコードでエラーを再現できました。 struct MyDecodable:

こんにちは、技術広報を担当している外村です。 2018年2月10日にエンジニア向けのカンファレンス、Cookpad TechConf 2018を開催しました。当日はたくさんの方に参加いただき、活気あるカンファレンスになりました。ご来場の皆様本当にありがとうざいました。 新しい試みとして、当日の司会をAmazon Pollyの音声合成で行なったのですが、こちらもみなさんにお楽しみいただけたようでした。 講演資料・動画 当日の講演資料および動画を公開いたしましたので是非ご覧になってください。 基調講演: 毎日の料理を楽しみにする挑戦をし続けた20年 by 橋本 健太 コーポレート戦略部本部長の橋本による基調講演でイベントはスタートしました。クックパッドはテックカンパニーとしてどのように成長してきたか、グローバル展開をどのように行ってきたか、現在取り組んでいる新プロジェクトについての話などがあり

サービス開発部の外村 (@hokaccha）です。 クックパッドのアプリには「料理きろく」という機能があります。 モバイル端末から料理画像のみを抽出して記録することで食べたものが自動的に記録されていくという機能です。 今回はこの料理きろくで画像判定をおこなっているバックエンドのアーキテクチャについて紹介します。なお、実際に判定をおこなう機械学習のモデルのはなしは以下の記事に書かれているのでそちらを参照してください。 料理きろくにおける料理/非料理判別モデルの詳細 - クックパッド開発者ブログ また、以下のスライドでも料理きろくのバックエンドについて紹介されているのでこちらも参照してみてください。 処理の概要 ざっくりとした画像判定のフローとしては、次のようになります。 クライアントアプリは端末内の画像を判定用に縮小してサーバーにアップロードする サーバーはアップロードされた画像を機械学習を

こんにちは、サービス開発部の氏です。 主にiOSのクックパッドアプリの開発を担当しています。 UICollectionViewLayout みなさん使ってますか？ UICollectionView でレイアウトを組む際、実際触り始めると実装するための選択肢が複数あり、どれが最適なのか悩ましい場面に遭遇する人もいるのではないかと思います。 今回は、自分が業務で触れた際に得た知見について軽くお話したいと思います。 UICollectionVIewLayout とは UICollectionView は Cellのサイズや余白等のレイアウトを管理するため、プロパティとして、 UICollectionViewLayout を所持しています。 この UICollectionViewLayout に手をいれることによって、レイアウトを好きな形に変更することができます。 レイアウトを組み立てるときの複数

こんにちは、技術部モバイル基盤グループの茂呂(@slightair)です。 今回は、ちょっと地味ではありますが、クックパッドのiOSアプリ開発を支えているスクリプト群について書きたいと思います。 日々iOSアプリ開発を行うとすれば、Xcodeまたはその他のお気に入りのエディタでコードを書き、ビルドと実行を繰り返して開発を進め、アプリが完成したらサブミット、めでたくリリースという流れになると思います。 場合によってはこうした開発の所々をサポートするツールを使うこともあるでしょう。クックパッドでもいくつかのツールを使っていますし、場合によっては自作することもあります。 ツールを導入することで解決できることであればそれでよいですが、もうちょっと気の効いたことをして欲しい、リリースフローなど自分たちのアプリ開発の進め方の都合で発生する繰り返しタスクを省力化できないか、というような比較的小さな問題を

技術部モバイル基盤グループの ヴァンサン です。 西山が 以前紹介したように 、クックパッドでは 2014 年から Swift を使っています。長い間、海外向けのアプリや みんなのお弁当 だけに使われていましたが、去年の5月から、 クックパッド iOS アプリ の開発にも Swift を使うようになりました。歴史のある iOS アプリなので Objective-C でのコードの方がまだ多いのですが、いまは既存の画面の変更を除いて新しいコードが Swift で書かれています。既存の画面を Swift で書き直すこともあります。 Xcode 8.0 がリリースされてから数ヶ月 Swift 2 を使っていましたが、去年の12月のリリース直後に Swift 3 へのマイグレーションをしてから、開発で Swift 3 を使っています。2017年2月1日にリリースされた 17.1.1.0 が Swif

インフラ部 id:sora_h です。 先週開催された Cookpad TechConf 2017 如何でしたでしょうか。わたしは TechConf において Wi-Fi を担当していて、こちらも好評いただいたようでなによりでした。 というわけで、この記事では TechConf 2017 における Wi-Fi についての詳細を紹介します。 ネットワーク機器設定・サーバー mitamae レシピ等の公開 https://github.com/cookpad/techconf2017-network 今回の紹介する構成のうち、ネットワーク機器およびサーバ側の設定等、ほとんどを GitHub で公開しています。参考までにどうぞ。 TechConf 2017 NOC メンバー 実は外注などはしておらず、社内 IT と SRE グループのメンバーで構成されていました。 メイン (設計・運用・設営)

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

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

海外事業向けのiOSアプリケーション開発を担当している西山(@yuseinishiyama)です。クックパッドは現在、海外複数カ国に向けてサービスを展開しています。 海外事業向けのiOSアプリケーションは、英語、スペイン語、インドネシア語、タイ語、ベトナム語、アラビア語をサポートしています。今後、サポートする言語は更に増えていく予定です。 これまで、複数の言語に対応するための国際化(internationalization)と地域化(localization)を行ってきました。ここでは、その中で得た知見を以下の4つのパートに分けて共有したいと思います。 コンテンツとUIの言語の決定 RTL対応 翻訳フロー 翻訳に関するTips ちなみに、当該プロジェクトがサポートしているiOSバージョンはiOS8以上です。そのため、iOS9以降でしかサポートされない機能については触れません。 また、我々の

Android/iOSアプリを開発している皆様、こんにちは。技術部の松尾(@Kazu_cocoa)です。テストエンジニアとして、サービスの品質を向上するために様々な活動を行っています。特に最近はモバイルアプリに注力しています。 この記事をご覧になっている皆さんは、モバイルアプリに対する品質をどのようにお考えでしょう？例えば、アプリがクラッシュしないとか、アプリが機能不全無くシナリオを実施できるとか、そういう面は想像が容易だと思います。品質に対する機能的な側面の指標の1つですね。 品質を考える上では機能的な側面だけではなく、非機能的な側面も考える必要があります。例えば、モバイルアプリを使っているときにサクサク動いているとか、そういう観点は利用時の効率性という側面を持ちます。これにはCPU使用率やメモリ使用量、通信量、見せかけのUIなどが関係してきます。これらの指標を常時取得、監視する、という