ここ数日 Perl を学んで分かった事 #Perl

　最近、会社では Perl を使います。Perl は中学生〜高校生の時にちょろっとやっただけで、しかもその時は独学だったのでものすっごいガラパゴスなコードを書いていました。しかし、仕事で使うとなるとそういう訳にはいかないので今勉強しているのですが、会社でコードを読んでいて「なんじゃこりゃ？？」と思って勉強して分かった事をちょっと書いてみようかと。

　Perl を今さら始める人ってのもかなり奇特だとは思いますが、まぁ何かの役に立てば。

• +{ } って？
• 結論から言えばただの無名ハッシュです。
• 何故プラスを付けるのかと言えば、それがブロックではなく無名ハッシュなんだと明示するため、ただそれだけです。
• 逆に、ブロックである事を明示したければ {; hogehoge} の様に、ブレースの中に ; を書きます。
• 関数呼び出しには & がいるんじゃないの？付いてないやつはなんなの？
• 関数呼び出しは「基本的には & を付けます」。ただ、それがコンテキスト上関数と分かるもの（例えば、それ以前に既に sub によって関数が定義されている時）に関しては、& を付けなくても動作します。
• なんか定義があいまいなので、個人的にはあくまで & を付けた方がいいだろうな、と思ってます。その方が単純に分かりやすい。
• リファレンスを参照しているはずなのに、中身が取れてしまう？
• 矢印記法（->）は、添字的なモノの間に挟まっている場合は省略できます。
• 添字的なモノとは、[] とか {} だと理解していますが、ちょっと怪しいので間違ってたらごめんなさい。
• 例えば、$a[0]->[0] は $a[0][0] と書く事もできます。
• なので、こちらのコードも動作します。
• 詳しくは「続・初めてのPerl」など参照の事…。

　Perl Mongers の方からすれば当たり前すぎる事かもしれないんですが、イチから学んでる人にとっては、この辺すら理解不能だったりするのでメモがてら書いてみました。

 

How to install MongoDB 2.0 on Mac OS X (>= Leopard)

　Mac 的な作法で MongoDB 2.0 をインストールする方法を gist に上げてみました。…………しかし何か見にくいですね。gist で見た方がいいかもです。gist はこちらです→How to install MongoDB 2.0 on Mac OS X (>= Leopard)

　間違いや作法的におかしい部分などありましたら是非ご指摘頂ければと思います。

【スーパーまとめ】メソッドのエラー処理を考える 高橋徹

　Java でのエラー処理の方法についてまとめます。出典は、WEB + DB PRESS vol.51 「巧いメソッド設計　第六章　メソッドのエラー処理を考える」です。

【対象】

• 言語は Java
• 「契約による設計」を採用した場合の実装方法

【そもそもエラーとは】

• A の条件の元、B という処理を行い、C という条件になったとする。
• この時、以下のものをエラーとする。
1. A の条件が不正だった時は、B の呼び出し元のメソッドのバグによるエラー
2. C の条件が不正だった時は、B のメソッドのバグによるエラー

【エラーの通知方法】

• 上記の様なエラーは、事前条件（A）チェック、および事後条件チェック（C）により検出ができるが、その通知方法は大まかに下記の３通りである。
1. 戻り値による通知
• true/false や int などなどで返す事が考えられるが、メソッド本来の戻り値との切り分けが難しい
2. 例外による通知
• B 自体のバグの場合、チェック例外（Exception のサブクラス）にしても呼び出し元が対処できる訳ではないので非チェック例外（RuntimeException のサブクラス）とする
• 例外に使用するクラスの使用基準があいまいである
• 非チェック例外の場合、ドキュメントに明記しておかないと例外仕様が不明瞭になってしまう
3. アサーションによる通知
• 事前、事後のチェックを行い、エラーがあった場合には assert 文で通知する
• 記述が若干少なく、楽である
• 例外の型の問題はなく、コメントを付ければ例外仕様は分かりやすいという点において、例外による通知よりも使いやすい
• リリース時にオフにした場合、何も把握できなくなってしまう
• パッケージ、クラス単位でアサーションのオン / オフを指定する事ができるので、パフォーマンスが問題になるならそれを利用するという手も

プログラムの出荷時に表明（アサーション）をオフにすることは、綱渡りの練習を一度うまくやり終えただけで本番の綱渡りに挑戦するようなものです。ドラマチックな価値はありますが、生命保険は下りないでしょう。 

※まとめ注：要するに出荷時にアサーションを一概にオフにする事はオススメしないと言っている 

【事前条件チェックの注意点】

1. 呼び出し側が条件の成立を判定できない条件を事前条件に含めてはならない。例えば、下記の様なものである。
1. 外部からアクセスできない変数の値
2. 処理を開始しないと判定できない事項
3. そもそもプログラムで判定できない事項
2. 下記の様なものは、「プログラム外部の異常」なので事前条件チェックには含めない
1. DB と正しく接続できる事
2. ハードディスクや RAM に十分な空きがある事
3. ファイルが読み出し可能である事

【スーパーまとめ】ロジカル・シンキング 照屋華子・岡田恵子

　今回は前回の「日本の未来について語ろう」ではないですが「ロジカル・シンキング　論理的な思考と構成のスキル（照屋華子・岡田恵子）」という本のスーパーまとめを書いてみます。

　………結局、本の中でも書かれている様に、「判断基準」がビジネスのキモな訳ですが、これをどうやって相手に納得してもらうかは本当に難しいですね。全ての意思決定パターンについて期待値（売上など）をシミュレートして定量化なんてできないですし（やる人はやるのかも…でも効果は怪しい）、ある意味芸術の領域だと思います。だからこそ、真似のできない経営ってのも存在するんだと思いますけどね。

（以下まとめ）

【ビジネスにおけるコミュニケーションとは】

• 取引先、上司や部下などに対して自分（やその属する組織）の考えを適切に伝え、思い通りに動いてもらう事が肝要。
• それによって、より早く行動し、より早く・確実に成果に結びつける事ができる。

【ビジネスにおけるコミュニケーションを構成する要素】

　ビジネスにおけるコミュニケーションでは、下記の要素を考慮したメッセージを相手に伝える必要がある。

1. 課題
• そもそも自分の伝えようとしている事が課題と関係ない事柄であってはならない。
• 課題は、共通認識として、自分・相手の中で共有されている必要がある。
2. 答え
• 「答え」は、下記の要素により構成されるべきである。
1. 結論（最終的な答え）
2. 根拠（何故その答えなのか）
3. 方法（どうやってそれを実現するのか）
3. 相手に期待する反応
• 相手に期待する反応を予め明確にしておく事。
• 期待する反応は、大まかに下記のいずれかである。
1. 相手に「理解」をしてもらう
2. 相手に「意見や助言、アドバイスをフィードバック」してもらう
3. 相手に「行動」してもらう

【説得力のない答えとは、またその解決策】

1. 話に重複や漏れがある
• MECE に物事を捉える（根拠・方法など）事が必要。
• MECE = Mutually Exclusive, Collectively Exhaustive（重複も漏れもない）な状態。
• 切り口は自分で考える以外にも、一般的に MECE である事が認められているフレームワーク（3C/4P/5Fs/7S/PEST 等々）を使うという手もある。
2. ロジックが飛んでいる
• 課題から自分の結論まで、Why so? / So what? で各階層を繋げられる必要がある。

【「答え」を得るための方法】

1. 根拠並列型
• 何故その結論（答え）に至るのかの根拠を並列の関係で列挙する。
• 各要素は MECE に構成されている必要がある。
2. 解説型
• 解説型は、下記の要素により構成される。事実を収集し、それに対する判断基準を定義・明示した上で、導かれる結論を答えとする。
1. 事実
2. 判断基準
3. 判断内容
• 事実は、MECE に整理しておく事。抜け漏れがあると思わぬ落とし穴にはまる可能性。
• 判断基準が相手にとっても納得できるものであるかどうかが肝要。課題とのコンテクストから外れたものを設定しない事。

【スーパーまとめ】シリコンバレーのDNA 南場智子

　「スーパーまとめ」シリーズと題しまして、2011/7/1 に発売された「日本の未来について話そう　−日本再生への提言−」をちょっとずつまとめてみる事にしました。基本的に文章を自分が理解するために行うので、不定期かつ勝手に止めたりするかもしれないので期待しないで下さい（笑）　第一回目は元 DeNA CEO の南場氏の「シリコンバレーのDNA」です。

（以下まとめ）

【問題】

　日本の、製造業以外の産業の世界に対するプレゼンスは小さく、特にインターネット業界では世界をリードする企業は一つも出ていない。

【理由】

1. インターネット業界のスピード感
• 既得権益・アセットに守られた業界ではなく、市場の評価をいち早く察知し、優れた意思決定を迅速に行う事が肝要。日本企業はそれが苦手。
2. 柔軟な発想ができない
• 日本企業は多様性が少なく、多種多様な人材が入り交じるシリコンバレーの企業に比べると発想のスケールが圧倒的に小さい。
3. ベンチャーキャピタルの未熟
• 地に足の付いた投資しかしない。リスクマネーを生み出さない。
• 世界で通用するベンチャーが出てこないと嘆く一方で、実際は世界を目指すベンチャーよりも地味な利益を出す企業を求めている。
4. 世界への目の向け方
• 中途半端に規模があり目の肥えた日本市場をメインにしていると、そこに忙殺されてなかなか世界への一歩が出ない。
5. 起業家への風当たり
• 日本では起業家を尊敬したり応援したりする気風が希薄すぎる。一度失敗すれば身ぐるみ剥がされ落伍者の烙印を押される日本と、２度３度とチャンスが与えられるシリコンバレーとは対照的。

【解決策】

1. 規制・制度改革
2. 本格派のベンチャーキャピタリスト
3. 起業家精神の旺盛な若者
4. エコシステム
5. 海外起業家ネットワークのまるごと招致（？）

※何故その施策なのかの具体的な記述はない