こんにちは。インフラエンジニアの永井(shnagai)です。
re:invent真っ最中で、EKS for Fargateが発表されたりFargate Spotが発表されたり今年も激熱ですね！！
今回は、日々アップデートされているECSの新機能の中から今年導入したものと今後導入を検討していきたいと思っているものについて書こうと思います。
内容はざっくりと下記3項目です。
この記事はコネヒト Advent Calendar 2019 4日目の記事です。
続きを読む
こんにちは！エンジニアの @fortkle です。
あの伝説のゲーム「メダロット」のスマホゲームのリリース日がついに 2020年1月23日と発表がありました!*1 いまからワクワクしてきましたね！リリースしたらぜひロボトルしましょう！
さて、今回の記事は「コードレビュー」についてです。コネヒトに入社してから早4年、数百のPRをレビューしてきてだんだんと自分の中でコードレビューに対する接し方が定まってきました。今日は私がコードレビューで心がけていることについてご紹介できればと思います。
コードレビューは様々な目的で行われますが、「欠陥・バグを検出すること」「コードの改善」に期待をしていることが多いかと思います。
これらの目的を達成するためには、既存・変更後のコードの実装意図や背景を理解することがとても重要になります。特に長年運用されているプロジェクトでは、前者の「なぜ今の、既存のコードがこのような実装になっているのか」という歴史的経緯を理解することは、不具合を出さずに安全に開発を行っていくためのスキルの1つです。
弊社コネヒトでは、GitHubのPRを使った開発スタイルを採用しているのでコードの意図や背景を理解するには純粋なコードリーディングと同じぐらい、過去のPRを見るのが効果的なケースがあります。
ここでは、過去のPRを素早く簡単に探し出すために、実際に私が使っているtipsを2つご紹介します。
Annotate Previous Revision で追加・編集されたコミットまで歴史を遡るFind Pull Request Plugin でそのコミットが追加されたPRを開くという手順で簡単にPRを探し出すことができます。
PhpStormやGoLandなどJetBrains製品のエディタにはAnnotateというgit blameと同等の機能があります。行番号を右クリックすることで表示されるようになります。
また、Annotate部分を右クリックすると、さらに選択行のコミットの操作ができるようになります。
Annotate Revision や Annotate Previous Revision を駆使すると、コードスタイルの変更などで追いづらくなってしまったコードも簡単に歴史を遡って探すことができます。
最後に、この Find Pull Request というプラグインを利用すると、右クリックしてメニューを選ぶだけで、選択行が追加されたPRを開くことができるようになります。
この方法はこちらのブログで紹介されており、大変参考になりました！ tenkoma.hatenablog.com
次に tig と open-pull-request を使う方法です。
, < と打つと選択行の履歴を遡れるので追加・編集されたコミットを探すP と打って open-pull-requestをtig上から実行し、PRを開くという手順で簡単にPRを探し出すことができます。
方法1のやり方を知る前はこの方法でPRを探していました。 特別なエディタが不要でどんなプロジェクトにも対応できるので今でもたまに利用しています。
この方法も設定方法などがこちらのブログで紹介されており、大変参考になりました！ blog.mknkisk.com
PRのコメントでもいくつか工夫することを心がけています。
PRにコメントを残すとき、私は以下のようなラベルを使うことが多いです。
| ラベル | 意味 |
|---|---|
| [MUST] | 必ず直してほしいとき |
| [IMO] | 自分ならこう書くかな？どう？という緩やかな指摘のとき（In My Opnion） |
| [nits] | 再レビュー不要な細かな指摘(typoやスタイル等)のとき |
| [質問] | 分からないとき、確認したいとき |
必要に応じてコメントの先頭にこれらのラベルをつけることで、例えば [MUST] は必ず修正してほしい、 [IMO] で指摘された点は一度考えてもらって採用するかしないか決めてほしい、などレビュイー自身に最終的な変更の意思決定をしてもらえるように考えて使っています。
以前は問題がある点や確認したい点のコメントしか残していなかったのですが、最近は勉強になったときや感謝の気持ちを込めて良いと思った箇所にノイズにならない程度にコメントを残すようにしています。
コードレビューという場を、リスクや課題を見つけ出すことだけでなく、自身の学びや自信につながるポジティブな場として活用するために意味はあるかなと思っています。
基本的にPRをレビューするときはどんなに些細な変更でもアプリケーションコードにdiffが入ったら実際にローカル環境で動かすようにしています。
変更内容にロジックが含まれるのであれば、レビュイーが様々なパターンを考慮に入れて実装できているか、抜け漏れがないか、を境界値やEmptyなstateを使って動かして確認します。 このとき単体テストがあれば簡単にチェックができるので、テストの有り難みを感じられますね！
続いてレビュイーとして心がけていることを紹介します。
... といいましたが嘘です！
レビュイーとして心がけていることは、今週末の2019年12月1日(日)に開催されるPHPカンファレンス東京 2019でLTとして発表します！
高野福晃(@fortkle) 17:20〜 Track 1 (1F 大展示ホール) Lightning Talks
登壇タイトル：「余裕を生み出すコードレビュー」
当日ご参加される方はぜひ発表を聞いていただければ幸いです！
また、今年もシルバースポンサーとして協賛いたします。 ブースも出しますのでそちらにもぜひお立ち寄りください！
”Twemoji" by Twitter, Inc and other contributors is licensed under CC-BY 4.0
こんなハートフルなレビューのコネヒトでは一緒に働いてくれるエンジニア募集中です！興味があればこちらもみてください！
こんにちは、エンジニアの@dachi_023です。最近、MacBook Proの調子が悪いのですが修理に行くのが面倒で行っていません。放置し続けていたら直ったりしないかな・・・。
今回の記事はGatsbyで100ページ超えの静的サイトを構築したときの学びについてです。Gatsbyって実際どうなん？って思っている方に読んでもらえたら幸いです。
ママリユーザーが本当に使ってよかったと思う商品・サービスの口コミを元に、自分と家族に合うものを探すことができる「ママリ口コミ大賞」の2019年 秋版のサイトをGatsbyで実装しました。妊娠中の方、育児中の方におすすめしたいサイトです。私も実際つかってみて、「これ、子どもが産まれた時にあったらもっと便利だったな〜！」って毎回思っています。
ママリ口コミ大賞は今回で3回目なのですが、毎回使用する技術が変わっています。その時のリソース事情や要件などに合わせていた結果そうなったわけですが、ママリ口コミ大賞を3回とも実装してみた感想は「リソース足りなくても出来るところまででいいから最初からちゃんとやればよかったな」です。考えが甘かった。
といった歴史があり、自作ジェネレーターの実装やSpreadsheetをDBとして運用するのがめちゃくちゃしんどかった辛さから今回はGatsbyでつくり直し + 商品や口コミのデータをちゃんとRDBに格納、GraphQL経由でデータを取得できるようになりました。開発がとても快適になったのと、RDBの偉大さを再認識することができました。ただ、Gatsbyは使った方が良いケース、悪いケースがはっきりしているのでその辺のPros/Consを書けたら、と思っています。
静的ページしかない時なんかはwebpackをはじめとしたビルドできる環境をつくってもあんまり恩恵なかったりするんですが、自分で構築しなくてもサクッとReactが使えてビルドもやってくれる環境があるよっていうのは体験として良かったです。create-react-appという手もありますが、ejectした後の整理が大変すぎるので仕事では使っていません。
GraphQLを使うとなるとGraphQLサーバ立てて、そのサーバーにリクエストを投げて、だと思ってるんですがGatsbyの場合は内部でやってくれるのでqueryを書けばいいだけです。まあ静的サイトつくるのにGraphQLサーバ立てなきゃいけないってなってたら中々使わないですよね・・・。
※ www.gatsbyjs.org より引用
Gatsbyにはプラグインの機構があります。公式ページのプラグイン一覧からつなぎこみたいデータソース用のプラグインを探したりするのですが、今回繋ぎこみたかったデータソースに関するプラグインは全部ありました。この辺の開発は結構盛んなのかな？と思いました。
接続情報を設定するだけでGraphQL経由でデータを取得することができるようになりました、とても便利です。あとはgatsby-plugin-typescriptを入れてTypeScriptで書けるようにしたりなどでプラグインを導入しました。
$ gatsby build して成果物をS3の静的ウェブサイトホスティング用のバケットなどのストレージサービスに置けばデプロイ完了です。AWSならCodeBuildを使えば自動化も簡単です。
version: 0.2 phases: install: runtime-versions: nodejs: 10 pre_build: commands: - npm install build: commands: - npm run build - aws s3 sync ./public s3://{YOUR_BUCKET_NAME} --delete --acl "public-read"
静的サイトなのでバックエンドのパフォーマンスチューニングは基本不要です(とはいえ重いQuery書くとビルドは遅くなるのである程度は気をつけていますが)。Reactの実装だけ気をつけていればそうそう遅くはならないと思います。
データ更新が頻繁に行われる、リアルタイムにデータを取得したい、などの要件がある場合は使わないほうがいいです。その条件でReact + SSRを実現したいならNext.jsかなーと。Gatsbyの場合、データ更新=再デプロイ(再ビルド)になります。ReactDOM.hydrate() してクライアント側で動的にごにょごにょするとかも出来ますが、もうそれGatsby使わなくてよくない？感がすごいので・・・。データの更新が頻繁でないコーポレートサイトやブログなどとの相性はいいと思います。
Gatsby Node API(ビルド時に動作するスクリプト)を理解するために結構時間をかけました。動的なページの生成、GraphQLスキーマ周りのカスタマイズなど、中身が盛りだくさんかつGatsby独自の仕組みも結構あるので、調べて→動かして→実行結果を確認して、を繰り返しました。慣れれば楽ですが慣れるまでが大変なヤツです。今回は複数のデータソースから取得したデータのマージやページ生成を行うための事前データの取得など、色んなロジックが絡んだためその分複雑になってしまったかな、という印象でした。コンテンツがシンプルなページをつくるのであればそもそも深くまで知らずともサクッと構築できると思います。
ビルド時間の大半がGraphQLスキーマの構築とページの生成で持っていかれるのですが、外部データを取得したりページ数が増えてきたりして、現状は2分くらいかかっています。JSのビルドにしては遅いよね〜ってくらいなのでデプロイ全体で見ればまあそんなに遅い訳ではないかも？とは思いますが、長い目で見るといくらビルド処理全任せしているとはいえ、コード書く側もちゃんと気を遣わないとね〜といった感じでした。
S3 + CloudFrontの構成に加えてimgixという画像配信に特化したCDNを利用しています。WebPへの自動変換や画像のリサイズなどをQuery Stringで指定できるので、画像周りのパフォーマンス改善が簡単にできました。imgixに関しては@shnagaiさんの下記の記事が参考になると思います。
Gatsbyの仕様を噛み砕いたり、実装する際に詰まった部分など残したりするために使っていたメモをScrapboxで公開していますので読んでみてください。本記事の社内レビューで「おまけの方が技術的には本編感ある」と言われたので多分こっちのほうがより具体的だと思います。
コネヒトではエンジニアを募集しています！家族向けサービスをつくりたいエンジニアの皆さん、お待ちしています。 www.wantedly.com
こんにちは！MLエンジニアの野澤（@takapy0210）です！
気づけば2019年の営業日も残り20日強ですね。年始に立てた個人的な目標が1/5しか達成できていないことに先日気付いたので、残りの期間で1つくらいは達成できると良いですね、という他人行儀な振る舞いをしたくなっている今日この頃です。
さて今回は、11月5日に開催した(コネヒトマルシェ)でLTした内容の全文書き起こしです。参考資料とあわせてご紹介できればと思います。
全文書き起こしは初の試みなので「ふ〜ん。なるほど〜」ぐらいのお気持ちで見ていただければと思います。
発表資料はこちらです。
Kaggleとは
Kaggleと書いて「カグル」と読みます。日本でも最近は定着してきましたが、Kaggleに参加している方を「カグラー（Kaggler）」とも呼びます。
「The Home of Data Science & Machine Learning」（データサイエンスと機械学習の家）と題されている通り、世界中の機械学習・データサイエンスに携わっている約40万人の方が集まるコミュニティです。最大の目玉とも言えるのは「Competetion（コンペ）」です。
https://www.kaggle.com/
SIGNATEとは
日本版Kaggleというのが一番わかりやすく、特徴としては、開催されるコンペティションのデータは日本の企業から提供されています。コンペティションで高順位をとると、後日表彰式および報告会という形で呼ばれることがあり、入賞すると、賞金が出ます。
https://signate.jp/
（会場の9割強の人が挙手）
参加したことある方に聞いてみたいのですが、特徴量の管理ってどうされてますか？
最初に、僕の実体験を添えてありがちなパターンを2つほどご紹介できればと思います。
例えば、[A, B, C, D]という特徴量があった時に、これらから[E, F, G, H, ...]という形で特徴量エンジニアリングする、というシチュエーションはよくあると思います。
で、一通り特徴量を生成し終えた後に、実験したい特徴量を指定して学習データを作り、学習させます。
一通り学習を終えたところで、ふとこんな事を思うタイミングがありました。
どのような計算で生成した特徴量か探してみると、これが結構大変だったりします。
特徴量生成場所が見つかっても、他の特徴量から段階的に生成されていたりする場合、この根源を探すのも大変です。（もちろん、特徴量の名前を一目で分かることにしておくことは前提としてとても大切だと思います。）
続いて、2つ目のパターンをご紹介します。
これは結構ありがちだと思います（笑）
で、意気揚々とDuplicateしてnotebookの中身を見てみるとこんな感じになっているんですね。
。。。
お気付きの方もいると思うのですが、特徴量生成処理など、同じ計算を再度行う必要がでてきます。これは本当に無駄だと思っていて、どうにかしないとな〜と思っていました。
また、Duplicateを繰り返していくと、気づいたらnotebookファイルだらけになっていた、なんてこともあるかと思います。
最初は「めっちゃ良いモデルが作れた！」と歓喜していましたが、煩雑なnotebook、特徴量管理により、コンペのモチベーションも低下してしまう、なんてことにもなりかねません。
今回は、上記で述べたような実体験から感じていた課題感を、玄人の事例を参考に少しづつ解消できてきたので、みなさんにも少しおすそ分けできたらと思っています。
題して
「データ分析コンペにおいて特徴量管理に疲弊している全人類に伝えたい想い〜学習・推論パイプラインを添えて〜」
という壮大なタイトル（笑）でお話できればと思っています。
こちらがアジェンダです。
いろいろ書いていますが、「玄人の知恵をお借りして、特徴量管理と学習・推論パイプライン構築に取り組んだ結果、めっちゃよかったよ」という話をします。 あくまで主観になりますので、「こんな方法で取り組んだらよかった！」などありましたら是非教えてください。
まずは簡単に自己紹介させてください。
野澤哲照と言いまして、コネヒト株式会社で機械学習エンジニアとして働いています。
会社などでは「たかぱい」と呼ばれています。
Kaggleしたり、野球したり、ラーメン食べたりするのが好きです。
次に特徴量管理方法についてお話します。
これから発表する特徴量管理については、下記記事を参考にさせていただきました。
参考記事：Kaggleで使えるFeather形式を利用した特徴量管理法 - 天色グラフィティ
まずは「特徴量を列ごとに管理する」「メモファイルを作成する」という部分のイメージを共有できればと思います。
「特徴量を列ごとに管理する」とは、下記のように1つの特徴量をtrainデータ, testデータそれぞれ１ファイルずつで管理することをイメージしてください。
「メモファイルを作成する」とは、上記の特徴量を生成する際に自動的に「この特徴量はこうやって生成したもの」というメモファイルを生成することです。
これだけ見ると結構大変そうに感じる方もいると思いますが、1つのスクリプトファイルを実行するだけで実現できます。
以下で具体的な方法についてお伝えできればと思います。
例えばhoge.pyという特徴量生成用のスクリプトを下記のように用意しておきます。
これを実行すると、「各特徴量」と「特徴量メモファイル」が生成されます。
特徴量のメモファイルを作成する箇所に関しては、難しいことをやっている訳ではなく、生成した特徴量の記述がファイルになければ追記していく、ということをやっています。
この特徴量メモはCSV形式で保存しておくとGithubから参照しやすかったりします。
ExcelやNumbersといったアプリケーションからでも綺麗に見えるので、今回はCSVファイルを採用しました。
新しい特徴量を生成したい場合は、hoge.pyにその特徴量生成処理を新しく記述します。
hoge.pyを実行すると新しい特徴量が生成されますが、この時すでに生成されている特徴量の計算はskipしてくれるので、余計な計算時間がかかることはありません。（もちろん、再計算することも可能です）
特徴量をdataframeに読み込む場合は、読み込みたい特徴量名のリストを生成しておき、下記のように記述すれば指定した特徴量データのみを読み込むことが可能です。
この特徴量管理方法を使って何が嬉しかったかと言うと
特徴量管理をすることで下記のようなメリットを享受することができ、「時間的なコスト」を大幅に削減できたのが個人的にはとても嬉しかったです。
データ分析コンペでは特徴量生成だけではなく、学習、推論にも一定の時間がかかります。
そのような中で、特徴量を管理することで余計な計算時間が減るだけでなく、学習→推論のPDCAも回しやすくなったと感じています。
次に、学習・推論パイプラインについてお伝えします。
こちらに関しては、昨今話題の下記書籍を参考にさせていただきました。
参考文献：Kaggleで勝つデータ分析の技術：書籍案内｜技術評論社
書籍で紹介されているパイプラインを土台に、下記run_nameをprefixとすることで、一貫性のあるファイルやモデル管理を、意識しなくてもできるように工夫しました。
生成されるファイルは下記のようなものになります。モデルや推論結果のファイルは皆さんの想像通りのものなので、それ以外のファイルについて少しご紹介します。
features.txtは今回の学習に使用した特徴量が記載されたファイルです。
また、param.txtは今回の学習に使用したハイパーパラメータが記載されたファイルです。
shap.pngはshapで計算された可視化イメージを保存したものです。これを元に次の学習の勘所を見つけていきます。
logファイルについては、処理過程を保存したもの（general.log）と、モデルのスコアだけを保存したもの（result.log）の2種類あります。
この学習・推論パイプラインを構築して何が嬉しかったかというと
「この特徴量」と「このパラメータ」を使って学習させたモデルに関して、「各タスクに要した時間」と「各foldと最終的なスコア」を意識しなくても管理できるようになったことです。
これにより、モデルの再現性はもちろん、どの特徴量を使うとスコアが上がった or 下がったということも自然と管理できるようになります。
また、shapの計算結果などを出力しておくことで、次の学習時の勘所も掴むことができます。
最後にまとめです。
特徴量管理とパイプラインを構築することで、様々な「いいぞ！」を感じることができました。一定のイニシャルコストはかかりますが、一度構築してしまえば流用できるので、興味のある方は試してみてください！
また、「他にこんな良い方法もあるよ！」といった知見・意見あれば、是非教えていただけると嬉しいです！
ご清聴ありがとうございました！
発表資料全体をご覧になりたい方はこちらをご覧ください。
以上、当日の書き起こしでした。
今後、コネヒトのMLチームとしては推薦システムに取り組んでいく予定です。
取り組みから得た知見など、積極的に発信していきたいと思っていますので、楽しみにしていてください！
よろしければ、今までのキャリア、コネヒトでの業務などをまとめておりますのでこちらもご覧いただけたら嬉しいです。 www.wantedly.com
こんにちは！サーバーサイドエンジニアの @fortkleです！
今回は、先週末に開催されたCakePHPの国際カンファレンスである「CakeFest 2019」に参加してきたのでレポートしたいと思います。
CakeFestはPHPのフレームワークであるCakePHPの国際イベントで、セミナー2日、カンファレンス2日の計4日間に渡って開催されるイベントです。 開催地は事前に投票によって決められており、今回は初めての日本開催となりました。 私は後半のカンファレンスから参加しました。
公式発表はないのであくまで推測になりますが、全体でいうと100名弱ほど、そのうち半分ほどが海外からの参加者という風に非常に国際色豊かなイベントでした。
このような形式のカンファレンスに参加したのは初めてだったのですが、堅苦しい感じとは真逆でアットホームな雰囲気の温かいカンファレンスでした。
今回、微力ながら協賛もさせていただきました。
コネヒトのプロダクトはCakePHPに支えられているものばかりなので、少しでもCakePHPコミュニティの発展を支援できたのであれば幸いです！
カンファレンス1日目の夜に行われたLTを除くセッションについて、すでに公開されている資料をまとめてみたので参考にしてみてください！ ※ 敬称略
特に、José RodríguezさんによるCakePHPのまだあまり知られて機能の発表や金澤さんによる滑らかなCakePHP3への移行についての発表などは知らないことも多くまさに"知見"という印象だったのでまた見返したいと思います。もちろん、弊社CTOの伊藤によるCakePHPではじめるOSSの発表もぜひご覧ください!(宣伝)
※ 一部の資料はCakePHPのSlackチャンネルでのみ共有されていたため当該Slackチャンネルの投稿のリンクを記載します。*1
| タイトル/スピーカー | 資料公開先 |
|---|---|
| Beyond unit testing: How to make your applications more reliable / José Rodríguez | https://cakesf.slack.com/archives/C172CS4TE/p1573354079126300 |
| GraphQL, CakePHP & JWT: A Fast & Secure Redemption from REST Hell / Prosper Otemuyiwa | 諸事情により発表なし |
| Baking with Vue.js / David Yell | https://docs.google.com/presentation/d/1bgilFVNRtvhp9KyCLVWMMKtlS-Q39rx07AXCOpf67G4/edit#slide=id.p |
| CakePHP with Habitat - Build once, deploy everywhere / Graham Weldon | 諸事情により発表なし |
| Building interactivity with websockets / Wim Godden | https://www.slideshare.net/wimg/building-interactivity-with-websockets-191944043 |
| Life after CakePHP / Andrej Griniuk | https://docs.google.com/presentation/d/1Hlrs_T-rZ_7LNy6iQh-S_Ff8Ca6O8HlThYfjg6D8GO4/edit |
| Let's start your first OSS with CakePHP / Sho Ito | https://speakerdeck.com/itosho525/lets-start-your-first-oss-with-cakephp |
今回のCakeFestは、Github上でしかやりとりをしたことがなかったCakePHPのコアコミッターの皆さんと直接コミュニケーションが取れたことがとても貴重な機会でした。
運営の皆様、会場提供してくださったDMM.com様・スマートニュース様、そして当日参加された皆様、本当にありがとうございました。そして、お疲れ様でした！
*1:CakePHPのSlackチャンネルは誰でも自由に入れますし、日本語話者向けのチャンネル#japaneseもあります! 参加方法はこちら https://twitter.com/fortkle/status/1193390451883040768
こんにちは。MLエンジニアの野澤（@takapy0210）です！
11月に入っていよいよ寒くなってきましたね。
寒いといえば、毎朝洗濯物を干すのが辛くなる季節でもあります。
このような季節も影響し、我が家ではドラム式洗濯機のデプロイが検討されています。もしオススメのドラム式洗濯機があれば教えてください！！
さて今回は、先日無事に開催することができました、「Connehito Marché vol.6 〜機械学習・データ分析市〜」の様子や、LTの内容などを簡単にご紹介できればと
思います！
（嬉しいことにLT枠もオーディエンス枠も満席となり、大盛況で終えることができました！）
今回は第6回目ということで「機械学習・データ分析」をテーマとして開催しました。
抽象的なテーマだったため、LT内容含めてどのような方々が参加してくださるのか、非常に楽しみでした！
ちなみにコネヒトマルシェでは毎回テーマを変えており、過去には下記のようなテーマで開催しています。
今回は、下記3つのお願いお伝えした上で、スタートさせていただきました！
by @takapy0210
by @0xb5951さん
www.slideshare.net
by @yu__ya4さん
by @yaginuuunさん
by @shnagaiさん
by @YASU11552288さん
by @TwYamatさん
by @IshizakiYukoさん
by @ml_taroさん
by @ktr_wtbさん
by @hatuninaさん
by @wakame1367さん
今回はお寿司とお酒を手に乾杯しました。
参加者の方々で質問しあったり、LTの感想を伝えたりしていて、終始楽しそうな雰囲気で幕を閉じることができました！
個人的には、Twitter上で知っている人と顔を合わせてお話できたのがとても嬉しかったです！
というわけで、当日の様子をお届けしました！
拙い司会・進行でしたが、最後までお付き合い頂きありがとうございました！
私自身もとても楽しく参加させていただきました！
次回開催時期・テーマなどはまだ決まっておりませんが、今回のマルシェの振り返りを社内で実施したときに「今回盛況だったから、次回も機械学習でいこうよ！（いこう）」という話がチラっとあがっていたので、もしかしたらもしかするかもしれません（笑）
参加していただいた皆さま、ありがとうございました！
また次回のマルシェでお会いできたら嬉しいです！
こんにちは！エンジニアの柳村です。
9月末頃からママリのiOSアプリでWebThread関連のクラッシュが増加し、ときどき爆増するといった事が起こりました。
クラッシュレポートを調べてみると以下の3つクラッシュが多数発生していました。
Crashed: WebThread 0 JavaScriptCore 0x1a583e14c WTFCrashWithInfo(int, char const*, char const*, int) + 20 1 JavaScriptCore 0x1a5d21b3c JSC::Interpreter::prepareForRepeatCall(JSC::FunctionExecutable*, JSC::ExecState*, JSC::ProtoCallFrame*, JSC::JSFunction*, int, JSC::JSScope*, JSC::ArgList const&) + 742 2 JavaScriptCore 0x1a5f808c0 JSC::boundFunctionConstruct(JSC::ExecState*) + 588
Crashed: WebThread 0 JavaScriptCore 0x19407aad4 <redacted> + 20 1 JavaScriptCore 0x1948013dc <redacted> + 746 2 JavaScriptCore 0x194a80b50 <redacted> + 608
Crashed: WebThread 0 libGPUSupportMercury.dylib 0x1d8145fe4 gpus_ReturnNotPermittedKillClient 1 AGXGLDriver 0x1dc7f2ed8 (シンボルが不足しています) 2 libGPUSupportMercury.dylib 0x1d8146fac gpusSubmitDataBuffers 3 AGXGLDriver 0x1dc7f4404 (シンボルが不足しています) 4 IOAccelerator 0x1be209884 IOAccelContextFinishResourceSysMem + 64
見ての通り、どれもなるほどわからんというエラーですね・・・
しかも、アプリやiOSのアップデートとは関係なく急増するという不思議な状況でした。
ママリのiOSアプリではいくつかWebViewを使っている箇所があり、どこのWebViewが原因かをまず洗い出す必要がありました。
ママリのiOSアプリではFirebase Crashlyticsを利用しており、Firebase Crashlyticsだとクラッシュレポートとログが一緒に見れるのでどの画面でクラッシュしたか判断するのに役に立ちました。
調べた結果は起動直後にクラッシュしているユーザーがいたのでトップページのどこかであるということに絞れました。
しかし、トップページにWebViewは使った心当たりはなかったので、XcodeのDebug View Hierarchy を使ってどこでWebViewが使われているか調査しました。
その結果Google Mobile AdsのDFPBannerView内でUIWebViewが使われていることがわかりました。
まずはSDKが古かったので最新(7.50.0)にしてみましたが効果はありませんでした。。
そこでGoogle Mobile Adsのフォーラムを見たところUIWebViewをWKWebViewに変えることができるとの情報が得られたのでやってみました。
以下のようにinfo.plistにgad_preferred_webview というKeyとwkwebview というValueを設定するとWKWebViewに変えることができました。
<key>gad_preferred_webview</key> <string>wkwebview</string>
これをリリースしたところ、多数発生していたクラッシュがWKWebViewにしたバージョンでは発生しなくなりました！
急にWebThread関連のエラーが増えて、Google Mobile Adsを使っている場合はinfo.plistを変更してWKWebViewに変えるとよいです。
UIWebViewはiOS13ではdeprecatedになっていますし、iOS13でUIWebViewでwindow.confirm を使うと挙動がおかしかったりするということも弊社で確認しているので、UIWebViewは捨て去ったほうがよいかと思います。
