Mac 的な作法で MongoDB 2.0 をインストールする方法を gist に上げてみました。…………しかし何か見にくいですね。gist で見た方がいいかもです。gist はこちらです→How to install MongoDB 2.0 on Mac OS X (>= Leopard)
間違いや作法的におかしい部分などありましたら是非ご指摘頂ければと思います。
どうもおはこんにちばんは(?)、どらです。気軽に、「どらちゃん」と呼んで下さい。 原点回帰し、自分ドメインでのブログを開始しました。どうぞよろしくお願い致します。本家サイトはこちら(www.dora-gt.jp)。
2011/09/21
2011/09/20
【スーパーまとめ】メソッドのエラー処理を考える 高橋徹
Java でのエラー処理の方法についてまとめます。出典は、WEB + DB PRESS vol.51 「巧いメソッド設計 第六章 メソッドのエラー処理を考える」です。
【対象】
【事前条件チェックの注意点】
【対象】
- 言語は Java
- 「契約による設計」を採用した場合の実装方法
【そもそもエラーとは】
- A の条件の元、B という処理を行い、C という条件になったとする。
- この時、以下のものをエラーとする。
- A の条件が不正だった時は、B の呼び出し元のメソッドのバグによるエラー
- C の条件が不正だった時は、B のメソッドのバグによるエラー
【エラーの通知方法】
- 上記の様なエラーは、事前条件(A)チェック、および事後条件チェック(C)により検出ができるが、その通知方法は大まかに下記の3通りである。
- 戻り値による通知
- true/false や int などなどで返す事が考えられるが、メソッド本来の戻り値との切り分けが難しい
- 例外による通知
- B 自体のバグの場合、チェック例外(Exception のサブクラス)にしても呼び出し元が対処できる訳ではないので非チェック例外(RuntimeException のサブクラス)とする
- 例外に使用するクラスの使用基準があいまいである
- 非チェック例外の場合、ドキュメントに明記しておかないと例外仕様が不明瞭になってしまう
- アサーションによる通知
- 事前、事後のチェックを行い、エラーがあった場合には assert 文で通知する
- 記述が若干少なく、楽である
- 例外の型の問題はなく、コメントを付ければ例外仕様は分かりやすいという点において、例外による通知よりも使いやすい
- リリース時にオフにした場合、何も把握できなくなってしまう
- パッケージ、クラス単位でアサーションのオン / オフを指定する事ができるので、パフォーマンスが問題になるならそれを利用するという手も
プログラムの出荷時に表明(アサーション)をオフにすることは、綱渡りの練習を一度うまくやり終えただけで本番の綱渡りに挑戦するようなものです。ドラマチックな価値はありますが、生命保険は下りないでしょう。
※まとめ注:要するに出荷時にアサーションを一概にオフにする事はオススメしないと言っている
【事前条件チェックの注意点】
- 呼び出し側が条件の成立を判定できない条件を事前条件に含めてはならない。例えば、下記の様なものである。
- 外部からアクセスできない変数の値
- 処理を開始しないと判定できない事項
- そもそもプログラムで判定できない事項
- 下記の様なものは、「プログラム外部の異常」なので事前条件チェックには含めない
- DB と正しく接続できる事
- ハードディスクや RAM に十分な空きがある事
- ファイルが読み出し可能である事
2011/09/19
【スーパーまとめ】ロジカル・シンキング 照屋華子・岡田恵子
………結局、本の中でも書かれている様に、「判断基準」がビジネスのキモな訳ですが、これをどうやって相手に納得してもらうかは本当に難しいですね。全ての意思決定パターンについて期待値(売上など)をシミュレートして定量化なんてできないですし(やる人はやるのかも…でも効果は怪しい)、ある意味芸術の領域だと思います。だからこそ、真似のできない経営ってのも存在するんだと思いますけどね。
(以下まとめ)
【ビジネスにおけるコミュニケーションとは】
- 取引先、上司や部下などに対して自分(やその属する組織)の考えを適切に伝え、思い通りに動いてもらう事が肝要。
- それによって、より早く行動し、より早く・確実に成果に結びつける事ができる。
【ビジネスにおけるコミュニケーションを構成する要素】
ビジネスにおけるコミュニケーションでは、下記の要素を考慮したメッセージを相手に伝える必要がある。
- 課題
- そもそも自分の伝えようとしている事が課題と関係ない事柄であってはならない。
- 課題は、共通認識として、自分・相手の中で共有されている必要がある。
- 答え
- 「答え」は、下記の要素により構成されるべきである。
- 結論(最終的な答え)
- 根拠(何故その答えなのか)
- 方法(どうやってそれを実現するのか)
- 相手に期待する反応
- 相手に期待する反応を予め明確にしておく事。
- 期待する反応は、大まかに下記のいずれかである。
- 相手に「理解」をしてもらう
- 相手に「意見や助言、アドバイスをフィードバック」してもらう
- 相手に「行動」してもらう
- 話に重複や漏れがある
- MECE に物事を捉える(根拠・方法など)事が必要。
- MECE = Mutually Exclusive, Collectively Exhaustive(重複も漏れもない)な状態。
- 切り口は自分で考える以外にも、一般的に MECE である事が認められているフレームワーク(3C/4P/5Fs/7S/PEST 等々)を使うという手もある。
- ロジックが飛んでいる
- 課題から自分の結論まで、Why so? / So what? で各階層を繋げられる必要がある。
【「答え」を得るための方法】
- 根拠並列型
- 何故その結論(答え)に至るのかの根拠を並列の関係で列挙する。
- 各要素は MECE に構成されている必要がある。
- 解説型
- 解説型は、下記の要素により構成される。事実を収集し、それに対する判断基準を定義・明示した上で、導かれる結論を答えとする。
- 事実
- 判断基準
- 判断内容
- 事実は、MECE に整理しておく事。抜け漏れがあると思わぬ落とし穴にはまる可能性。
- 判断基準が相手にとっても納得できるものであるかどうかが肝要。課題とのコンテクストから外れたものを設定しない事。
【スーパーまとめ】シリコンバレーのDNA 南場智子
(以下まとめ)
【問題】
日本の、製造業以外の産業の世界に対するプレゼンスは小さく、特にインターネット業界では世界をリードする企業は一つも出ていない。
【理由】
【理由】
- インターネット業界のスピード感
- 既得権益・アセットに守られた業界ではなく、市場の評価をいち早く察知し、優れた意思決定を迅速に行う事が肝要。日本企業はそれが苦手。
- 柔軟な発想ができない
- 日本企業は多様性が少なく、多種多様な人材が入り交じるシリコンバレーの企業に比べると発想のスケールが圧倒的に小さい。
- ベンチャーキャピタルの未熟
- 地に足の付いた投資しかしない。リスクマネーを生み出さない。
- 世界で通用するベンチャーが出てこないと嘆く一方で、実際は世界を目指すベンチャーよりも地味な利益を出す企業を求めている。
- 世界への目の向け方
- 中途半端に規模があり目の肥えた日本市場をメインにしていると、そこに忙殺されてなかなか世界への一歩が出ない。
- 起業家への風当たり
- 日本では起業家を尊敬したり応援したりする気風が希薄すぎる。一度失敗すれば身ぐるみ剥がされ落伍者の烙印を押される日本と、2度3度とチャンスが与えられるシリコンバレーとは対照的。
- 規制・制度改革
- 本格派のベンチャーキャピタリスト
- 起業家精神の旺盛な若者
- エコシステム
- 海外起業家ネットワークのまるごと招致(?)
登録:
投稿 (Atom)