別の分析が熟しました。今回はBaruch jbaruch Sadogurskyによるレポート「JPoint 2015での非同期マルチスレッドhttpアプリケーションの作成方法」を見ています。





スライドはこちら 。



Javaについては、記事自体ではなく、解析されたレポートのみ。

プロット

テーマ

Baruchのストーリーは、JFrogがJavaでファイルアップローダーを作成した方法に当てられています。これは、プロセスの組織的な側面ではなく、技術的な側面でした。 おそらく、開発者は途中で予想外の何かを学び、それを共有したいと考えています。



これは非常にありがたいトピックであり、これにはいくつかの理由があります。

1. あなたは年代順に固執することができます：タスクがどこから来たのか、どのようにアプローチを選択したのか、何を試みたのか、何が起こったのか、どんなミスをしたのか。 ストーリーがプロジェクトの回顧展ではない場合、多くの場合、コンポーネントを正しい順序に並べようとすることで頭がおかしくなります。
2. 明確に隠さない限り、確かに実際的な利点があります。
3. 当然のことながら、些細なことでさえ最初の試行ではうまくいかなかったため、自己皮肉の理由を見つけるのは簡単です。

結論と利点

同様のタスクがあり、単純な方法でそれを解決しようとしていたが、突然会議に出席したと仮定します。 レポートを聞いた後、私にとって何が変わるべきですか？



このプロジェクトからの実用的なヒントのセットを楽しみにしています。 開発者は最初は知りませんでしたが、汗、血、涙を犠牲にして受け取りました。 レポートの最後に、これらの調査結果の中で最も重要な（最もコストの高い）調査結果を繰り返すことを常にお勧めします。 この場合、それらはそれほどグループ化されていませんが、他の場所でそれらを探しましょう。



2つのライブラリ（NINGおよびApache HTTPコンポーネント（asyncclient））のプロパティの単なる言及と比較だけで、人々の学習時間を節約できます（スライド34〜49、14 ：30〜21:30の断片 ）。



さらに、いくつかの問題状況がリストされていますが、すべてが明確な結論を持っているわけではありません。



ファイルの長さ（ 23:10から24:56までのフラグメント ）のストーリーは、潜在的に興味深いものです。 http / 2標準に従って、圧縮ファイルであっても、元の長さを指定する必要があることがわかりました。 チャンクによるファイルスライシングを実装するには、これが問題であることを知っています。 JFrogがこの問題をどのように解決したかはわかりませんが、言うのは当然です。



対照的に、CDNリダイレクトのストーリー（ 24:57から26:26のフラグメント ）とゼロからのダウンロードの開始は、ソリューションに至るまで完全にカバーされています。 意図的にこれを行わない場合、リダイレクト時にヘッダーが失われることを常に思い出す価値があります。 私の意志であれば、同じ静脈内の他のすべてのピースを伝えていただろう。



http / 1.1とhttp / 2の接続数に関する会話は困惑しました。この知識のどれが、一般的に、そして私たちのタスクのコンテキストで実用的な結論を出しますか？ http1.1プロトコルは、3つ以上開かないように要求します。すべてのブラウザーはこの推奨事項に違反して開くので、もし違反して開いた場合、何が脅かされますか？



その後、明らかに開発者が経験したレーキがありますが、各ポイントについて詳しくは説明しませんが、問題の状況はさまざまな方法で提示されることに注意してください。 「すぐに思い浮かぶように」それを行うと何が起こるかは必ずしも明確ではありません。また、Baruchが話しているプロジェクトで、彼らが問題をどのように解決し、まったく決定したかは常に明確ではありません。 これは省略であるように思えます。レーキとそれらを回避する方法は、聴衆がそのようなレポートから持ち帰るべき主なものです。



一般的に、ストーリーは有用ですが、さらに明確に提示することも可能です。

プレゼンテーションの順序

ここでは、多くの場所で、探偵によるプレゼンテーションの順序を適用でき、ストーリーはよりよく記憶されることに注意してください。 投稿が膨らまないように、1つの例を挙げます。 素朴な視聴者として、ある時点でスライド67の精神でコードが書かれたと思います。







そして、簡単なテストでは、どうやらしばらくは機能していましたが、その後壊れました。 それがなんとか美しく壊れたなら、あなたはそれについて話すことができ、症状から調査に行き、それから「質問がある」スライドに行くことができます。 事実は、「問題を修正し、開始し、別の場所に落ちた」ということです。開発者にとって自然なプロセスであり、聴衆は新しい質問が以前の質問とどのように関係するかを理解するためにエネルギーを費やす必要はありません また、決定を下す前にすべてが故障した理由を少なくとも少し考えさせることも役立ちます。

スライド

テキストスライド

プレゼンテーションのさまざまなスライドクラスのデザインが異なることに注意してください。 理想的には、「公式」ステートメントが他のテキストと異なっていても悪くはありません。 これは、スライド8、13、16、18などで見ることができます。







このような背景（最初は空）のスライドが3回目または4回目に表示されると、次のラウンドのプロット開発が行われることを既に理解しています。これにより、知覚が大幅に簡素化され、コンテンツについて考える手間が省けます。 非常に異なるフォントが非常に適切であり、特に読みやすいため、同じ目的に役立ちます。



すべてのスライドがテキストのみで構成されている場合、分析する音声に関係のない叙情的な余談：スライドの役割（要件はこちら、結果はこちら、問題はこちらなど）に応じて異なるテキストレイアウトが特に推奨されます。 スピーカーの準備に関する私の経験によれば、視聴者はまだ外見的に同じスライドにうんざりしており、そのようなレポートは客観的に興味深いコンテンツであっても低い評価を得ることがよくあります。 おそらく、人々に少なくとも多様性の代替を与えると、少し簡単になるでしょう。

フォント

残念なことに、フォントはレイアウトされた.pdfに含まれていなかったため、これらの強調表示されたスライドは悪く見えます。 カスタムフォントの喪失に関連するオーバーレイがよく見られます。 よくある不愉快なことは、文字が指定された場所に収まらなくなり、美しくフォーマットされたスライド全体が乗るということです。 したがって、一見キャプテンの推奨事項について、テキストの段落をさらにいくつか使用します。

1. 非標準フォントを使用する場合は、コンピューターから話すか、フォントとともにプレゼンテーションを配布するか、.pdfを作成する必要があります。 この場合、これは助けにはなりませんでした、結論：配布前に作成された.pdfを確認することは有用です。
2. 企業のコンピューターでスライドを準備している場合は、企業のブランドブックのフォントをデフォルトで事前にインストールして含めることができ、標準ではないことに気付かないこともあります。 そして、彼らは別の場所にいないという事実のためにすべてが壊れます。

写真

スライドにはできるだけ少ない要素が必要だと思います。 有用な演習：各スライドを見て、意味を失うことなく破棄できると考えます。 それでもない：最初に、スライド全体を破棄できるかどうかを確認し、それでもそれが不可能な場合は、さらに最小化します。 そのため、写真の周りのフィールドもスライド要素であり、ほとんどの場合、余分です。 スライド上に絵だけが本質的にある場合（タイトルまたは1つの短いフレーズが本質を変えることはありません）、それが画面全体を占めてはならない理由は1つではありません。



スライドを定型化したい場合があります（新聞の場合、家族のアルバムの場合、知らない場合）。これには何らかのフレームワークが含まれる場合がありますが、すべての画像は同じように設計する必要があります。 スライド上のさまざまな場所に配置され、エッジからさまざまな距離にあるさまざまなサイズの写真が乱雑に見えます。 ほとんどの場合、フチ無しスライドの方がより正確に見えます（左は元のバージョン、右は改善のための提案です）。















フルスクリーンの画像を高解像度で検索する必要があります。最初に取得した画像は機能しませんが、実際の難易度はWheelerの写真だけです。 分析中のレポートでは、多くの写真で、たとえ小さなものでもピクセルが見えます。 これは過失の感覚を高めます。



パンの代弁をする伝道者は、雇用主から有料の株式購読を取得する必要があるかもしれません。 多くの人は、「オフィス」、「協力」、「コンピューターの前の怒っているユーザー」、「コールセンターの従業員」などのテーマのストック写真を撮ることができないことを警告しています。 しかし、まだ多くの無人の原子力発電所と熊が足を上げており、熊が足りなくなるとパンダがいます。 専門的に話さない人は、1つのプレゼンテーションのデザインに100ドルまたは200ドルを費やしたいとは思わないでしょう。つまり、もっとグーグルで検索する必要があります。



準備が急いでいたという感覚に追加する別の側面があります。 プレゼンテーション全体のスライドのデザインに共通のテーマ、一般的なアイデアがある場合に便利です。 コンセプトが狭いほど、ストーリーとリンクするのが難しくなります。たとえば、スターウォーズのキャラクターを表現するのはそれほど簡単ではありません。 しかし、コンセプトを拡張することもできます。たとえば、スターウォーズだけでなく、より広範なSF映画を撮影することで、これらの制限を満たすのが簡単になります。 しかし、これはいずれにせよ、熟考にかなりの時間を必要とします。 しかし、Baruchのスピーチの画像は、まったく異なる世界から来ました。









上記の例でも、よく見ると、説明されていることの意味ではなく、スピーチで発生するいくつかの別個の単語だけであることに気付くことができます。 明るい、面白い写真、人々はもちろんよく覚えていますが、これは私たちが必要とするものではありません。 意味を覚えておく必要があります。

スクリーンショット

一般的に、私はスライドのスクリーンショットに反対しています。 いつか誰かが分析のために悪いスクリーンショットを含むレポートを代わりに提供し、それから私はすべてを詳細に説明します。 しかし、ここでは彼らはその場所に慣れており、よく装飾されています、例えば：







本当にスクリーンショットを追加したい場合は、次の3つの点でBaruchの例をご覧ください。

1. 検索エンジン、stackoverflow、githubなどの有名なページからのみスクリーンショットを撮ります。 とにかく、企業内クラスター監視アプリケーションを理解する人はいませんし、見苦しいです。
2. スクリーンショットを撮る前に、ブラウザで画像を拡大し、画面の重要な部分のみを表示します。 これは、少なくともブラウザ内のテキストが劣化しないため、スクリーンショット自体を引き伸ばすよりも正確です。
3. 見る必要のあるものに丸を付けます。

定期的なレビュー

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