DartUP 2020オンライン会議：オフラインと同じように。サーフアイズによるイベントレポート

今年、DartUPカンファレンスは初めてオンラインで開催されました。Google、Yandex、Wrike、EPAM、Meduzaなどのさまざまな企業から450人以上の開発者が集まりました。サーフの人たち も彼らの報告をしました。開発者が提起したトピックと、DartUPが今年覚えているトピックについて説明します。

オンラインはロックンロールで、ほとんどオフラインです

会議は他のオンラインイベントとは異なることが判明しました。SpatialChatのおかげです。そのため、「オンライン」はまったく感じられませんでした。ステージがあり、人が内部のいくつかの場所を占め、これがマイクの音量に影響します。まるで実際に近くまたは遠くに立っているかのようです。



周りの人はコメントを残したり、絵文字を入れたり、マイクでカメラの電源を入れたり、スピーカーとコミュニケーションしたりすることができます。珍しいオンラインの雰囲気の中で多くのネットワーキングが行われたことが判明しました。これは、混沌とした時代の会議ではひどく不足しています。同時に、オンラインのすべての利点が残っています。たとえば、外出先で時間を無駄にしたり、マスクをしたりする必要がありません。それはクールなフォーマットであり、会議の間で本物のロックンロールです。







サーフと会議の主催者であるWrikeには独自のブースがありました。私たちは創造性の自由を与えられました。Wrikeは私たちのすべての活動をサポートし、何も拒否しませんでした。このため、私たちは彼らに非常に感謝しています。

彼らはクールな専門家をステージに置きました

私たちのブースは、プレゼンテーション用の仮想ステージとコードレビューエリアの2つの部分で構成されていました。初日のスケジュールは忙しかったです：







私たちは報告をしました：

• ジェーニャSaturovは、共著者とのホストであるフラッターのDevポッドキャスト。彼はサーフチームのリーダーであり、フラッターのエバンジェリストでもあります。なぜフラッターが必要なのか、本当に必要ないのかを誰にでも説明できます。
• Masha Dolgushevaは、経験豊富で永続的なHRSurfです。マーシャは私たちのためにスペシャリストを選び、インタビューを行い、チーム内の時々の誤解を解決します。
• Artyom Zaitsevは、Flutterコースの学生とSurfのFlutter部門の責任者にとって雷雨です。

ArtyomとZhenyaは、Flutterに関する私たちのプロジェクトについて話しました。

• Rosbank
• ライグル
• KFC DSR
• 穴

10〜15人が聞いて質問するようになりました-それはほとんど群衆です。会議がオンラインであったことは良いことです。そうでなければ、1.5メートルの社会的距離を提供することができなかったでしょう。

開発者が欠員を選択するのを助け、HRと話す方法を教えました

MashaとZhenyaはHRトークを開催しました。これは、視聴者がHRトーカーに仕事に関する最も差し迫った質問への回答を求めることができる形式と呼ばれる方法です。



HRトークでは、開発者から最も人気のある質問を集め、それぞれに回答しました。例えば：

• 自信を持ってインタビューの準備をするにはどうすればよいですか？
• どの企業がFlutter開発者を探していますか？
• なぜ彼らはテストタスクを行うように求められ、それは開発者に何を与えますか？

開発者にとって、



マーシャが労働市場について語ったコード例ほど重要なものはありません。給与のレベル、欠員と再開の数、そしてジェーニャがスピーチのホストでした。それは会議でのフラッターについてではなく、最も活発な会話でした。多くの人々がつながり、エモティコンとコメントで積極的に反応しました。



開発者が多くの興味深い質問をするので、宿題は十分ではないことがわかりました。たとえば、「なぜHRはそれほど執着しているのですか？」プレゼンテーションの後、マーシャは聴衆とのコミュニケーションを続けました。彼女は開発者からの非常に多くの質問を集めたので、彼女は今、彼女が望むなら答えのある本を出版することができます。







2日目は1日目と同様で、昨日のプレゼンテーションを逃した人のためにマーシャが基本的な情報を繰り返しましたが、今回のパフォーマンスは対話というよりはスタンドアップのようなものでした。おそらく、開発者の質問は終わりました。HRにとって人生がどれほど大変かについての話がなかったわけではありませんでした-出席者はこの職業をもう少しよく理解することができました。理解し、許しなさい。

彼らはあなたがアドバイスを聞くべきではない理由を話しました

その間、Zhenyaは新しいプレゼンテーションに切り替えました。Surfの開発者であるLeshaKorpatenkovと一緒に、彼らは私たちのプロジェクトTheHoleについて話しました 。これは、ロシアのYoutubeの最大の発行元であるMediumQualityのビデオストリーミングプラットフォームです。







技術を選んだ段階でも、Flutterでそのようなアプリケーションを作成する必要はないと周りの人は言っていました。男たちは自分の道を進み、すべてがうまくいった。ZhenyaとArtyomが外部の意見に耳を傾けていたら、プロジェクトがうまくいく可能性は低いでしょう。

フラッターマシンのボンネットの下に登った

並行して、Flutterの開発者であるMishaZotievとFlutterの責任者であるSurfArtyom Zaitsevは、「Flutter underthehood」を解体していました。彼らの報告は非常に膨大で有用であることが判明しました。



2020年、MishaはFlutterの「内部」に何度も突入し、フレームワークが使用するアルゴリズムとアプローチを扱いました。最も興味深いトピックについて、彼はHabrの記事を書きました。時間が経つにつれて、ミーシャはかなりの量の資料を蓄積し、それは構造化されて「内部のフラッター」というレポートになりました。これは新しい知識であるだけでなく、実際にどのように適用できるかについての実際の例でもあります。





約270人が同時に見守っていました。これは大きな映画館のほぼ満員のホールです



レポートの後、Mishaは参加者の質問に答えに行き、Artyomは最も長くて最も困難なコードレビューを引き継ぎました。

レビューまたはリポジトリ

Artyomはリポジトリを確認し、参加者からの質問に2時間回答しました。レビューのために5つの申請書が提出され、15人がプロセスに従いました。





コードレビューはYouTubeチャンネルで 行われました。コードレビューは



誰にとっても便利です。初心者は何か新しいことを学び、経験豊富な開発者は外から新鮮な表情を得ることができます。ここでSpatialChatは私たちを少し失望させました：ビデオが遅くなり、誰かが何も見ませんでした。チャンネルからのストリームを表示することにしましたが、何らかの理由でYouTubeが許可しませんでした。私は回り道をしなければなりませんでした。視聴者がそれを読んで私たちのチャンネルに切り替えることができるように、彼らはスタンドにQRコードを残しました。15人が来て、25人が私たちのスタンドを見守っていました。



Artyomはリポジトリをライブで評価し、コードにコメントし、アドバイスを提供しました。しかし、SpatialChatの技術的な問題のため、十分なフィードバックがありませんでした。コメントを通じて視聴者とコミュニケーションをとる必要がありました。



それはランプであることが判明しました、私たちはそれが好きでした。人々は注意深く耳を傾け、有益なコメントを残しました。コードレビューは良い形式であり、同様のイベントを開催することが可能であるという結論に達しました。

私たちの秘密を明らかにした

2日目のスケジュールは混雑していませんでした。ステージ上-すべて同じ人々。







2日目のメインイベントは、Flutter TeamLead ZhenyaSaturovのプレゼンテーション「GearUp」です。彼は、Flutterプロジェクトのプロセスを最適化するのに役立つソリューションを共有しました。



私たちはネイティブ開発を愛するのと同じくらいフラッターを愛しています。 2年前、Flutterは、

見通しがはっきりしない単なる 誇大広告技術でした。それは私たちにとって不快で、どこか怖いものでしたが、私たちは賭けをして、すでにいくつかの大きなプロジェクトとオープンソース開発の大きなリポジトリを作成しました -SurfGear。彼にはクールな使命があります-開発をスピードアップし、典型的なタスクの実装を簡素化することです。





ジェーニャのスピーチ。最後のコメントを喜ばせてください：「ハレー、ユージーン！」



SurfGearについてお話しし、アイデアを集めるためのコンテストを開催したいと思いました。残念ながら、ここでは多くの回答はありませんでしたが、1つのアイデアは本当にコミュニティの痛みを反映しています。Flutter開発者は、依存関係とDIを操作するときに2つのアプローチがあります。

1. get_itサービスロケーターはほとんどがシングルトーンです。すべてが1つの場所に保存され、依存関係はアプリケーションの実行中ずっと存続することがよくあります。
2. 木の上で「転送」。たとえば、プロバイダーを使用します。ここでは、スコープを選択できます。依存関係は基本的に1つまたは別のウィジェットで作成されるため、存続期間を制限します。しかし、これがサービスレイヤーとUIレイヤーを組み合わせる方法です。これもあまり良くありません。

依存関係の「存続期間」を制限しながら、ビジネスロジックをUIから切り離すことができる、「理想的な」アプローチのアイデアが送信されました。具体的な解決策はまだ見つかっていません。おそらく、koinパッケージは同様の何かを提供できる可能性があります。つまり、アイデアの作成者自身がそれに注意を向けました。私たちは彼と一緒にこの問題を調査し、決定を下します。



***

オンラインはオフラインに代わるものではありませんが、Wrikeは、私たちが参加できた中で最も活気のあるリモートイベントを開催しました。そのため、彼らに感謝します。



DartUP 2020に行ったことはありますか？何を一番覚えていますか？