ビジュアライジング・データ

1月に読んだままの本.情報視覚化(情報可視化とも言う)について教えてくれる本だと期待して買ったのですが,実際にはProcessing入門のような本でした.Web上で取得できるデータを加工して視覚化する方法が実例で書かれています.以前取り上げた集合知プログラミングを補完する本だと思いました.

1章で,情報視覚化のプロセスについて述べられています.この7つのステップが本書の内容の全てです.後は,実際にこれらのステップをどのように取捨選択して適用していくのか,また,ステップ間でどのような相互作用があるのかという話になります.

  1. データ収集 (acquire)
  2. 解析 (parse)
  3. フィルタリング (filter)
  4. マイニング (mine)
  5. 表現 (represent)
  6. 精微化 (refine)
  7. インタラクション (interact)

Processingについては去年知ったのですが,なかなか面白いです.Javaで手軽に2D graphicsを書くための簡易言語なのですが,HTML5 CanvasとProcessing.jsを使うと,コードをそのままブラウザ上で動かすこともできるそうです .Raphaëlといい,手軽にブラウザ上で動かせるgraphicsの選択肢が増えるのは良いことだと思います.

アマゾンのサーバでエラーが起こっているかもしれません。
一度ページを再読み込みしてみてください。

ザ・マインドマップ – 脳の力を強化する思考技術

今までマインドマップには興味があったのですが内容を知らなかったので,マインドマップを発案した人の本を読みました.まだ実際に使用してはいないのですが,論文やプレゼンなどの応用例をは試してみたいと思います.

全体を通してみると,マインドマップはブレインストーミングの一手法で,その整理方法が肝です.アイデアを出すプロセス自体は珍しくありません.テーマを中心にキーワードを挙げ,そこから連想されるキーワードをつないでいきます.その後キーワード群の整理や再構築を繰り返すことで完成度を高めるという方法です.ここでポイントなのは,キーワードの挙げ方や整理方法です.マインドマップではテーマや主張を中心としてキーワードの枝を描いていきます.さらにキーワードから連想するキーワードを新たな枝として,尽きるまで追加していきます.書式として,色や図形,絵を積極的に使うことを重視しています.視覚的に強調することで記憶や創造性が高まるためです.

興味深かったのは,グループでの利用です.従来のブレインストーミングでは誰かが筆記役となり,参加者のアイデアを黒板なり紙なりにまとめていくことが多いです.しかし,この本が主張する手順は異なります.

  1. テーマについて,まず個人で1時間程度マインドマップを作成
  2. グループを少人数のグループに分割し,各自のマインドマップを元に前向きなディスカッション
  3. グループ全体でマインドマップのたたき台を作成
  4. 休憩後,1-3を繰り返して再構築

最初に参加者各々が思考する時間を与えているのが特徴です.グループディスカッションの企業での応用例として,ボーイングの成果が載っていました.

ボーイング社では,技術マニュアルを長さ約8メートルのマインドマップにまとめている.その結果,従来は上級航空技師チーム100人の研修を行うのに数年かかったが,それをわずか数週間に短縮する異に成功し,約1100万ドルのコストが削減された. (p.160)

本には8メートルマップの写真も掲載されています.マインドマップを使用することでこれだけ効果があったのだとしたら,逆にいままでどういう研修をしていたのかが気になるところですが.

また,海外では教育機関でも採用されつつあるようです.韓国と中国の例が載っていました.

マインドマップは,日本以上に,他のアジア諸国で急速に広がっている.韓国では義務教育課程で,マインドマップが教えられるようになった.また,中国では2008年のペキンオリンピックをきっかけに,市民一人一人が英語100後を覚える運動が行われており,そのための教育ツールとしてマインドマップが公式に採用されていると聞く.(p.304)

ブザン・ワールドワイド・ジャパンのプレスリリースによると,2006年の時点で10ヶ国以上の公的教育機関で採用されているようです.日本では,学校で個別に導入してみたという事例は目にするのですが,義務教育として導入するという話は聞いたことがないですね.実際にマインドマップが良い方法なのかどうかはわかりませんが,何かしらのアイデアの出し方というのは教えても良いのかなと感じます.

アマゾンのサーバでエラーが起こっているかもしれません。
一度ページを再読み込みしてみてください。

プログラミング Erlang

Erlangの作者 Joe Armstrongが書いた本の翻訳本を読みました.マルチコアなプロセッサや分散環境が手軽に使える時代なので,平行指向かつ分散指向なプログラミング言語である Erlangは気になっていました.ロックによる状態共有のプログラミングは皆が正しく行うには難しいので,プログラミング言語としてサポートするのは正しいと思うのです.今すぐ使うわけではないので,簡単な逐次実行から並列処理のサンプルを試しただけですが,新しい言語を学ぶのは楽しいですね.文法部分にPrologの影響を受けた関数型言語という感じです.

束縛した変数が不変で,かつプロセス間メッセージパッシングで処理を行うモデルなので,状態の共有はほとんどありません.そのため,安全に平行処理ができるというのがウリです.サーバーを書くには向いていると思います.文字列はただの数字の配列という扱いなので,文字列処理には向いていなさそうです.Erlang Tipsを見ると正規表現ライブラリもあるようですが,試してはいません.

アマゾンのサーバでエラーが起こっているかもしれません。
一度ページを再読み込みしてみてください。

Beautiful Code

著名なプログラマー達が,自分が今まで出会った中で”美しい”と思っているコードについて述べている本.人によって”美しい”の定義が異なるので,アルゴリズム,テスト,アーキテクチャ,並列処理など,内容が多岐にわたります.

自分が考える美しいコードとは,簡潔で,短く,容易に可読なコードです.本書でも,多くの方々が同様の意見を述べていましたので,抜粋してみました.

ロブは,さまざまな選択肢の中から,非常に小さいが,重要であり,うまく定義された,拡張可能な一群の機能を選択したという点で賞賛されるべきです.

ロブの実装それ自体も,コンパクトでエレガントで,効率的で,実用性があるという点で美しいプログラムの最上の例です.(p.3 Brian Kernighan)

コードを削ることで機能を追加しなさい.(p.40 Jon Bentley)

美しいコードは,理解が容易でなければいけません.開発者の言語知識をひけらかすために書かれたようなコードは,私は大嫌いですし,あるコードが実際に何をやっているのかを理解するために25行以上コードを読み進む必要があるべきではありません. (p.277 by Adam Kolawa)

要約すると美しいコードとは,短くて,明確で,質素で,現実を考えて書かれている物だと,私は信じています.(p.282 by Adam Kolawa)

私はコードをリファクタリングして追加した行数より削除した行数の方が多いとき,いつも得意な気分になります.(p.306 by Diomidis Spinellis)

Pythonを開発していて,最初はいろいろ最適化するのがよいと思ったけれども,結局は比較的素朴な実装の方が好ましい,と気づく場合がありました.要するに物事はシンプルに保っておくことが得な場合が多いのです.(p.310 Andrew Kuchling)

並列プログラムは非決定的に実行されるため,テストは困難であり,バグはほとんど再現できません.ですから私にとっては,美しいプログラムとは,単に明らかな間違いがないという物ではなく,明らかに間違いがないと一目でわかるような単純でエレガントなプログラムのことを言います(この表現はC.A.R.ホーアによるものです).(p.405 Simon Peyton Jones)

プログラムの美しさを構成する要素の一つは「簡潔さ」です.Paul Grahamもエッセイで「簡潔さは力なり」と語っています.ですから簡潔に記述できることはプログラミング言語にとって絶対の善なのです. (p.504 by まつもとゆきひろ)

それぞれ実際に言及している分野はばらばらなのですが,それでもほとんど同じことを言っていると思います.

取り上げられていたアルゴリズムで美しいと思うのはニ分探索 (binary search) です.しかし,これだけ単純で古いアルゴリズムでも,最近まで実装にバグがあったというのには驚きます.”Extra, Extra – Read All About It: Nearly All Binary Searches and Mergesorts are Broken – Google Research Blog”にその詳細が載っています.


1:     public static int binarySearch(int[] a, int key) {
2:         int low = 0;
3:         int high = a.length - 1;
4:
5:         while (low <= high) {
6:             int mid = (low + high) / 2;
7:             int midVal = a[mid];
8:
9:             if (midVal < key)
10:                 low = mid + 1
11:             else if (midVal > key)
12:                 high = mid - 1;
13:             else
14:                 return mid; // key found
15:         }
16:         return -(low + 1);  // key not found.
17:     }

上記のコード(元ブログから引用)の6行目 int mid = (low + high) / 2;でlow+highが231-1より大きくなるとき,符号が反転してmidがマイナスになります.そのため7行目の配列アクセスで失敗します.これを回避するためにはint mid = (low + high) >>> 1とすれば良いです.>>>は右シフト演算で符号を落とします.または明示的にunsignedで実装する必要があります.

その他にも,MapReduceなど,色々載っています.通して読むよりは,興味がある章を拾い読みするのが良いかなと思います.

アマゾンのサーバでエラーが起こっているかもしれません。
一度ページを再読み込みしてみてください。

プログラミング言語Ruby

この本がPerlのラクダ本扱いになるのかはわからないですが,Rubyでプログラムを書いている人は一度目を通す価値ありだと思います.Rubyは使い始めてから結構年数が経ちますが,細部で知らないことが結構ありました.例えばcloneとdupの違い.対象がfreezeの場合,cloneはそのままコピーしますが,dupはfreezeを外します.また,cloneはオブジェクトの特異メソッドもコピーします.splat演算子というのも使ったことがないです.

Procとlambdaの扱いの違いも知りませんでした.returnやbreakなどの制御構文で違う動作をします.また,lambda はメソッド扱いなので引数の数が厳密にチェックされるそうです.Ruby1.9 にはlambdaかProcかを判別できるようにlambda?メソッドが追加されています.

Ruby1.9についてはまったく知らなかったので,かなり参考になりました.仕様としては,エンコーディングのサポートと,文字の単位がエンコーディング依存になるのが一番大きい変更のようです..lengthはバイト数ではなく文字数になります.逆にバイト単位用の仕様やメソッドも色々追加されています.その他,便利なメソッドが増えているようなので,一度標準ライブラリを確認し直した方が良さそうです.

アマゾンのサーバでエラーが起こっているかもしれません。
一度ページを再読み込みしてみてください。

  • アマゾンのサーバでエラーが起こっているかもしれません。
    一度ページを再読み込みしてみてください。

  • アマゾンのサーバでエラーが起こっているかもしれません。
    一度ページを再読み込みしてみてください。

  • アマゾンのサーバでエラーが起こっているかもしれません。
    一度ページを再読み込みしてみてください。

  • アマゾンのサーバでエラーが起こっているかもしれません。
    一度ページを再読み込みしてみてください。

  • アマゾンのサーバでエラーが起こっているかもしれません。
    一度ページを再読み込みしてみてください。

  • アマゾンのサーバでエラーが起こっているかもしれません。
    一度ページを再読み込みしてみてください。

  • アマゾンのサーバでエラーが起こっているかもしれません。
    一度ページを再読み込みしてみてください。

  • アマゾンのサーバでエラーが起こっているかもしれません。
    一度ページを再読み込みしてみてください。

  • アマゾンのサーバでエラーが起こっているかもしれません。
    一度ページを再読み込みしてみてください。

  • アマゾンのサーバでエラーが起こっているかもしれません。
    一度ページを再読み込みしてみてください。