前回の分析から多くの時間が経過しましたが、私はその考えをあきらめませんでした。 今日は、最初にデータサイエンティストであり、第二に何らかの理由で.NETが好きな人がどのような解決策を持っているかについて、ローマネボロマンネボリンによるレポートに注目します。



2016年12月にDotNextでこのパフォーマンスが行われたのは論理的です。





スライドはこちらにあります 。



従来の免責事項：.NETについては、記事自体ではなく、記事で解析されたレポートのみ。

スピーカーの行動

以前のレビューでは、これに焦点を当てる理由はありませんでしたが、Romanは自分自身はあまり経験のあるスピーカーではないと考えていると別に書いたので、いくつかの点についてコメントします。



話者の視線は、彼が横を向く必要があるたびに非常に素早くホールに戻ることに注意してください。 ストーリーには、スライド、デモ、およびスピーカーの注意を必要とするその他のものに関するコードが含まれています。 非常に多くの、非常に経験豊富な人々でさえ、この後しばらく画面に張り付いており、Romanはうまく対処します。それがまさに必要なことです。



もう1つの注目すべき瞬間は3:45頃でした。 人が表彰台に置かれ、そこに立つように命じられた場合、カメラがそこに向けられているので、たとえそれが不便であっても、彼はしばしばそうします。 この場合、話者は正しいことをしました。話中の不快感は、可能であればすぐに修正する必要があり、カメラは何らかの形で調整されます。



活発で聴衆と連絡を取り合っているスピーカーは、コンテンツとスライドにさらに多くの欠陥を与える余裕がありますが、それでもうまく機能します。 もちろん、聴衆との接触は失敗したナンセンスを救うことはできませんが、スピーカーの活気は通常の物語に多くの信頼性ポイントを与えます。

プロット

一般的に、ローマの物語の意味は次のとおりです。データ科学者が必要とする典型的なツールがあり、これまでのところ、このツールセットは.NETに関連付けられていません。 一方、プラットフォームのフレームワーク内には、優れたF＃タンがあり、ほとんどすべてがすでにそこにあり、それを使用して使用します。

対象読者

パフォーマンスの目標がF＃の普及であるとします。 これは.NETとデータサイエンスの接点にあるツールであるため、データサイエンスを所有し、.NET + F＃を販売している人々に行くことは有望です。 現在、まったく異なる技術スタックを持っている研究者を.NETに移行する方法を想像することは困難であり、彼を取り巻く開発者も.NETを使用していませんが、販売市場はそこにあるように思えます。 .NETカンファレンスでは、突然額をたたいて、F＃が問題を解決するのに適していることに気付く人はほとんどいません。

リストと 物語

少なくとも何らかの形で技術情報が織り込まれた筋書きのあるストーリーは、単にこれらの技術情報をリストするよりもうまく機能すると確信しています。 レポートでは、F＃の小さなタスクによってバックアップされたデータサイエンティストの作業の側面を確認します。 このアプローチにはいくつかの問題があります。



第一に 、システム全体が地球規模の問題を解決するのに適しているということではありません。

第二に 、すべてのタスクは、たとえ小さなものであっても、観客が最初から理解する必要があり、以前は前のタスクを頭から投げ捨てていました。 レポート中に、次の主題分野に遭遇しました。

• 国別の開発者の分布
• 花の販売
• コンタクトレンズレシピ
• 第三世界のマクロ経済指標
• 自転車レンタル+線形回帰
• 株価分析

タスクは毎回完全に新しいため、条件はゼロから説明する必要があり、視聴者が以前に蓄積した情報の一部を頭から​​アンロードする必要があります。 1つの大きな横断的なストーリーがより有利に見えるように思われます。その過程で、F＃の力を示すことができる問題があります。 視聴者の頭に全体像を簡単に配置できます。



同時に、実際のタスクまたは類似のタスクは、明らかに架空のタスクよりも優れています。 これがカスタム開発であり、NDAの下でのすべての実際のタスクであっても、真に機密情報を開示する必要がないため、顧客はこの話に反対しないことがよくあります。 お客様に許可を求めても、何も失われません。

生演奏

横断的なタスクがある場合、聴衆にとっては少し簡単になりますが、時間がかかる場合があります。サブジェクトエリアのイントロを行い、ソリューションアーキテクチャ（これも複数回参照されます）、およびコードを記述する必要があります。難しくなります。 この時間を見つけるために、デモンストレーションを減らすことを提案します。これについては、いくつかの言葉を話す時間です。



私の意見では、デモはフロントエンドの手に有機的に見えます。 確かに、それはそのように遅くなりますが、コマーシャルはもはや存在しません。 美しい3D効果が得られますが、うまくいきません。 デモを使用すると、コードとコードが生成する効果をすぐに関連付けることができます。 ただし、これも事前に記録されたスクリーンキャストで行うことができます。



サーバーアプリケーションをライブでデモンストレーションする必要はありません;その結果をスライドに表示する方が簡単です。 聴衆は、デモンストレーションがなくても、スピーカーが全体として合理的に見え、もっともらしいことを言うと、スピーカーを信じる傾向があります。



それとは別に、自転車レンタルの線形回帰（ 27:20から開始）でデモを批判したいと思います。 線形回帰に慣れていない人にとっては、コードはすぐに表示されたり消えたりするため、関連する数学への参照が常にあるため、何も与えません。 ここでローマ人は、まったく妥当ではないことを言っており、これからそれに従うことは非常に難しくなります。 ある種の機械学習で受けた間違いが気に入らない場合（この用語が線形回帰を指すかどうかは別の哲学的議論であるかどうか）、利用可能なすべてのデータをトレーニングに投入するのは悪い考えです。 まず第一に、再訓練の考えが思い浮かびますが、何らかの偽のデータセットが存在し、自然なノイズが存在しないということはまったくありません。 つまり、ここで言うのは数学的に正確ではなく、アプリケーション間のちらつきさえありました。

結論

レポートの結果に基づいて、私はF＃に必要なものがすべて揃っていると信じる準備ができているので、別の要約スライドでこれを繰り返す必要はないようです。 括弧の外側には制限とパフォーマンスがありますが、すべてについて話すことはできません。

スライド

スライドはかなりまともなので、私のコメントのほとんどはマイナーな改善です。 主な利点は、スライド上に表示する必要があるものがあり、余分なテキストがないことです。 つまり、スライドは理想的な世界で果たすべき役割、つまり講演者のスピーチのためのイラストの役割を正確に果たします。



しかし、改善するためにはもちろん、常に何かがあります。

コード

デモンストレーション中にコードの大部分が画面に表示されますが、スライドにもたくさん表示されます。 コードに関するいくつかの提案があります。



スライド22〜25では、Stackoverflow APIへの呼び出しをラップするために実装する必要があるクラスが順番に表示されます。 一方で、単語に順番に焦点を当てたいと思います。そうです、そうです、すべての複雑なオブジェクトを部分的に開く方が良いです。 ただし、このプロセスをよりクリーンにすることができます。 最後に、すべてが3つの追加クラスになります。







このスライドですぐに、これらの3つの追加のクラスが必要な理由がわかりますか？ 少し時間がかかりますよね？ したがって、私は注目すべきものだけを強調することを提案します：







どちらが誰を引っ張っているのかはもっとはっきりしているように思えます。 もちろん、コードの一部を順番に開くとき、すでに作成されたセクションの強調表示は削除できます。



多くのコードがあるスライド51は20:33にレポートに表示され、コメント「not the essence」とともに2秒間表示されます。 削除する方が良いと思います。 見るべきではないものを人々に示す必要はありません。

コンテキストの保存

プロセスのダイナミクスまたはソリューションの逐次近似を表示するたびに、注意を喚起したいものだけを写真で変更することをお勧めします。 他のすべての情報は、関連性は維持されますが、そのまま残しておくことが最適です。 ほとんどの場所で、小説はまさにそれを行いますが、スライド36〜38では、図を再描画することをお勧めします。







ここで何を改善できますか？ 第一に、時間はほとんどの人の心の中では左から右へ流れるようなものであるため、他のほとんどの場合とは異なり、時間とともに変化するデータに水平バーを使用しない方が良いです。 さらに、スライド36からチャートを回転させると、スライド37および38からチャートをオーバーレイでき、視聴者はコントラストの問題を解決するための以前のバージョンを試すことができます。 もちろん、Romanが示す状況は非常に単純なので、ここではこれらのすべてのトリックがなくても理解できますが、より複雑なケースでは、これにより視聴者のエネルギーが大幅に節約されます。







2つのスケールに悩まされないように、質的比較のみを残して、垂直軸を完全に削除することをお勧めします。 実際のデータ科学者は実際の作業中にこれを行わないことを理解していますが、ここではアイデアを伝えるだけです。 スピーカーにソースコードを要求しなかった場合は、グリッドを削除します。



サイドノート：興味深いことに、バレンタインデーは3月8日より涼しいです。 ただし、次のストールではすべてが異なります。

過失

正直、気付かれた過失は目を引きませんが、私は捕まったので、何も言いません。 まず、いくつかの場所で、スライド上のオブジェクトが明白な必要なしにシフトされます。 ここでの問題は、オブジェクトが変更されていないが動いた場合でも、目はまだ変更をキャプチャし、オブジェクトが変更されたかどうかはもはやわからないということです。 そして、前のオブジェクトはすでに視野から出ているので、意識的な努力もそれらを比較しません。 したがって、不変オブジェクトは、スライド上で自然にジャンプしてはなりません。



スライド22と23を切り替えると、コードの上部ブロックがジャンプしていることがわかりますが、変更されていません。 スライド30と31の間のコードの下部ブロックでも同じことが発生します。どのようになるかは明らかです。スライドを手動で実行するのは面倒なので、IDEからスクリーンショットとしてコードをコピーする方が便利です。 さらに、スライドの1つで、画像が誤って移動またはサイズ変更され、作成者はこれに気付きません。 構文の強調表示を拒否することをお勧めしますが、テキスト形式のコードを使用することをお勧めします。調整が簡単です。



別の楽しいことは、すでに上で見た花屋の販売で見つかりました。 スライド33-35と37-38の年は一致しません：







これには多くの有効な説明があるかもしれませんが、堆積物は残ります。

定期的なレビュー

プレゼンテーションに関するフィードバックを受け取りたい場合は、喜んで提供します。

恥知らずな自己宣伝の瞬間

6月7日水曜日、モスクワの夕方7時頃、キリルアナスタシンと共同イベントを開催します。 ステージに入る前、つまりトピックを選択するときや準備中にスピーカーがよく行う典型的な間違いのまともなリストを蓄積しました。 あなたが話し始めたら、来てください：それは役に立ちます。