デモの進め方

Being Geek ―ギークであり続けるためのキャリア戦略の中で、『デモ』についての章があったのでメモ書きします。
私はかなり緊張しやすく、伝えたい事が半分程度にしか伝わらない事が多い為、備忘の為に残します。

  • デモとプレゼンテーションは異なる
  • デモは参加者により参加してもらうもの。

  • デモ対象について最も知っているのは自分
  • だから自信を持てば良い。

  • 3つのフェーズ
  • デモをする場合、相手が誰であろうと目的はみんな一緒。
    みんな目的は情報を得る事である。デモをする際は下記の基本ルールを守る。

    1. 背景説明
    2. デモを理解する上で知っておくべき事を伝える

    3. 内容説明
    4. 発見、アイデアの具体的内容を詳しく説明する。

    5. ポイント説明
    6. 発見、アイデアのどこに最も価値があるかをようやくする。
      そして、聞き手に意見を求める。

  • 聞き手のタイプ
    1. 何も言わない人
    2. この手のタイプが最も厄介である。
      打破するには、背景情報や発見に至るまでの物語を長く話すと良い。
      毎回このタイプを想定しておけば、怖いものはない。

    3. 積極的な人
    4. 一見、厄介に感じるが、最もありがたい存在。この手のタイプから建設的な意見が出だすと
      デモは成功していると言える。だが、積極的な人がよく理解出来ていない状況の場合は
      かなりまずい状況と言える。まずは深呼吸をして立て直そう。
      デモ対象について最も知っているのは自分。

    5. 仕切り屋
    6. 仕切り屋は途中(もしくは最初から)で自分のペースに持って行こうとする。
      デモを行う人ではないのに。そんな時は”完全な沈黙”、”デモのテンポを変更する”等を行い、
      自分のペースに引き戻す。また、仕切り屋によって、あらぬ方向へデモが進んでしまう事により
      新たな発見があるかもしれない。(自分が見えていなかった事など)

  • 理想のデモとは、発表者のいらないデモ
  • そんな事は絶対に不可能。理想のデモをどのようにやれば良いとは言えないが、
    結局試行錯誤を重ねていくしかない。

    結局、プレゼンテーションの本(ZENなど)にも同じ事が書いてありますが、
    本番前の練習がモノを言うということでしょうか。


    ウェブオペレーション(非リレーショナルデータベース)

    その時の気分で本を変えてしまってますが、ウェブオペレーション ―サイト運用管理の実践テクニック
    15章 非リレーショナルデータベースを読んだメモを残します。
    イマイチNoSQLが自分の中に落ち切っていないので、この章から確認しました。

    SQLデータベースのスケーラビリティ
    SQLデータベースのスケーラビリティは、4つにまとめめられる。

    1. キャッシュの最適化
    2.  読み取り負荷の軽減には非常に役立つ。
       但し、アプリケーションは複雑になり、軽減可能な負荷に限界がある。

    3. クエリの最適化
    4.  クエリの最適化も同様に限界がある

    5. 新しいハードウェアの購入
    6.  非常に効果的。問題は2つ。値段が高い。最も良いハードウェアを購入するとその後の手立てがなくなる。

    7. シャーディング
    8.  最後はシャーディング。シャーディングに適しているのは、ユーザID等から取得先のデータベースを
       振り分けるような場合(西海岸と東海岸とか)。だけど、ちょっと面倒。

    どうすれば簡単にスケール出来るのか? どうすればデータを近くに保存出来るのか? どうすればアプリケーションを再構築しなくて済むか? といった悩みから生まれたのがNoSQLである。

    NoSQLデータベースの概要
    NoSQLは以下の5つに分類出来る

    1. キーバリュー型
    2. キーバリュー型は昔からある。memcachedで再注目された。
      非常にシンプルでキーを渡せばバリューが返る。

    3. データ構造型
    4. キーバリュー型とほとんど同じ。バリューをリスト・セット・ハッシュ等のデータ構造で格納する。
      リストだとpush, popが出来たりとアプリケーションのデータ構造と同様に操作出来る。
      Redis

    5. グラフ型
    6. データ構造型のデータ構造がグラフになっただけ。データはキーバリューではなく、
      ノードとエッジで格納される。

    7. ドキュメント指向型
    8. キーバリュー型に似ているが、バリューがドキュメントとなる。
      ドキュメントはJSONオブジェクトで格納されている。
      このタイプは、データ構造が事前に分からない場合に有用である。
      CouchDB
      MongoDB

    9. 高分散型
    10. 複数の形式があるが、共通しているのは複数ノードへのデプロイに最適化されている事。
      分散システムでキャパシティを増やすには、新しいノードをクラスタに追加すれば良い。
      1つのノードに障害があっても データが失われることなく、
      キャパシティが損なわれるだけである。一貫性を犠牲にして、可用性と分割耐性を保証するものが多い。
      なぜ、高分散型を使用するか?他に選択肢がないから。
      SQLベースのDBでは、大量のデータを扱えないが、高分散型では可能。
      但し、面倒。
      Cassandra
      HBase
      Riak

    例で挙げた各データベースについては、後日調べる事とする。


    「プログラマが知るべき97のこと」のまとめ

    プログラマが知るべき97のことを読み終えたので、備忘の為に1言ずつ残します。

    01 分別のある行動

      その場しのぎの対応は結局先送りとなって残る事が多い。これを技術的負債と言う。分別のある行動で早く負債は返済しよう。

    02 関数型プログラミングを学ぶことの重要性

      自分の書くコード品質が大きく高まるよ。参照透過性を意識してプログラミングする

    03 ユーザが何をするかを観察する(あなたはユーザではない)

      プログラマとユーザは思考が違うよ。立ち位置はユーザ側へ

    04 コーディング規約を自動化する

      コーディング規約は結局守られない。自動的、強制的に入れれば良い。品質も上がるよ。

    05 美はシンプルさに宿る

      シンプルなコードは可読性、保守性、開発効率、美があるよ。美しいコードは結局シンプルである。

    06 リファクタリングの際に注意すべきこと

      リファクタリングだからって、全部書き直しはNG。変更を少しずつ公開。人間はミスするよ。

    07 共有は慎重に

      コードの再利用化をする際は、コンテキストを読み取らないとダメだよ

    08 ボーイスカウト・ルール

      チェックイン時は必ずチェックアウト時よりも美しくすること

    09 他人よりまず自分を疑う

      まず自分のミスを疑ったほうが早く解決するよ

    10 ツールの選択は慎重に

      安易にツールをたくさん使用しない。最初は最低限のツールのみでスタート。

    11 ドメインの言葉を使ったコード

      ユーザ定義型を使え

    12 コードは設計である

      コードを書くことは機械的な作業ではない。創造的な仕事だよ。

    13 コードレイアウトの重要性

      コードレイアウトが良ければ、保守性があがる。素晴らしいプログラムは詩のようにみえるよ。

    14 コードレビュー

      コードレビューは楽しいものに。チーム全員に同じ知識を共有させる。その前にガイドラインは示すこと。

    15 コードの論理的検証

      バグを出さない為に制約を設けて、チーム内で互いに共有しあう。

    16 コメントについてのコメント

      コメントは悪ではない。でもコメント内容は気をつけて

    17 コードに書けないことのみをコメントにする

      コードに書いていないことを書くのではなく、書けないことをコメントする

    18 学び続ける姿勢

      とにかく学び続けないと置いていかれちゃうよ。

    19 誰にとっての「利便性」か

      APIは多様性を持たせずに分けた方が利用者側では使いやすい

    20 すばやくデプロイ、こまめにデプロイ

      デプロイタスクはプロジェクト初期から取り組んだほうが良い

    21 技術的例外とビジネス例外を明確に区別する

      技術的例外とビジネス例外を混在させると、本来の意味が分かりづらくなる。分けること。

    22 1万時間の訓練

      1万時間練習すれば、誰でもエキスパート。

    23 ドメイン特化言語

      DSLを導入すれば、作業スピードが上がるよ

    24 変更を恐れない

      コードの変更を恐れずに積極的にシステムを改良しよう

    25 見られて恥ずかしいデータは使わないこと

      テストデータも気を抜くな。誰がいつ見るか分からないよ

    26 言語だけでなく文化も学ぶ

      複数言語から新しい発想を得れば、違った解決方法が出るかもしれない

    27 死ぬはずのプログラムを無理に生かしておいてはいけない

      例外をユーザに絶対に見せない事が正しいわけではないよ

    28 「魔法」に頼りすぎてはいけない

      他人の仕事は簡単に見えるもの。簡単に見えると魔法のように自動的に出来るように感じる。それを解くと大変なことが起きる

    29 DRY原則

      繰り返しはダメだよ

    30 そのコードに触れてはならない!

      開発者はステージング、本番環境のコードに触っちゃダメ

    31 状態だけでなく「ふるまい」もカプセル化する

      バグが発生しにくくなるし、保守性もあがるよ

    32 浮動小数点数は実数ではない

      浮動小数点を使用する時は丸めが発生するかが重要

    33 オープンソースプロジェクトで夢を実現する

      オープンソースプロジェクトに参加すれば力がつくよ

    34 API設計の黄金律

      APIを提供するときはAPI自身のテストのみでなく、APIを利用するコードのテストも行うこと

    35 超人の神話

      超人はいないよ。みんな努力してきたからだよ

    36 ハードワークは報われない

      プロジェクトへの貢献は短い時間で高いパフォーマンスを出せばよい。その為には自分を磨け。

    37 バグレポートの使い方

      バグレポートには、再現方法・本来の仕様・実際の動作を記述する

    38 余分なコードは決して書かない

      今使用しないコードは書かない。その時書けば良い。

    39 最初が肝心

      取っ掛かり易くしてあげること

    40 プロセス間通信とアプリケーションの応答時間の関係

      リモートプロセス間通信を少なくすることが大事。結構コストがかかるよ

    41 無駄な警告を排除する

      警告を出し過ぎると、本来検知して欲しい警告が埋もれるよ

    42 コマンドラインツールを使う

      IDEは便利だけど、裏で何をしているかを知ることが大事

    43 プログラミング言語は複数習得すべき

      少なくとも2つのパラダイムの言語を習得すること

    44 IDEを知る

      IDEを深く知れば、作業効率が上がる

    45 限界を知る

      何事も限界を知れば、次の一手が出てくる

    46 すべきことは常に明確に

      やっている事を明確にしないと遠回りになるよ

    47 大量のデータはデータベースで

      あたりまえだけど、データはデータベースへ

    48 いろいろな言葉を学ぶ

      複数プログラミング言語だけでなく、その他の職業毎の用語を知ればコミュニケーションは円滑になるよ

    49 見積りとは何か

      見積を大事に。見積の上に、ターゲット、コミットメントがあるよ

    50 Hello, Worldから始めよう

      何でも自分で試してみるのが大事

    51 プロジェクト自身にしゃべらせる

      自動検知する仕組みがあれば楽

    52 「その場しのぎ」が長生きしてしまう

      暫定ソリューションは結局残ることが多い。勇気をだして、暫定ソリューションは捨てて新しくつくろう。

    53 正しい使い方を簡単に、誤った使い方を困難に

      インタフェースはユーザのもの。開発側の利便の為ではないよ

    54 見えないものを見えるように

      何でも見える化することが大事

    55 並行処理に有効なメッセージパッシング

      共有メモリを使わずにメッセージパッシングを使ってプログラミングすると良い

    56 未来へのメッセージ

      自分の書くコードは未来の誰かへのメッセージ。自分に対してかもしれない

    57 ポリモーフィズムの利用機会を見逃さない

      ポリモーフィズムを有効に使えば、コード量が減り読み易くなる

    58 テスト担当者はプログラマの友人

      テスト担当者と仲良くしよう。顧客に見られる事を防いでくれたのは誰ですか

    59 バイナリは常に1つ

      どの環境でも同一バイナリを使用しよう

    60 真実を語るはコードのみ

      設計書は必ず正しいわけではない。最後はやっぱりコードが真実

    61 ビルドをおろそかにしない

      ビルドスクリプトを知らない人が多い。ビルドプロセスも勉強しよう

    62 プリミティブ型よりドメイン固有の型を

      コードの質が大きく向上するよ

    63 ユーザの操作ミスを防止する

      ユーザが操作ミスをしない仕組みをつくってあげよう

    64 プロのプログラマとは?

      「自分が責任を取る」という態度、責任感を持て。

    65 バージョン管理システムを有効に使う

      とにかく何でもバージョン管理していこう

    66 いったんコンピュータから離れてみる

      一旦離れると、新しい答えが見つかって解決することがあるよ。

    67 コードを読む

      本を読むより、他人のコードを読むほうが力がつくよ

    68 「人間」を知る

      相手を知れば、円滑にいくよ

    69 車輪の再発明の効用

      新しい発見を目指すと失敗が多いけど、大きな経験が出来る。

    70 シングルトンパターンの誘惑に負けない

      何でもシングルトンにすれば良いのではない。必要なインスタンスが絶対に1つという確信がある時以外は使わない。

    71 パフォーマンスへの道は地雷コードで敷き詰められている

      パフォーマンス改善には、コードの依存性や複雑さが問題になる。これらを計測することが大事。

    72 シンプルさは捨てることによって得られる

      コードはシンプルであるべき。良い部分を残して悪い部分は捨てる。または最初から書きなおすという気持ちを持っていれば、無駄なコードは書かなくなる

    73 単一責任原則

      変更する理由が同じなら集める。異なるなら分ける。

    74 「イエス」から始める

      否定から入らず、肯定から入れば、対立せずに協力関係が生まれるよ

    75 面倒でも自動化できることは自動化する

      自動化すれば対応工数が少なくなる

    76 コード分析ツールを利用する

      コード品質を高める為にコード分析ツールを利用すると良い

    77 偶然の仕様ではなく本物の仕様のためのテストを書く

      ホワイトボックスよりブラックボックステストの方が大事

    78 テストは夜間と週末に

      人がいない時のほうがマシンパフォーマンスが出やすいよ

    79 テストのないソフトウェア開発はあり得ない

      テストは時間がかかるけど、やっぱり大事

    80 1人より2人

      ペアプログラミングは色んな効果があるよ。成長。不意な退職など

    81 エラーがエラーを相殺してしまう

      ある箇所と別の箇所で矛盾が生じているとエラーが相殺されて、正常の動きに見えることがある。思い込みを捨てて、冷静さを保つことが大事。

    82 他者への思いやりを意識したコーディング

      プログラマは1人ではない。他社への思いやりが大事。

    83 UNIXツールを友にする

      UNIXツールを使いこなすと作業効率があがるよ

    84 正しいアルゴリズムとデータ構造を選ぶ

      アルゴリズム毎の効果と適用ケースを学べ

    85 冗長なログは眠りを妨げる

      重要なログは必要最低限にする

    86 WETなシステムはボトルネックが見つかりにくい

      DRY原則に反したシステムをWETなシステムと言う。

    87 プログラマとテスターが協力してできること

      開発当初から両者が協力すれば奇跡が起きる。テスターはソフトウェアを破壊するのが役目ではない。プログラマはテスターを邪魔をする敵と考えてはダメ。

    88 コードは生涯サポートするつもりで書く

      良くないコードを書いているとキャリアアップのチャンスも減るよ

    89 関数の「サイズ」を小さくする

      関数のサイズ(コード量だけでなく、取りうる値)を小さくするとバグが少なくなる

    90 コードを見る人のためにテストを書く

      良いテストはドキュメントの代わりになるよ

    91 良いプログラマになるには

      積極的に新しい言語に取り組む。分かりやすい、正しい、保守しやすいコードを書くよう心がける。一人ではなくチームでやっていることを意識する

    92 顧客の言葉はそのまま受け取らない

      顧客独自の言葉があるので確認すること

    93 エラーを無視するな

      小さなエラーもスルーしない。こまめに対応すれば後から楽になる

    94 リンカは魔法のプログラムではない

      リンカは複雑なことはしていない。エラーをちゃんと見ればヒントがあるよ

    95 ペアプログラミングと「フロー」

      完全に没頭している時をフロー状態という。この状態を維持するにはペアプログラミングあ有用だ

    96 テストは正確に、具体的に

      テスト仕様と予想結果はちゃんと書こう。

    97 ステートに注目する

      実行時に常にステートを意識しよう

    以前読んだソフトウェアアーキテクトが知るべき97のことについても、そのうちまとめます。既に内容は忘れました・・