本日、新しいセクションを開きます：技術的なプレゼンテーションの分析。 ITカンファレンスから一般的に成功したレポートを取得し、それを改善する瞬間を形式化すると、プレゼンテーションの観点から多くのことを学ぶことができます。 また、同じレポートで、改善できる瞬間を形式化する場合、メリットは2倍になります。 会議で発言しようとしている人が役に立ちます。 そして、長く成功している人にとっても、これは痛くないでしょう。



本日、 JPoint 2016でSergey Walrus Kuksenkoによるレポート「Quantum Performance Effects II：Beyond the Core」を提供します。





→ スライドはこちら



免責事項： Javaについては、まだ見ていなければレポート自体のみです。 カットの下の記事はレポートについてです。

プロット

多くは、レポート内のプロット要素の構成と品質に依存します。そのため、それらから始めます。

探偵団

非常にすばやく（スライド5〜9、時間02：00-05：00）セルゲイは自分の名刺と考えられるテクニックを使用します（同じように巧妙に使用する人がいます。これはAlexei Shipilevです）。 私はこの手法を「プレゼンテーションの検出順序」と呼び、研究と使用のためにすべての人にお勧めします。 良い、良い順序は次のようになります。

1. プログラムに奇妙な症状が見られます（殺人犯）。
2. 私たちは何かを強化し、どのような変化があるかを見ようとしています（警察が証拠を集めています）。
3. もっともらしい説明を見つけたようです（公爵夫人を疑います）。
4. 私たちの仮説を破壊する新しいテストが見つかりました（公爵夫人アリバイ）。
5. 最後に、問題の真の原因が明らかになります（殺人者は執事です）。

明らかに、このようなプロット構造は、引きずりすぎない限り、聴衆の注意を引き付けます。耳を傾けることは興味深いです、あなたは探偵の役割で自分を試すことができ、一般的にはそれがどのように終わるかを知りたいです。 「探偵小説を再生する」は非常に重要な側面です。なぜなら、私たちは観客を引き付け、彼らに考えさせ、ストーリーの主題について正確に考えさせるためです。 セルゲイはこれをよく理解し、定期的に実証しています。



問題の理論的正当性を最初に示し、次にその兆候の例を示すと、逆の順序になります。ほとんどの場合、退屈で観客が少なくなります。 もちろん、このジャンルでも比較的成功した作品があります（コロンボ中Liを覚えている人はいますか？..）が、セテリスパリバスの「探偵の秩序」が注目を集めています。 だまされてはいけません、ここでの容易さは明らかです。 まだ解決されていない問題を示すコードは、その問題が既に知られているコードよりもはるかに慎重に記述する必要があります。 事前に主要な秘密を明かすことなくヒントを投与することは困難です。 会議を準備するとき、私はしばしば話者がこの順序で物語をやり直すことを提案しましたが、最初の試みで、それに対処する人はほとんどいません。 そのため、単純な探偵小説の背後に、重要な仕事が隠れています。



レポートのほとんどすべての例は同じ原則に基づいていることに注意してください。

問題化

しかし、先に進みましょう。 まだレポートの冒頭にあるいくつかの人目を引く例の後、私は普通の人の生活におけるプロセッサキャッシュの周りの問題があなたが思っているよりも一般的であるというストーリーを見ると期待しました（たとえば...）彼らは遅かれ早かれ真剣に彼らに苦しむことを望まない人でなければなりません。 平均的なJavaプログラマー（これは私が覚えている、JPoint）がプロセッサー・キャッシュの問題に遭遇するのは、生涯に1回よりもはるかに少ないからです。 通常、「これはすべての人に起こりうる」という理解は、聴衆にもう少し注意を向けます。 セルゲイの実際の参考文献は、スライド43の33:20から始まる「デモ6」セクションで最初に出会ったが、その頃までに、このレポートはすでに人気のある科学のエキゾチックであると認識されていた。



現在からどれだけのレベルの抽象化がプログラマの心に自由に浸透するかというトピックに関する多くの（しばしば矛盾する）引用があります。 おそらく、偉大な者の権威に目を向ける価値があったのでしょう。 いずれにせよ、「これが個人的に重要なのはなぜか」という仮想視聴者の質問に対する少なくともいくつかの回答は、各レポートの冒頭に近いはずですが、ここではそのような回答はありません。

結論

エンディングはかなり衝撃的です。 視聴者が知る必要のある特定の問題のリストと哲学的メッセージがあります。景観全体を研究し、測定結果から結論を導き出さないでください。 ここで、それは私には思えます、すべては大丈夫です。

スライド

スライドのデザインに関するコメントは、主にバッテリーの消費に関連しています。 各視聴者が頭の中にバッテリーを持ち、考えているように座っていると想像してください。 彼は私たちのアイデアに賛成または反対することができます、彼はそれを論破する方法、彼の仕事にそれを適用する方法、彼が同僚にそれをどのように伝えるか、トピックに関連する他の問題について考えることができます、彼はスピーカーを傍観者に捕まえて尋ねたい-これらはすべて有用な考えであり、バッテリーについて残念ではありません。 しかし、どんな状況でも、視聴者が私たちのアイデアが何であるかを痛々しく理解しようとすることを決して望まない。 「ここには何が書かれていますか？ 彼はテーブルのどの行について話しているのですか？ 彼はどういう意味ですか？」-非生産的な支出。 セルゲイの素材は画像にとって最も簡単なものではないため、改善できる箇所がいくつか見つかっているはずです。 もちろん、ありました。 そして、節約された料金は、観客がキャッシュラインがどのように配置されているかをよりよく理解するのに十分です。

コード

しかし、まず第一に、レポートにあるコードの断片を賞賛したいと思います。 結局のところ、ご存じのとおり、コードは簡単に記述できますが、読むのは困難です。 したがって、私たちが実証するコードフラグメントに多くの作業を投資する必要があります。それらはシンプルで最小限のものでなければなりません。 この場合、彼らはまさにそれであり、投資された労働は報われる。



それとは別に、コードが白い背景で正確に正確に示されていることに注意してください。







もちろん、 vimの多くのプログラムは、背景が黒の異なる配色を使用しています。 スライド上で再現しないでください：黒のグレー、赤、濃い青は、プロジェクターで簡単に完全に見えなくなります。 このことを一緒に話しているスピーカーに話すと、どれほどの抵抗に遭遇するかは驚くべきことです。 議論は、「これらのスライドをすでに見せたので、すべてが見えるようになった」から「主催者は通常の機器を提供するだけでよい」に由来します。 私の意見では、これは、「有効なデータをサービスに送信するだけ」または「はい、1週間正常に回転しています」などの口実の下でエラーを処理しないコードを記述することと同じです。

ポインタ

Sergeyのコードはシンプルで、ナビゲーションは不要です。 また、ナビゲーションが必要な場合は、レーザーポインターが使用されます。 私の世界観では、レポートごとに1回使用すると、すでに必要以上に使用されています。 同時に、私たちがそうであるように、ビデオを見る人々は苦しみます。 50:24から50:35までの文章をご覧ください。 問題はこの記録とこの読み物にはありませんが、この記録とこの読み物にあります。 すべてが明確です。



もちろん、ホールに来た人々のために働く必要があります。彼らはレコーディングを見る人々よりも重要です。 しかし、レポートをライブで見た人の多くも不運でした。 これは、すべてが起こった部屋のようです。 ポインタを見る機会がほとんどない人を見てみました（プレゼンターは左の画面でのみポインタを使用しました）。







同時に、2つの画面が重複する構成は珍しいものではなく、会議で頻繁に発生します。





私はかつてクリッカーでレーザーポインターを閉じ、かつてなかったように生きており、フレーム、矢印、スキーム上の要素の連続した外観、または色の変化を使用して照明を行う必要があります。 スライド64には、たとえば矢印があり、通常は次の機能を実行します。

テーブルとチャート

しかし、スライド64には、他のいくつかと同様に、テーブルがあります。 分析（並べ替え、サブサンプルなど）には便利ですが、デモンストレーションには劣ります。 見せたいものをすぐに見る必要があります。 長さが異なる列は、数値よりも比較がはるかに簡単であり、さらに、すぐに比率を示します（頭で分割しないように、86が35を超える回数）。 多くの場合、表は図の形で再描画できるため、解読が容易になると考えています。 スライド46の2つのオプションを比較します。



オリジナル：







再加工：







もちろん、図を2つのスライドに分割し、最初のプレゼンテーションのテーブルで行ったように、最初に青いストライプを表示し、次にそれらにオレンジを追加します。



チャートについて説明する場合は、スライド26からチャートを変更する必要があります。







ビデオでは、彼は13:41に登場します。 この場所から1分ほどを見てください。スライドには多くのデータがあり、わかりにくい凡例があるため、グラフが良いケースであり、悪いケースを理解するには多少の努力が必要であるように思えます。 もちろん、あなたはそれを理解することができますが、チャートが一度にすべて表示されずに順番に表示され、スピーカーのそれぞれがショーの時点で別々に説明しコメントすることができれば、それははるかに簡単です。



グラフ上の線に直接署名して、凡例を完全に削除することをお勧めします。 伝説は悪であるという事実は、私はすでにここに書いたが 、繰り返しに飽きない。

色

52:53のビデオに表示されるスライド65のポイント図は、知覚の観点から興味深いものです。 ここにあります：





この写真の何が問題になっていますか？ その上の色は、良いケース（クイックコピー）を象徴する赤から、悪いことに対応する紫まで、虹の順序でソートされます。 ただし、「虹による」並べ替えは意識レベルでのみ行われるため、黄色と青のどちらの色が良いかを判断するには、目で伝説を駆け回るか、ハンターとキジの話を覚えておく必要があります。 これはそれほど難しいことではありませんが、もっと簡単にすることができます。



頭では、この比率がより明るい/暗い場合を除き、色は自動的にソートされません。 ソーシャルエンジニアリングの簡単なタスクを解決した後、図のソースを取得し、1色で再描画し始めました。 シェードの数を5つに減らす必要がありました（4つまで可能ですが、50 +は別の色に値することはほとんどありません）。しかし、最終的には、私にとってより明白なオプションがありました（明るい-良い、暗い-悪い）：







もちろん、デモの前に、これがプロジェクターで見えるかどうかをテストする価値があります。

定期的なレビュー

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