droidcon SFのレビュー

こんにちは、Habr！ 私の名前はAlexander Kolobanovです。FunCorpのAndroidチームリーダーです。 11月、私はサンフランシスコのドロイドコンにいました。 カットの下で、会議の小さなレビュー、旅行メモ、いくつかの写真。

なぜここまで飛ぶのですか？

Droidconカンファレンスは、アメリカだけでなくヨーロッパでも開催されています。 そこを飛ぶのはどんどん安くなりますが、私の経験からすると、地理的な場所が決まると言えます。 会議がGoogleや他のトップIT企業の本社に近いほど、有名なスピーカーが参加する可能性が高くなります。



さらに、さまざまな主催者がさまざまな場所にいて、名前だけがそれらを結び付けます。 したがって、各都市を個別に調べる必要があります。 私の意見では、droidcon NYCは一般的にシルクハットです。 欧州からは、組織の質とレポートのレベルに関する価値のある会議であるdroidcon Londonに言及します。 ヨーロッパのAndroid開発者にとっては、おそらくそれが主なものです。 私も訪れたベルリンとウィーンのdroidconは、初心者や中級レベルの開発者により適しています。それらについての著名なスピーカーや筋金入りのレポートは非​​常にまれです。



droidcon SFとロシアの対応品を比較すると、主催者は食べ物（コーヒーもあります）や参加者の利便性などについてあまり考えません。 そこにたどり着くための詳細な計画をだれも送ってはいません。会議がもうすぐ開催されるという20のリマインダーは、議論やその他すべてのボットやプラットフォームを作りません。 くっきりした、非常に詳細なナビゲーションとnishtyakovのシックな品揃え。 ここでは、最初の場所（および2番目と3番目）で、技術的な部分とレポートのレベル。 これは、いくつかのレポートがプログラムに漏れることを意味しませんが、一般的に、droidcon SFは、トップエンドのコンテンツと著名なスピーカーのみがいる開発者向けの開発者による会議です。



これらすべてを考えると、サンフランシスコでの会議のプログラムは高いレベルにあったと言えます。 developer.android.comのチュートリアルを改ざんした率直なハックレポートはありませんでした。

交通費およびその他の費用

アメリカは安い国ではありません、そしてあなたが我々の部分から飛ぶならば、あなたが飛行で多くを救うことができるということはありそうにありません。 さらに、誰もが生活のために異なるレベルの快適さを必要としています。



常に有効な普遍的なアドバイス：チケットを取り、宿泊施設を事前に予約します。 割引チケットを探して、販売を詳しく見てみることができます。 このようなことに関する多くの情報は、ウェブサイトやソーシャルネットワークの専門グループにあり、旅行の節約に専念しています。 ミッドレンジの航空会社を検討する必要があります。多くの場合、航空会社は急勾配で高価なサービスを提供しています。 まあ、一般に、大西洋横断では、通常、クラスに関係なく、サービスは全員に対して同じレベルです。 低コストの航空会社は、そのような距離を飛ぶことはありません（おそらくそうでしょう）。 また、フライトのコストは旅行予算の重要な部分であるため、もちろんそのような機会がある場合は、会議への旅行と休暇を組み合わせることをお勧めします。 アメリカには見たりすることがあります。



















州のタクシーは伝統的に高価です。 したがって、アドバイス：公共交通機関または車のプーリングを使用します（これは、同様のルートを旅行し、旅行の費用を分担する複数の人をタクシーが拾うときです）。 都市間では、バスで旅行するか、車を借りることをお勧めします。 市内の駐車場の価格は非常に高く、状況は困難で奇妙です（たとえば、月の第2木曜日の午前8時から午前10時まで駐車することはできません—滞在とカウント）。 。



住宅について話すと、特にサンフランシスコのような高価な都市では、あまり節約できません。 愛好家のために、コーチサーフィンがありますが、残りは同じです-事前に予約してください。







会場



会議は、ミッションベイ会議センターで開催されました。 カリフォルニア大学サンフランシスコ校の建物の1つにあります。 ところで、同じ建物内に、図書館、フィットネスルーム、カフェがあります。 かなり多くの参加者（800人以上）にもかかわらず、十分なスペースがありました。 廊下では時々押す必要がありましたが、ホールには十分なスペースがあり、誰も壁に沿って立っていませんでした。



ミッションベイカンファレンスセンター自体は、市の中心部に非常に近い場所にあります（中心部からタクシーで10分）。 ここで、発言する必要があります。サンフランシスコ自体はかなりコンパクトな都市です。 中心部から空港までは、タクシーで約40分かかります（ラッシュアワーでもう少し）。 したがって、そこにたどり着くための問題は原則として生じてはなりません。 その地域の公共交通機関で唯一のものは非常に複雑であるため、タクシーを利用することを好みました。



会議には2フロアが割り当てられ、それぞれに2つの部屋がありました。大小。 バッジとTシャツが発行された登録は入り口にありました。 多数の参加者がいたにもかかわらず、すべてが非常に迅速に進みました。 バッジを取得するのに数分かかりました。 午前中、基調講演の直前に小さな列ができました。 ところで、Tシャツは、登録時だけでなく、多くのスタンドでもほぼ無制限に配布されていました。 そのように。



登録エリアの後ろには大きなホールがあり、そこから誰もがすでにホールに散らばっていました。 また、スポンサー企業のスタンド（2階にはもっと多く、建物は密集していた）とコーヒーポイントの展示エリアがありました。 ホールから直接、キャンパス内にある小さな公園に行くことができます。 素敵で快適。

組織の瞬間

すべてはきちんと組織されていましたが、ロシアの会議と比べると少し変わっています。 間違いなく、レポートや技術面への注意が減り、注目が集まった。 「食べ物」からはお茶とコーヒーだけでした。 コーヒーブレイク、ケータリング、栄養全般にもっと注意を払っています。 ここでは、温かい飲み物は別として、何もありませんでした。 より正確には、昼食時に彼らはまだコーラの缶で冷蔵庫を運びました。 食べたいなら、角を曲がったところにカフェがあり、そこでサンドイッチを買うことができます。 あなたのためのスーパーケアとハイパーカストディはありません。 ところで、それは標準でした。



昼食自体もかなり名目でした：リンゴ、チップス、そして再びサンドイッチ。 正式に供給されたが、それ以上。 多くの学生が同じ公園のベンチで昼食をとりました。



しかし、組織の技術的な部分に特に注目する価値があります。 WI-FIはキャンパスから開いていましたが、実質的に問題はありませんでした。 スピーカーのセットアップと接続はすぐに、数分で完了しました。 報告中、すべてがうまく機能するように絶えず監視しました。 たとえば、スピーカーが大声または小声で話し始めると、ほとんど瞬時に音を減らして追加しました。 一般的に、私は機器の単一のヒッチと問題に気づかなかった、すべてが最高でした。 すべてのレポートで、マイクがホールの周りに装着されていたが、スピーカー自身が彼らに尋ねられた質問を発話した場合を除きます。



異常から：私は本当に静かな部屋が好きだった。 ただ入って、お茶を飲んで、静かにラップトップと一緒に座って、大規模な会議の騒ぎから休憩できるちょうど部屋。

プログラム

報告書は、ほぼ朝から夜まで、4つの流れで送られました。 サイトは午前8時にオープンし、最初のレポートは9時に始まりました。すべては午後7時ごろに終了しました。 スレッドには明確なテーマがありませんでした。 ほとんどの場合、主催者は各レポートの予想出席者数によってスロットを分配しました。 主なトピックには、CI / CD（過去数年間のほとんどすべてのAndroidカンファレンスと同様）、UIテスト（突然、ほとんど誰も持っていないことが判明しました）、Kotlin（今はどこにいませんか）、アーキテクチャがありますアプリケーション（2人のAndroid開発者を集め、間もなく彼らは「アーキテクチャ」について話す）。 つまり、ここではすべてが非常に標準的です。 基調講演について興味深いことは何も言えません。 彼らは、ほとんどすべての人の電話にあるアプリケーションを作成し、この世界を形作り、人々がその中でやり取りし、通信する方法について話しました。 しかし、私はコメディー（元々コメディーは予定されていませんでしたが）を覚えています。RomainGuyとChet Haaseからのスピーチ。プラットフォームがどのように見えるか。 多くの人が、ハードウェアアクセラレーション、アニメーション、レンダリングに関するGoogle I / Oでのパフォーマンス（非常にクールな）を見ていたと思います。 あなたが見ていない場合、私はそれを強くお勧めします。 最終的なコメディトークについてはあまり話したくありません。冗談を言うのはまあまあの活動です。 自分の目で確かめてください。

上位のレポートを強調しようとすると、純粋に個人的なものになり、私にとって最も興味深いレポートに依存するようになります。 ここにあります：



SlackのValera Zakharovによるゼロからパフォーマンステストパイプラインを構築する方法 。 素晴らしいパフォーマンス、直射。 たくさんの良い実践的なアドバイスと興味深い経験。 サポートする別のチームがない場合、独自のデバイスファームを作成してはならないという事実に関するレポート。 そして、アプリケーションを高速にするだけでなく、コミットからコミットまで絶えず継続し、回帰を許可しないようにすることが重要です。 また、テストが頻繁に「ノイズを発生」させ、無駄になった場合は、少しコストがかかります。すぐに誰もがそれらを無視し始めるからです。



Human Centered API Design 、ピエール・イヴ・リコー、スクエア。 LeakCanaryを作成し、Squareの他の開発者と連携して同様に有名なライブラリを作成します。 彼は人々のために外部APIを作る方法を話しました。 それを直観的にしてください。 そのため、使用する人のエラーの割合を最小限に抑えるために。 優れたレポートは、外部APIの記述だけでなく、一般的な適切な設計方法に関するものです。 ちなみに、アプリケーションのモジュールのAPIも簡単で、可能な限り明確である必要があります。



Snapchat 、Ben Dodson、Gustavo Mouraで未来に向けて構築 -予想外に、しかしSnapchatから。 4歳以上のアプリケーションをどのように作り直すかについては、かなり遅く、人生の中で何度か概念を変えました。 そして今、まず、カメラ、そしてチャット。 そして、あなたがそれを書いたとき、レトロフィットでさえありませんでした。 主なアイデアは、すべてを書き直すために急ぐ必要はないということです。 あなたの優先順位とあなたが望むものを理解し、メトリックを導入し、それらを厳守することは素晴らしいことです。 一部のモジュールは最初から書き直すことができますが。 はい、これは実際、すでに別のアプリケーションであり、何らかの形でユーザーに紹介する必要があります。あるモジュールを別のモジュールに置き換えて、すべてが落ちないようにしようとすることもあります。 実際のイベントに基づいています。



多くの興味深い有用なレポートがありました。 Uberの開発者のストーリー、Out of memoryでどのように戦ったかを強調できます。 多くの場合、リークや大量のメモリ消費だけでなく、多数のスレッドが発生します。 結局のところ、各スレッドは、たとえば、スタックの下に自分自身のメモリを割り当てます。 いくつかのスレッドも悪い：スレッドの不足のために相互に依存しているタスクは、スレッド枯渇デッドロックに入ります（あるタスクが別のタスクの結果を待機し、実行中のスレッドが不足している場合を状況と呼びます）。 この状況から抜け出す方法は非常に簡単です。アプリケーション全体でマルチスレッド化のために1つのツールを使用し（Rxを選択）、それがどのように機能するかを理解します。 たとえば、Rxの場合、スケジューラーの違いを調べます。



Facebookの開発者は、Spectrumを操作するための新しいライブラリを発表しました。 伝統的に、FacebookライブラリはMozJPEGを含むネイティブコードを使用します。MozJPEGはJPEGの最高のコーデックの1つです。 コーディング、圧縮、最適化、さまざまな変換の追加が可能です。 一般的に、かなり興味深い機能であり、それ以前は使いやすい形式で見つけるのは非常に困難でした。



Advanced Kotlinと呼ばれるKotlinについてのレポートから、Kotlinの上級者であることがわかります。インフィックスとtailrecが何であるかがわかっていれば、ジェネリック型のインとアウトを区別し、whereクラスとシールクラスを知っています。 まあ、あなたはラムダでのDSLの類似性を構築することもできます。



TinderとNetflixからのUIアーキテクチャに関する良い報告もありました。 前者は、いわば、アクションを通じて切り替えられる状態にリアクティブUIを作成し、このためにアーキテクチャコンポーネントのLiveDataとViewModelを使用します。 後者は独自のコンポーネントを作成し、ロジックの一部をビューとともに囲み、イベントバスの実装を介してそれらを接続しました。



したがって、多くの優れたレポートがあり、注目に値するそれぞれの言及には、おそらく数十ページかかるでしょう。 率直に言って悪いレポートではありませんでした。 しかし、個人的に、私は写真に関するロマン・ガイの報告が好きではありませんでした。 アプリケーションから写真を撮る方法についてでさえなく、単に写真の理論についてです。 もちろん彼は尊敬されている開発者ですが、写真コースではなくAndroid開発に関する会議にお金を払っています。

ネットワーク

そのため、スピーカーまたは少なくとも特別なゾーンとのコミュニケーションの余地はありませんでした。 スピーカーは、原則として、プレゼンテーションが聴衆からの質問に答えた後、「最後までここにいる-キャッチ、アスク、うれしい」というスタイルで、非公式にさらなる会話に招待しました。 しかし、ニュアンスがあります。 講演者の出身であるほとんどすべての企業には、講演者だけでなく、会社の他の開発者も参加しているスタンドがあったので、関心を持って質問することは問題ではありませんでした。 そのため、スタンドは面白く、時には非常に活気がありました。

誰がdroidcon SFを訪れるべきですか？

このカンファレンスは、有名な開発者の応用レポートを聞き、そして誰にどのように、そして何が効果的かを個人的に尋ねたい人のために訪問する価値があります。 雰囲気はとてもオープンでフレンドリーです。 しかし、経験の少ない人には会議に行くことはお勧めしません。 レポートは非​​常に複雑で、会議のペースは非常に速いです。 1日8回の講義は厳しいです。 たとえば、Slackはスタンドにサバイバルキット（ビタミンと頭痛薬の入ったバッグ）を配りました。 そして、ご存知のように、すべてのジョークにはジョークのほんの一部しかありません。 さらに、少なくとも今回は、プログラミングに関するだけでなく、インフラストラクチャ、独自の経験、および実践に関するトピックも多くありました。 したがって、チームリーダーと開発マネージャーは、droidcon SFで自分に適したコンテンツを見つけることもできます。



CI、テスト、およびそれに関連するすべてのトピックはまだ生きており、非常に関連性がありますが、QAおよびDevOpsエンジニアに行く価値があるかもしれません。 ところで、私の興味深い観察結果の1つです。代表された企業では、彼らはエンジニアについて単純に話すことが多く、開発者、テスター、インフラストラクチャに分けていません。 これは、多くの人が役割を変更でき、開発者として、たとえばインフラストラクチャチームに参加できるという事実に表れています。 なぜ、まだエンジニア。

一般的な印象

全体的な印象は非常にポジティブです。 弱いレポートを期待していましたが、「ウォークスルー」はほとんどありませんでした。 原則として、ケータリングを手配する準備ができていました。 言われたことすべてを理解するのに問題があるかもしれないと思っていましたが、ほとんどのスピーカーははっきりと話し、実際には加速しなかったので、原則として問題はありませんでした。 アクセントに慣れるまで少し時間がかかることもありました。 そして、技術組織と非公式のコミュニケーションは明らかに期待を超えていました。 そして、これは私の意見だけではありません。 ホールとレポートの間のスタンドで、多くの興味深い議論がありました。











PS以下のリンクは、ブログからの他の外国会議のレビューです。

droidconウィーン

アトラシアン

ドロイドコンロンドン

後藤ベルリン

Webサミット