ストレスフリーなGitHubのIssue生活

こんにちは。サービス開発部の丸山@h13i32maruです。

今日はGitHub/GHE(GitHub Enterprise)で快適なIssue生活をおくるために作ったJasperというツールと、それを実際にどうやって使っているかを紹介させていただきます。

ストレス

GitHub/GHEを日々の業務の中心として使っていると、すごくたくさんのIssueやPull Request(以下PR)が流れてきます。 これらのIssueを処理する方法としては主に「メール」と「通知ページ(github.com/notifications)」の2つだと思います。 僕もこれらの方法を使っていたのですが、以下の点ですごく困っていました。

  • 多すぎてメンションされたものやコメントしたものを見逃してしまう
  • あとで見ようと思って、忘れる
  • ブラウザのタブを大量に開いた状態になる
  • 知らないところのIssueで議論が進んでいて気づけ無い
  • チームの人がIssue上でどんな活動をしてるのかわからない

こういうことに日々気をつけながら、仕事をしていると凄いストレスを感じてしまいます。 そこで、これらの問題を解決するためにJasperというGitHub用のIssue Readerを作りました。

f:id:h13i32maru:20170313110353p:plain:w600

Jasperとは

JasperはGitHubのIssue/PRを柔軟にかつ効率的に閲覧・トラッキングするためのIssue Readerです。 と、これだけではどんなものなのか想像しづらいと思うので、以下のスクリーンショットをみてください。

セットアップが終わると、このような画面になります。左のペインから「Stream一覧」「Issue一覧」「Issue本体」となります。

f:id:h13i32maru:20170315081116p:plain:w600

この「Stream」というのがJasperのコア機能になります。 例えば「x10/cooking-logというリポジトリでryo-maruyamaがアサインされているIssueをみたい」と思った場合、以下のようなStreamを作成することになります。

repo:x10/cooking-log assignee:ryo-maruyama is:issue

f:id:h13i32maru:20170313110451p:plain

Streamを作成して、数秒待つと、以下のように当該の条件にあうIssueの一覧を見ることができます。

f:id:h13i32maru:20170313110501p:plain:w200

Issue生活

では、実際に私は仕事でどんなStreamを作ってJasperを活用しているか簡単に紹介します。

内容 Stream例
自分が関係したIssue/PRを把握する
(メンションされた OR コメントした OR アサインされた OR 作成した)
involves:ryo-maruyama
自分のGitHubチームあてにメンションされたIssue/PRを把握する team:tech/all team:android/all
自分が作成したIssueを把握する is:issue author:ryo-maruyama
自分が作成したPRを把握する is:pr author:ryo-maruyama
自分がメインで活動しているリポジトリのIssue/PRを把握する repo:ha/kiroku-g repo:x10/cooking-log
グループメンバが出しているPRを把握する is:pr author:member1 author:member2 author:member3
グループメンバのIssueでの活動を把握する is:issue involves:member1 involves:member2 involves:member3
隣のグループのIssueでの活動やPRを把握する involves:other1 invovles:other2 involves:other3
他部署の活動を把握する is:issue user:research user:partner-alliance
直近のリリースについて進行を把握する repo:android/android-cookpad milestone:v17.3.1
影響がありそうな問題をすぐに把握する repo:x10/cooking-log label:important label:bug
重要であったり、特に見ておいたほうがよいIssueを把握する is:issue label:注目
社内エゴサーチ(※日本語のエゴサーチはできなさそう) redshift OR dwh

これらを見て気づいたかもしれませんが、StreamにはGitHubの検索クエリがそのまま使えます。 Streamの使い方、GitHubの検索クエリについて詳しくは以下のURLをご参照ください。

どうなったか?

Jasperを使うことによって、私は仕事でIssue/PRの見落とし防止や他の人の活動を格段に把握しやすくなりました。 また、社内でも多くのエンジニア、デザイナ、ディレクターの人が使っています。 ダウンロード数ベースでは約100人程が使ってくれています。中にはこういったフィードバックをくれる方々もいました。

f:id:h13i32maru:20170313110518p:plain:w800

f:id:h13i32maru:20170313110522p:plain:w700

f:id:h13i32maru:20170313110554p:plain:w400

また、GitHubの中の人にも使っていただけているようです。

技術的な紹介

ここまでは、主にJasperの使い方を紹介したので、ここでは簡単に技術的な紹介をします。

JasperはElectronと呼ばれるデスクトップアプリを作るためのOSSを使って作られています。 このElectronはGitHub社が主に開発しており、クロスプラットフォームで動くことを売りにしています。 JapserもMac版/Windows版/Linux版を提供しています。

Electronでアプリを作るためにはネイティブアプリの実装方法を覚える必要はなく、JavaScript/HTML/CSSを使って実装することができます。 そのためWebの開発をある程度分かる人なら、すぐにでもアプリを作り始めることができます。 Jasperも初期のプロトタイプは土日だけで作ることができました。 また、ECMAScript2015以降やasync/awaitもトランスパイルなしに使えるのも魅力的です。

Electronで作られている有名なアプリとしては、Atom、Visual Studio Code、Slackなどがあります。 この他にも多くのアプリが作られており、実績もあり活発に開発されているので、デスクトップアプリの開発に興味がある方にはオススメです。

まとめ

JasperにはIssue/PRを閲覧しやすくするために、Stream以外にも更新通知、未読管理、未読コメント管理、フィルタ、スター、キーボードショートカットなど、便利な機能があります。 なので、毎日たくさんのIssue/PRを閲覧するのに苦労している人もそうじゃない人も、是非一度Jasperを使ってみてください。

以下は個人ブログでJasperについて記事です。よかったら読んでみてください。

クックパッドにおける最近の機械学習について

f:id:yoshiaki-0614:20170303110052p:plain こんにちは、研究開発部の山田(@y_am_a_da)です。

去る2月16日、「Cookpad Tech Kitchen #5 クックパッドにおける最近の機械学習について」と題して、機械学習に関わっている方々向けの技術交流イベントを行いました。

https://cookpad.connpass.com/event/49324/

定員が70名のイベントでしたが、告知してから30分ほどで応募者数が定員超えの100人近く集まり、最終的には400人を超す方々にお申込みいただきました。これまでに開催したTech Kitchenの中でも過去最高の申込数であり、機械学習への関心の高さを感じました。 昨年7月に発足したばかりの研究開発部では、現在クックパッドに投稿されている250万品以上のレシピを始めとするさまざまなデータに対して、機械学習を活用したサービス開発を行っています。このイベントでは、研究開発部の現在の取り組みとそこで得られた知見について発表を行いました。

この記事では、その様子についてお伝えします。

クックパッドと自然言語処理 (Cookpad and NLP)

f:id:yoshiaki-0614:20170303120244p:plain

まず、原島から、クックパッドでの自然言語処理の活用事例について紹介がありました。

この発表では、自然言語処理による

  • レシピの分類
  • レシピの翻訳

などについて紹介をいたしました。具体的には、現在「おまかせ整理」として提供されているレシピのカテゴリ分類機能の実装方法と、日本語のレシピを英語のレシピに変換するためのモデルについて紹介をしました。

発表内容の一部は

でもご覧いただけますので、ご興味あるかたはあわせてご覧ください。

また、2年前に公開したレシピデータセットとその利用状況についても紹介をいたしました。

Food image object detection and classification: Challenges and solutions (part1 - object detection)

f:id:yoshiaki-0614:20170303115507p:plain

次に、レシェックから、画像認識を用いた写真中の料理領域の認識について紹介いたしました。

この発表では

  • ILSVRCの歴史
  • 「料理があるかどうか」だけでなく「どこに料理があるのか」を認識するための手法

についての紹介をいたしました。

具体的には、You Look Only Once、略してYOLOと呼ばれる手法による動画中からリアルタイムでの料理認識について触れ、発表の最後ではそのデモを行いました。

Food image object detection and classification: Challenges and solutions (part2 - classification)

f:id:yoshiaki-0614:20170303120245p:plain

最後に菊田から、画像認識を用いて写真が「料理」か「非料理」かを分類する手法について紹介いたしました。

この発表では

  • クックパッドで提供している「料理きろく」のアーキテクチャ
  • 「料理きろく」で行っている写真の「料理」「非料理」を分類するための試行錯誤

についての紹介をいたしました。

具体的には、発展著しいディープラーニングモデルの比較検討や二値分類問題の多クラス化拡張、など様々な試行錯誤をしながらサービスレベルの向上に取り組んだことについて紹介をしました。

質疑応答

質疑応答は、休憩時間中に質問を紙に書いてボードに貼ってもらう形式だったのですが、時間内に全て答えきれないほどの質問数で、大変盛り上がっていました。内容としては

質問1

料理/非料理の画像判別モデルの改善において様々な工夫をしたということだが、どんな取り組みが最も性能向上に貢献したか

回答1

CNNのモデルをより良いものにアップグレードすることと、二値判別問題から間違えやすいクラスを追加した多クラス問題に拡張したことの寄与が大きかった。データセットを拡充するというのも基本的かつ効果的だと思われるが、アノテーションのコストもあるため徐々に進めている。

質問2

研究開発をする部署にとって研究と開発の棲み分けは重要だと思うが、クックパッドの研究開発部ではどのように棲み分けをしているのか

回答2

それぞれが密接に関連しているものなので、明確に棲み分けてはいない。ただし個々人の興味や要求されるスキルが異なるため、研究の方に重きを置くメンバー、開発の方に重きを置くメンバー、というようにメンバーによって比重は異なっている。

などがありました。

懇親会

発表会の後は、懇親会を行いました。

懇親会では、弊社の研究開発部メンバーと参加者と用意されたご飯を食べながら様々な意見交換や雑談をしました。 今回の料理の目玉は、下のようなクックパッドロゴの入ったライスケーキでした。 f:id:yoshiaki-0614:20170303110047p:plain

まとめ

いかがでしたでしょうか。 クックパッドでは、一緒に機械学習を行っていくエンジニアを募集しています。ご興味ある方はぜひ遊びにいらしてください。 画像認識エンジニア | クックパッド株式会社 採用情報

クックパッドのiOSアプリ開発を加速させるスクリプト群

こんにちは、技術部モバイル基盤グループの茂呂(@slightair)です。

今回は、ちょっと地味ではありますが、クックパッドのiOSアプリ開発を支えているスクリプト群について書きたいと思います。

日々iOSアプリ開発を行うとすれば、Xcodeまたはその他のお気に入りのエディタでコードを書き、ビルドと実行を繰り返して開発を進め、アプリが完成したらサブミット、めでたくリリースという流れになると思います。 場合によってはこうした開発の所々をサポートするツールを使うこともあるでしょう。クックパッドでもいくつかのツールを使っていますし、場合によっては自作することもあります。

ツールを導入することで解決できることであればそれでよいですが、もうちょっと気の効いたことをして欲しい、リリースフローなど自分たちのアプリ開発の進め方の都合で発生する繰り返しタスクを省力化できないか、というような比較的小さな問題を解決するために、僕たちは今回紹介するようなスクリプトを用意しています。

開発支援系

アプリ開発を支援するスクリプト群を紹介します。

利用ツールのバージョンチェック

クックパッドのiOSアプリ開発では CocoaPods, Carthage, clang-format, SwiftLint, SwiftFormat などのツールを使っています。 数が多い上にこれらのツールの更新頻度はバラバラで、バージョンによって動きが違ったりします。複数人でアプリを開発しているので、環境によって期待している効果が得られないと困ってしまいます。そのため、各開発者の環境に期待しているバージョンがインストールされているかチェックするスクリプトを用意しています。

ライブラリ群のインストール

クックパッドのアプリは CocoaPods と Carthage を併用しています。 CocoaPods は Objective-C で書かれた静的リンク可能なライブラリ群を、Carthage は Swift のライブラリ群をインポートするために使っています。 何故このように使い分けているかというと、CocoaPods で導入しているライブラリの一部が静的ライブラリであって use_frameworks! が使えないからです。 またフレームワークが増えるほどアプリ起動に時間がかかってしまう問題を防ぎたいというのも理由です。

CocoaPods と Carthage のコマンドを叩き、Carthage がチェックアウトしたライセンスファイル群を CocoaPods の acknowledgements.plist にマージするスクリプトを用意しています。

また、Carthage にはこの記事を書いている時点では更新のあったライブラリだけをビルドし直す仕組みがなかったので、ビルド時間を抑えるために更新が必要なライブラリだけをビルドするスクリプトを用意していました。 この問題への対応はすでに PR が出てマージされているので、新しいバージョンではこの処理は必要なくなりそうです。

前述のツール群のバージョンチェックとあわせて make でこの操作を実行できるようにしています。 各開発者は手元へ最新のコードを fetch した後に make コマンドを実行することで、チームで期待されている開発環境にそろえて開発に取り掛かることができるようになります。

コードフォーマッタ

コードフォーマッタに clang-format と SwiftFormat を使っています。 直接これらのツールを使ってもよいのですが、ちょっとした工夫をしています。

clang-format はオプションで format をかけたい範囲を指定できるので、開発者が変更を入れた箇所にだけフォーマッタをかけるスクリプトを用意しています。ファイル単位でも良いのですが、PRを出した時に変更とは関係のないフォーマッタによる修正が混ざるとレビューする側がつらくなってしまうので、こうしています。

また、フォーマッタにかけるのを git の commit hook などに仕込むこともできると思いますが、意図的にしていません。これは、フォーマッタによって自動的に変更されたコードを開発者に確認してもらいたいからです。

リリースフローに関係するタスク補助系

クックパッドのリリースフローに含まれるタスクのうちスクリプトで解決しているものを紹介します。

アプリのバージョンを繰り上げる

アプリのバージョンを変更するというただそれだけのスクリプトを用意しています。特に面白みのないものですが、Extension を複数持つアプリだとそれに対応する info.plist がいくつもあるので地味に面倒な作業であることがわかると思います。クックパッドではこの部分の変更作業を複数人で回しているので、スクリプトで行えるようにしているのは作業する人によって微妙に違う内容になってしまうのを避ける目的もあります。

開発に関わった人ごとのマージコミットをリストにする

リリースフローに、次にリリースしようとしているバージョンのコードに自分がいれた変更が正しく含まれているか各開発者が確認する手順があります。このチェックリストをつくるスクリプトがあります。 単純に git のコマンドを利用してマージコミットのリストを作るだけのものですが、このような単純な作業こそスクリプトにしやすく、単調で間違いやすいタスクなので、スクリプトで片付けるようにしています。

開発環境の計測系

開発に直接関わるものではなく、開発環境がどういう状態であるか計測するためのスクリプトもあります。

Swift 移行率の計測

毎日リポジトリの master ブランチに含まれる iOS アプリのコードのうち Swift のコードの割合がどれくらい変化しているか計測・記録し、グラフに描画するようにしています。 単純な興味もありますが、Objective-C のコードが残っていると Swift の便利な機能が使えない場面が多くでてきてしまうので、必要に応じて Swift への書き換えを進めています。この進行具合が可視化されると、少しだけやる気がでたり達成感が得られます。

ビルド時間の計測

アプリのビルドにどれくらい時間がかかっているのか、バージョンを重ねるたびに変に伸びたりしていないか計測しています。ビルドに時間がかかっているということは、それだけ開発者を待たせてしまい生産性を下げていることになるので、状況を把握するために記録しています。ここで計測している時間をもとに、ライブラリの選定や場合によっては直接的な対策を行います。特に Swift を採用してからは書き方によってビルド時間が変に長くなってしまうこともあるので xcprofiler などを使って具体的な場所を特定したりもします。


これらのスクリプトはだいたい Ruby で書かれています。 Makefile などから呼び出されているスクリプトもありますが、最近は fastlane をよく使っているので、fastlane action として実装し直そうという動きもあります。今回紹介したようなスクリプトの中で汎用的な action として分離できるものがあれば、公開していきたいと考えています。

クックパッドではiOS/Androidに詳しいモバイルアプリ開発エンジニアはもちろんのこと、このようなモバイルアプリ開発をより効率よくするために活躍できるエンジニアを募集しています。