defprofile_app_load_timeBenchmark.measure do
system("./bin/rails r '1;'") orraise"error"endend# Warming disk cache, ...
puts profile_app_load_time
3.times do
result = profile_app_load_time
puts result
influx.write_point("cookpad_ci_app_load_time", tags: { app: app }, values: { load_time: result.real })
end
クックパッドでは、テックリードや新卒、インターン、バイトといった肩書きに関係なく、誰もがレビュワー・レビュイーになります。
チームやプロダクトによって開発ルールは少しずつ異なりますが、私の所属する会員事業部では、PR を出したときに GHE やチャットで部内のエンジニアにメンションして、その時にレビューできる人がレビューするという形を取っています。
I first heard about Cookpad back in 2012 when I joined Tokyo Rails Meetup. At the time, Rails was immensely popular in the developer community and many coders, if not working with Rails in their day jobs, would learn Rails and build hobby projects in Rails after hours. I remember being quite impressed by the talks, especially the ones by Cookpad employees. I was amazed by Cookpad's hospitality and willingness to share the event space, the expertise of the staff and even contribute to open source projects. Cookpad was truly the cornerstone of the Rails community for Tokyo.
(A talk at the Tokyo ML event)
Fast forward to now. Machine Learning in general and Deep Learning in particular is the hot topic. I joined Cookpad's newly created Research and Development department as a Machine Learning researcher. Cookpad is, as it was those years ago, a dynamic, fast-paced company with a positive attitude to open source and sharing knowledge, be it recipes, open-source code or datasets for machine learning researchers. I have decided to make it my mission to contribute to the community of Deep Learning researchers in Tokyo by organizing Tokyo Machine Learning Kitchen events. Much like Tokyo Rails, the ML Kitchen events are a place where professionals and hobbyists can get together to share their interests, network and enjoy a good meal.
The focus of ML Kitchen events is networking between practitioners of Machine Learning. You can expect presentations on:
professional or personal ML-related projects
machine learning, deep learning, data science walkthroughs
paper reviews: own or found somewhere
reviews of machine learning frameworks and libraries
really interesting talks about math and statistics
To further facilitate networking, Cookpad provides snacks prepared in the kitchen where the event takes place. This is why it's called "ML Kitchen", by the way. It takes place in a kitchen.
Talks are in English, but it's not a problem to do a talk in Japanese, if the slideshow is in English. We usually have a keynote talk, followed by a snack break and a series of lightning talks. We end the evening with more networking, exchanging of business cards, eating and drinking.
If you'd like to share something with the Machine Learning community in Tokyo, contact me through our group page or meetup or raise an issue in our github repository.
レシピ本の質感と手書き感から連想するイメージが見えたのでそれに合う色を探します。 基準としては「明るい印象を持ちつつ、落ち着きがある」で、前述で決めたデザインとの相性から緑を連想し、彩度低め・明度高めでカラーパレットを作成しました。 最終的にクックパッドのデザインシステムに定義されている Mint #40b2aaが考えていたものと近かったため、カラーパレットとしました。
クックパッドであることが分かる
LPなのでクックパッドであることが分かる要素も重要です。 ここまで考えたデザインがクックパッドらしさと少し離れているなと感じたので、色を足すことにしました。 ここでもクックパッドのデザインシステム Mint #40b2aaと相性の良い Orange #ff9933を選定し、LPデザインのアクセントカラーとして使用しました。
単純に考えれば、サンプルで動いているモデルに基づき、自分たちのデータを使って再学習したモデルをTOCOを使って.tfliteファイルに変換するだけで上手くいくはずです。
ML Kitのサンプルではmobilenet_quant_v1_224.tfliteという重みが量子化されたMobileNetV1が使われているので、とりあえずMobileNetV1の量子化バージョンMobilenet_1.0_224_quantから再学習したretrained_graph.pbを使いfood-non-food.tfliteを作成します。
変換コマンドは以下のものを使用しました。
しかしながら、結果はダメで、サンプルのモデルだけ置き換えると例えばDidn't find custom op for name Dequantizeなどというエラーを吐きます。
これはTensorFlow Lite側で計算グラフのoperationが実装されていないことを意味しています。
operationが無いということで、選択肢は自分で頑張って実装するかサポートされているoperationだけでモデルを作るかです。
そもそもちゃんと動くか分からない状況なので、試すまでのスピードや余計なバグの原因を混入させないという意図で、後者の方法で進めることにしました。
まず試したのは、floatモデルをfake quantizationして扱うという方法です。
ML Kitのサンプルが量子化されたモデルを扱っているのでこれが既存のスクリプトを書き換えずに実行する近道に思えます。
Mobilenet_1.0_224を元に再学習したretrained_graph.pbを以下のコマンドで量子化されたfood-non-food.tfliteに変換します。
これで作ったモデルはエラーは吐きませんが、予測のスコアが[0.7,0.3]辺りをうろついてあまり変化しないという結果になりました。
この結果から推察するに入力の画像の取り扱いや重みがちゃんと入ってるかなどが怪しいところですが、いくつか調べてみても解決法は見つかりませんでした。
ML Kitの世界に行ってしまうとどこに問題があるか（モデル変換にバグがあるのかアプリ側にバグがあるのか）のデバッグが難しいということもあります。
ML Kitはまだβ機能として提供されているので、対応しているモデルのオペレータが少なかったり、
量子化されたモデルを上手く動かす情報が不足していたり、発展途上であることは確かです。
しかし、一度モデルを構築してしまえばオンデバイスで動作させることができますし、Firebase経由でモデルのアップデートも簡単にできます。
E AndroidRuntime: DeadSystemException: The system died; earlier logs will point to the root cause
W System.err: java.lang.Throwable: tname=main - android.os.DeadSystemException
W System.err: at adgh.a(PG:17)
W System.err: at adgh.uncaughtException(PG:20)
W System.err: at java.lang.Thread.dispatchUncaughtException(Thread.java:1955)
W System.err: Caused by: java.lang.RuntimeException: android.os.DeadSystemException
W System.err: at android.app.ContextImpl.registerReceiverInternal(ContextImpl.java:1442)
W System.err: at android.app.ContextImpl.registerReceiver(ContextImpl.java:1394)
W System.err: at android.app.ContextImpl.registerReceiver(ContextImpl.java:1382)
W System.err: at android.content.ContextWrapper.registerReceiver(ContextWrapper.java:609)
W System.err: at ajmt.a(Unknown Source:10)
W System.err: at akmp.a(Unknown Source:117)
W System.err: at akma.a(Unknown Source:12)
W System.err: at akmu.a(Unknown Source:7)
W System.err: at aklm.a(Unknown Source:8)
W System.err: at ajqf.a(Unknown Source:2)
W System.err: at ajpo.handleMessage(Unknown Source:11)
W System.err: at android.os.Handler.dispatchMessage(Handler.java:106)
W System.err: at android.os.Looper.loop(Looper.java:164)
W System.err: at android.app.ActivityThread.main(ActivityThread.java:6494)
W System.err: at java.lang.reflect.Method.invoke(Native Method)
W System.err: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
W System.err: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
W System.err: Caused by: android.os.DeadSystemException
W System.err: ... 17 more
I Process : Sending signal. PID: 3501 SIG: 9
解決策を試行錯誤している中で、最終的にSwiftRenderが助けてくれました。no-windowオプションと合わせてエミュレータを起動した結果、正しくエミュレータが起動し、Espressoのテスト実行も完了することができました。 Configuring graphics acceleration on the command lineにも書かれている通り、これは swiftshader_indirectモードによるエミュレータ起動で利用することができるものでした。このライブラリはOpenGL ESをCPU処理を使い実現するものです。
会員事業部の日高尚美(@natan3)です。
半年前になりますが、クックパッドでは Android ユーザ向けにプレミアムサービスの決済手段の一つとして Google Play 決済を導入しました。
ユーザに新たな機能を提供する前には、何らかの形で開発者側での検証が必要です。
Google Play 決済導入バージョンのリリースは、ユーザのお金を扱うこともあり、不具合が起きた際にサービス全体の信用に関わる、非常にリスクの高いリリースでした。
それに伴い、検証もできる限り万全に行わなければなりません。
そのため、なるべく丁寧にテストケースを作成し、それをもとに検証を実施することで新機能が期待通りに実装されていることを担保しました。
丁寧にテストケースを作成したから、というだけではもちろんありませんが、リリースから半年経った今でも Google Play 決済周りの目立った不具合はまだ見つかっておりません。
テストケース作成前は、Google Play ストアによる決済用システムダイアログが出ているときにブラウザアプリから別な決済手段にてプレミアムサービスを登録したらどうなるのか？
というケースについて考えられていませんでした。
Google Play ストアの決済用システムダイアログが出てから決済処理完了までは、クックパッドではその経過状況を知ることが不可能です。
そのため、残念ながら決済完了時に Google Play の購読情報をクックパッドに送る際に二重課金が起きていることを伝えることになります。
幸いにも既に別で考慮していたケースと同様にユーザに重複課金を伝え、問い合わせを促す画面を表示できるような実装になっておりました。
Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production.
さすがにこれだけのサービスが連携して動いているとどこかで発生した障害がどこまで影響するのか把握するのは容易ではありません。
A というモバイルアプリが叩いている B という API の裏で通信している C が必要としているデータ取得のための D のレスポンス時間が遅くなって、結果として A の応答が悪くなったのだが、原因が D だとは思っていなかった……的な事も発生します。
何故やるのか
上記ブログのマイクロサービス導入背景にもありますが、昔のようにひとつの巨大なアプリケーションを運用するようなスタイルではプロダクト開発の規模の拡大やスピードに限界があり、マイクロサービスアーキテクチャを採用するようになりました。分散システムとして Web サービスを実装する事により単一の複雑なアプリケーションからは開放されましたが個々のサービス間の連携は複雑になりました。
2. Choose machine learning over a complex heuristic. (複雑なルールになってきたら機械学習を選択！)
multi-label problem 対応で、1つのカテゴリーに相応する1つのバイナリ分類器を作りました。例えば、「ポジティブ」カテゴリーは ポジティブ-or-not 分類器になります。最終的にデータが少なすぎるカテゴリーを除いて合計 81 の分類器を作成しました。将来もしカテゴリーが増えたら、そのカテゴリーに相応する分類器を作れば良いので、open set problem も対処できます。
imbalanced data problem （負例が正例より圧倒的に多い）に関しては、正例はそのままにし、負例は正例と同数になるように無作為に選びました。
3. Keep the first model simple and get the infrastructure right. (シンプルなモデルを保ち、インフラを適切に保つ)
また、学習モデルの精度を上げるために、再学習の仕組みを導入しました。選択されていない「もしかしてカテゴリー」は学習の負例となり、Rundeck/Jenkins で毎週定期的に training コンテナを起動し、モデルを再学習しています。新しいモデルができたら、inference コンテナがそのモデルに切り替えるように設定します。仕組みは以下のイメージです。
ビンテージキーボードが好きで、以前はIBMマシンで使用されていたバックスプリング式キーボードを使っていました。60%くらいのコンパクトさで自分好みのキータッチのキーボードを作ろうと思い、CHERRY軸を触ってみたのですが自分にはしっくりこなかったので別のものを探していました。その中で、80〜90年代に生産された多くのキーボードに使用されていたAlps軸が気になりました。特にサーモン(ピンク)軸が気になったので、サーモン軸を使っている Apple Extended Keyboard をオークションで購入し、解体してキースイッチを取り出し自作してみました。
