Client-Side Deep Learning (LT) | try! Swift Tokyo 2017 #tryswiftconf Day2-13 聞き起こし

twitter.com

iOS 10よりMetal Performance Shadersフレームワークに畳み込みニューラルネットワーク(CNN)のAPIが追加され、iOSバイスGPUを利用して高速にCNNの計算を行えるようになりました。つまり「ユーザの手元で」「オフラインでも」昨今の進化がめざましいディープラーニングの成果を利用できるようになったのです!本LTでは実装のオーバービューと、デモをお見せしたいと思います。

Client-Side Deep Learning

f:id:niwatako:20170303172041j:plain

f:id:niwatako:20170303172042j:plain

f:id:niwatako:20170303172046j:plain

f:id:niwatako:20170303172053j:plain

f:id:niwatako:20170303172055j:plain

f:id:niwatako:20170303172059j:plain

強力なコンピューターでやるとイメージされるかもしれません。モバイルデバイスは貧弱だと思うかもしれません。

それはその通りです。学習は強力なマシンで行い、そこで作った学習パラメータをiPhoneに私、MPSCNNで実行できるようになったということが、iOS10で出来るようになったことです。

学習はTensorFlowでもChainerでも良いし、ファイルフォーマットはなんでも良いです。

f:id:niwatako:20170303172232j:plain

クライアントサイドでやると何が嬉しいのか?

60fpsでやりたければ負荷がかかるのでクライアントサイドで処理できることはメリット。

f:id:niwatako:20170303172305j:plain

4分ぐらい話したが、ここまで来て、CNNが何かとか、Deep Learningとはなにかとか、そういう話はLightningTalkなのでできないが、自動運転ができているとか、AlphaGoが囲碁チャンピオンに勝ったとか、医者より精度を高くガンを見つけられるとか、そういう画期的な話を皆さんも聞いたことがあると思います。

f:id:niwatako:20170303172442j:plain

f:id:niwatako:20170303172444j:plain

f:id:niwatako:20170303172446j:plain

f:id:niwatako:20170303172448j:plain

f:id:niwatako:20170303172450j:plain

とにかく、何かすごいものがiOSで動くようになったんです!!!

デモを作って来ました。

f:id:niwatako:20170303172540j:plain

f:id:niwatako:20170303172542j:plain

去年の try! Swiftの名札があるのですが、、、

f:id:niwatako:20170303172617j:plain

おっと。。。手が震えて認識できません。。。。。

f:id:niwatako:20170303172619j:plain

(会場歓声)

以上です。ありがとうございました!

オープンソースコミュニティをスケールさせる | try! Swift Tokyo 2017 #tryswiftconf Day2-14 聞き起こし

twitter.com

オープンソースプロジェクトのさまざまな段階についてお話しします。どのようにプルリクエストを処理するか、規模に応じてどのようにサポートを変えていくか、ユーザー数が拡大していく中でどのように革新を起こしつづけるかをお話しします。 それらを念頭に置き、開発者がどのように問題を解決するのか、具体的にはワークフローの自動化、コントリビュータとの密接な関わり合い、プロダクトやドキュメントの改善について詳しく説明します。 おととしfastlaneで多くのことを学びました。オープンソースコミュニティのスケーリングについていくつかブログを準備しはじめました。

オープンソースコミュニティをスケールさせる

f:id:niwatako:20170303172829j:plain

Twitterで仕事していてFastlaneを担当しています。

fastlaneミートアップが有りましてカッコいいTshirtを入手しましたありがとう御座います。

f:id:niwatako:20170303172913j:plain

Googleのサイドプロジェクトとしてfastlaneに着手しました。

0から立ち上げて何万というユーザーになりました。OSSの段階をお話します。

f:id:niwatako:20170303172941j:plain

Githubの40%はインタラクションがありません

プルリクエストなどが来るようになります

f:id:niwatako:20170303173006j:plain

Twitterで推奨されたりカンファレンスで発表されたりします

f:id:niwatako:20170303173019j:plain

f:id:niwatako:20170303173055j:plain

私はラッキーで4つの段階を経験できました。2年間いろんなことを学びましたが人間的な要因について学ぶことができました。

インパクトを与えるか、どうサポートできるか。

f:id:niwatako:20170303173141j:plain

大きくなると初期のイノベーションが難しくなります。

機能を変えたりデフォルト値を変えたりできなくなります。

f:id:niwatako:20170303173204j:plain

プロジェクトの仕事よりもユーザーサポートの時間。テキストエディタよりユーザーに2倍向き合っているということを表しています。

f:id:niwatako:20170303173233j:plain

GithubのIssueをクローズすると文句を言われるので別のサイトを用意したほうが良いかもしれません。

f:id:niwatako:20170303173309j:plain

f:id:niwatako:20170303173320j:plain

f:id:niwatako:20170303173332j:plain

くだらない、ビジョンに合わない要望を断る際に、正当化出来る必要があります。

f:id:niwatako:20170303173339j:plain 壊れたら自分が治すことになります。Issueをレビューすることはコードを書くのと同じくらい考えます。

f:id:niwatako:20170303173427j:plain

メンテナーがユーザーではなくなってしまう事が起きます。

ここでのチャレンジは何らかの形で困っていることを肌で感じ、期間配分をすることです。

f:id:niwatako:20170303173516j:plain

たまに利用するようにしましょう。

f:id:niwatako:20170303173527j:plain

Issueは多くのIssueの中の1つです。しかしユーザーにとっては自分のすべてです。

WWDCでしばらく前のIssueについて話をされたのが最初の体験でした。

f:id:niwatako:20170303173617j:plain

まずエラーメッセージを改善することです。どんなに優れたソフトでもクラッシュはあります。エラーをどう表示するかが大事です。

Fastlaneでは異なる2つの表示をしています。

最初はStackTraceをすべて表示していましたが、これは情報が多すぎたようです。

f:id:niwatako:20170303173656j:plain

エラーメッセージを赤で表示し、StackOverFlowへのリンク、再現するコマンドを表示しました。

f:id:niwatako:20170303173712j:plain

次は簡単に問題を得られるようにすることです。

エラー発生時点で解決方法を見つけられるようにすべきです。

f:id:niwatako:20170303173812j:plain

これによってユーザーは簡単にGithubの情報を探せる。

私はボットなどは好きではありませんが、規模が大きくなると何らかの方法で自動化が必要です。

f:id:niwatako:20170303173832j:plain

バグレポートはソフトウェアエンジニアでもすべての情報を適用することは難しいです。

ユーザーがIssueを報告する時かなりの情報が欠落しています。

必要な情報がもれなく表示されるようにします。

そうでなければ入手方法が分かるようにしています。

f:id:niwatako:20170303173942j:plain

f:id:niwatako:20170303173948j:plain

似たようなIssueが来るなら根本的な問題やドキュメントを改善します。

10のユーザーがIssueを出すと多くのユーザーが同じように感じているのかもしれません。

Appleでしか解決できないCodeSiginingについての問題にガイドを書きました。

Issueをとにかく前にすすめることが大事です。

Appleのバグレポートで2年後に最新のOSを使えと言われるだけならイライラするでしょう。

f:id:niwatako:20170303174121j:plain

応答がない場合はもう必要なくなっているかもしれません。

f:id:niwatako:20170303174142j:plain

Issueに2ヶ月変更がないと、問題が完了しているのかボットが聞いてきて、誰も何も言わないとIssueがクローズされます。さらにその1ヶ月後にはロックされます。

何故ロックすべきか。

古いリリースのものからIssueが出てくることを避けることができます。

全く関係ないことを言ってきたり、不要なemail通知を発生させてしまったり。

f:id:niwatako:20170303174321j:plain

bot導入で700から300にOpenチケットを減らすことができました。

f:id:niwatako:20170303174327j:plain

大半のIssueはCIが前テストが合格していることをチェックしているが、テストだけでどのようにして変更が入ったかわからないわけです。Ortaを使うことであるファイルが変わった時にWarningを出すとか、20のコードラインが入ったならテストを要求することができます。

誰かがPullRequestを出す、ビルドがうまくいかない、AuthorがPRをアップデートしない、TestがFailしたら通知が行かない http://Danger.systemを使うことで解決できる。

f:id:niwatako:20170303174524j:plain

大きなOpenSourceプロジェクトではVision.comを使ってビジョンを共有するようにしている。 コミュニティが増える、ということに安全な環境が必要です。コーディング規約が必要です。mono repoでなければすべてのリポジトリと依存性に問題がないかチェックをしています。

コードベースが複雑になるほど貢献できる人も少ない。

できるだけフレンドリーに、IssueやPRにはまず感謝を伝える。多くのフィーチャーやアイディアにNoと言わなければならないが、ユーザーがソフトを拡大できる様々な方法を取ることができます。CocoaPods, Bundlerなど。

f:id:niwatako:20170303174741j:plain

f:id:niwatako:20170303174742j:plain

StaticなValueを使うとか、Webサービスなどの外部の絵ソッドを利用できる

拡張時にコードに触ること無くやることが有ります。

デベロッパーのコミュニティを大きくしてプラグインで拡張できるようにします。

本体がスリムになってPRも減るかもしれません。そしてすでにある依存性を排することが出来る。

OSSの拡張は難しくいろいろな課題がある。

問題に対処しなければいけないのは一人の人ではなく多くの人が助けてくれる。

コミュニティなしでは今の状況は作れませんでした。

長く続くOSSもあるので、全世界のデベロッパーにインパクトを与えられます。

Q&A

メンテナンスしていないライブラリは有りますか?そういうものはどうしていますか?

宣言して、だれかにメンテナンスを引き継ぐ。透明性を持って引き継ぐ。

チームの生産性を改善するために決断疲れを最小化する | try! Swift Tokyo 2017 #tryswiftconf Day2-12 聞き起こし

チームの生産性を改善するために決断疲れを最小化する

twitter.com

ソフトウェアエンジニアとして、私たちは書いているコードの1行1行ごとに決断し続けています。 これに必要な時間とエネルギーの量はチームが生産的に働けるか、あるいは停滞させてしまうのかどうかを決定します。このトークではSwift開発における決断疲れを最小化し、チームの効率と同時にコミュニケーションとコラボレーションを改善する方法についての個人的な経験を共有します。

チームの生産性を改善するために決断疲れを最小化する

f:id:niwatako:20170303164100j:plain

Pivotal Labでの働き方

動やったら精神的な決断疲れを減らせるか、実際にやっている方法をお伝えします。

f:id:niwatako:20170303164202j:plain

f:id:niwatako:20170303164203j:plain

f:id:niwatako:20170303164206j:plain

プログラマはキーを打つ度に決断をしています。

タブ?スペース?Viewはどう書く?条件は?ライブラリは使う?CocoaPods?Carthage?

ちいさなことのように思えるが、しかし精神的に集中しないと決定できません。

そのために難しくなります。オプションの中でも最も努力のいらないものを選んだり、意思決定を限定的にしかみない、あるいは選択を避けることが有ります。これを決断疲れといいます。

我々はチームでコミュニケーションして決定します。

ここのアプローチがたまたま合致することはない

やろうとしなければ出来ない。結果だけ伝えるみたいになってしまう。そうすると疲労につながります。

f:id:niwatako:20170303164412j:plain

思わぬところに影響を及ぼすコードを書いたりしてしまったりします。

どうやって重要な決定にエネルギーを向けられるでしょうか

f:id:niwatako:20170303164442j:plain

意思決定をシンプルにすることで開発効率を高められると思います。

そのような疑問に答えるためにコンテキストの中で考えてみたいと思います

どうやって私たちは日常を送っているか

全てカバーしていきます。あらゆる決定が精神を疲れさせます

まずは朝ごはんをどうするかの決定が必要です。PivotalLabではそれは必要ありません。提供されるのでチームメイトと話すいい機会です。

9:06に朝礼を行います。新しいメンバーやお客さんの紹介、ヘルプの申し出、興味深いニュースが話題になります。

f:id:niwatako:20170303164615j:plain

その後プロジェクト向けの朝礼を行います。昨日何をして何が起きて今日何をするか。

非常に時間がかかったか、どこにリポジトリを入れるか決めるのが大変だったという話がありました。そしたら話し合ったほうが良さそうですよね。他のエンジニアもやはり同じ懸念を抱いていてそうだねという話になった。

f:id:niwatako:20170303164706j:plain

どこにファイルを置くべきか

f:id:niwatako:20170303164717j:plain

何を探しているか分かっていればファイル名やファイルナビゲーターで探していく、検索ができます。

f:id:niwatako:20170303164748j:plain

ファイルが置かれた場所は何故そんなに大事なのでしょう。

知らないプロジェクトを触るときは探し回ることになるわけです。ずっと長い時間を費やすことになります。思うより。

一定の組織化が必要ということになりました。

全く組織化しないことは、無いなという話に。

Helper, Utilはあまり何が入っているかの助けにならない。

MVCを使ったら?という人もいました。でも他の人も懸念を示しました。MVC概念に一致しない場合困ってしまうよね、それだけではダメだという話になりました。

Applicaiton、 Component, UIでフォルダを作りました。 テストも同じ形にしました。 ただResourceフォルダにはテスト関連のものだけが入ります。

f:id:niwatako:20170303164946j:plain

AppDelegateやMain.swiftは普段触らないので邪魔ですよね。

本当に作業が必要なものを集めます。

ComponentoはComponent毎にフォルダを分けました。モデルのようなものだと考えています。

f:id:niwatako:20170303165029j:plain

レストランリポジトリオブジェクト、パーサーオブジェクト、Presenterも使われますね。

UIは

f:id:niwatako:20170303165105j:plain

DelegateやDatasourceで関連したものがあればそこに入れていきます

予見性のある形でいれていくと、いちいちどこに入れるかで困らなくなります。そうすると決定要素が一つ減ります。

f:id:niwatako:20170303165141j:plain

エクストリーム・プログラミングテスト駆動開発、そしてペアプログラミングをやっています。

ペアプロはやったことはあるよと思っていましたが、Pivotalでやると、だいぶこれまで経験したものとは違うものになりました。

f:id:niwatako:20170303165227j:plain

キーボードと27インチディスプレイ。どちらの人もドライビングしていくことが出来ます。

一連のIndexカードがあります。いろいろな話をしたりダイアグラムを書いたりに役立ちます。

f:id:niwatako:20170303165303j:plain

ピンポンプログラミングの方法

テストコードを書いた人同士が交代で書く

f:id:niwatako:20170303165321j:plain

ナビゲーター・ドライバー

熟達者がナビゲーターとなってドライバーがコードを書く。教育に役立ちます。

f:id:niwatako:20170303165351j:plain

できるだけこのペアが一緒にすることが重要です。エンジニアやデザイナ、PMもペア位になります。毎日ペアを変え、仕事を変え、チーム全体でコードベースを共有します。

色々なトピックがあるがベネフィットとしてはすぐにフィードバックが帰ってくる。そしてすぐ意思決定を行えます。

f:id:niwatako:20170303165502j:plain

ケータリングランチを食べます。だれかがプレゼンをしたり、動画を見たりします。

この日はObjc-ioの方をお招きしました

昼食後またプログラミングを続けます。

プランニングのミーティングがあることもあります。

f:id:niwatako:20170303165646j:plain

f:id:niwatako:20170303165657j:plain

ViewControllerを開いて新しいUIオブジェクトなどをどこに置くでしょう

Ctrl+6を押してナビゲーションをまずみます。

セクション化や共通パートを定義したりしていきます。

アノテーションなし→MARKありセパレーションなし→Markとセパレータ

f:id:niwatako:20170303165824j:plain

f:id:niwatako:20170303165833j:plain

プロパティ、ViewElements, initialization, Lifecycle, Privae methods,,,

f:id:niwatako:20170303165907j:plain

ViewControllerのボイラープレートをXcodeスニペットに登録している。

ぱっとテンプレートを使って自動化します。

プロトコル遵守も重要なトピックです。

f:id:niwatako:20170303165955j:plain

f:id:niwatako:20170303170019j:plain

MarkをつけてExtensionに切り出し、プロトコルに属するものであることを示す。

このように共通の形で組織化すると何がどこにあるかわかりやすくなる。新しく書くべき場所も分かりやすい。

f:id:niwatako:20170303170109j:plain

休憩はダブルスで同じようにペアで卓球、インフォーマルな関係を作れます。そして全く違うことをすることでリフレッシュします。

ペアプロは異なる担当でエンジニア・デザイナのペアなどもやる

f:id:niwatako:20170303170215j:plain

スタイルガイドはデザイナから提供されています。それらを実装し再利用する。

f:id:niwatako:20170303170242j:plain

UIColor の Extensionでカラーを定義しています。

f:id:niwatako:20170303170301j:plain

ボタンも定義されます。 ボタンをパラメータとしてとって、それぞれに適切な設定を行います。

UIButtonに対して適用していくことが出来ます。同様にViewやLabelにも。

f:id:niwatako:20170303170348j:plain

f:id:niwatako:20170303170355j:plain

ViewControllerがロードされると呼び出されます。

新しいスタイルを適用する時にどうしたら良いかわかります。

f:id:niwatako:20170303170422j:plain

チームメンバーのみで行います。

f:id:niwatako:20170303170503j:plain

マネージャーもステークホルダーも居ない場でチームメンバーだけで話します。お酒を飲むこともあります。

特に感情を取り扱います。この1週間どう思ったか。

f:id:niwatako:20170303170537j:plain

感じたことを書き込みます。ファシリテーターはボランティアです。

アクションアイテムは翌週取り組んでいきます。継続改善を反芻する、チームビルディングに重要です。

f:id:niwatako:20170303170627j:plain

問題が大きくなる前に解決する。

f:id:niwatako:20170303170643j:plain

Extream Programingの中でケント・ベック

真実を話すことで信頼が醸成される。

我々もふりかえりの中で信頼を醸成していきたい。

これらを実行することが重要です。

f:id:niwatako:20170303170718j:plain

意思決定の合理化は今も将来も一人でもチームでも重要です。

ベストな答えではないですが選択肢として。よりシンプルに出来るならどうすればより効率化出来るか考えてみて下さい。

意思決定をする場面でそうした意思決定が何回も反復されるならば同自動化出来るか簡素化出来るか考えてみて下さい。

個人、チームの意思決定が減り、チームのリソースをより重要な意思決定に向けられます。

f:id:niwatako:20170303170902j:plain

f:id:niwatako:20170303170904j:plain

f:id:niwatako:20170303170905j:plain

f:id:niwatako:20170303170910j:plain

Q&A

バランスの質問です。働いている時の快適さがあると思います。快適に感じる必要があります。(???)いろいろな修正が必要だったり2人でやることが必要化コスト化みたいな??

ペアプログラミングはユニークだと思います。人との関係で言うと非常に集中が必要である、好みのキーボードがある、好みのIDEを使うという人もいる。自分ではやっていないことを人から学ぶことが出来る。キーボードのショートカットなども。

チームに関して共感を得ることが出来る。

この人の他のメンバーが使うツールは自分の知らないアドバンテージが有るのかなと思うことが出来る。そうした学習を続けられることがいいことだと思う。

自分の好みを犠牲にしてももっといいものを見つけたり、気に入っているものを伝えられる。

私はリモートで働いていますがペアプログラミングが難しい。リモートで働く上で良い案はないでしょうか

ペアプログラミングをリモートでやるのは難しい。ペアプログラミングの昔ながらのスタイルは1台を共有して一人が入力、あるいは複数キーボードを使う。

適切な機器を持ってペアプログラミングをすることは一つの重要な要素だと思います。Skypeを使ってペアプログラミングをしている人は居ます。ただ可能であれば経験を得ていただきたいなと思います。ソーシャルな側面があります。

私はリモートで働いたことが有ります。その時は寂しかったです。FacetimeSkypeも試してみてはいかがでしょう、でも生身で出来るのが一番だと思います。

ちょっと不思議に思ったのは奇数の開発者が居たらどうしますか?

奇数の開発者ということも有りますよね、一人は残念ながら残されることになります。GetDoit?というツールを使っています。GetSoloというオプションが有ります。今の時点では午前と午後で分けています。ペアリングの頻度を変える。 そして正しい方向を探す必要がありますが、Backlogでちょあーず:探索や小さな仕事をする人たちですが、そういったタスクをすることになります。病気や休暇もあると思うのでそのような方法を試みます。