私もこんな本を書いてみたかったと思うような,とても感覚に合う本でした.実際,紹介されている項目の多くはすでに私も実践している内容で,それほど目新しい内容ではありませんでした.どちらかというと,iPhoneを使うとこんなに便利になるんだよ,と他人に紹介したくなる本です.全ての情報をハンドヘルドデバイスに集約して日々持ち歩くというのは,Palmを使っていたときからのある種の夢でした.それがiPhoneというデバイスで当たり前のように可能となったことがとても感慨深いです.

本書は,ScanSnapやDropbox,Evernote,タスク管理など様々な手段によってiPhoneに情報を蓄積し,それをどう活用するかということについてまとめてあります.まず気になった項目は,07.裁断機です.以前 ScanSnap を購入する際には,複数の人に”裁断機もセットで”と薦められました.実際 ScanSnap で 電子化するのに慣れてくると,分厚い資料もぶった切って全部pdfとして取り込みたくなってきます.現在研究室にある裁断機は10枚も切れないので,何十枚も切れる裁断機が欲しくなってきます.問題は置き場所ですが.

23. Evernoteで人脈手帳というのは,名刺管理の発展としても面白いなと思いました.確かに名刺だけではなく,各人の写真やWebページのクリップなどを一人一ノートとしてまとめておくと,次に会うときに見直せて良いです.私は人の名前覚えるのが苦手なのでなおさらです.

29. Bluetoothヘッドセットについては,以前Twitterでも薦められたので気になっていました.数年前にSkype経由の電話会議用にと購入したことはあるのですが,結局有線のヘッドセットに落ち着いてしまいました.

iPhoneの電話機能は,とても静かな部屋でないとまともに使えません.外で使用すると相手に何度も聞き返されるし,相手の声もスピーカーモードにしてやっと聞き取れるくらいです.付属のヘッドフォンを使うと良いようなので,現在こちらから電話をかけるときにはそれを使うようにしています.しかし,私はインナータイプのヘッドフォンが好きではないので,できれば耳かけのbluetoothヘッドセットが欲しいなと思っていました.探したところ,SONY BT140Qが良さそうなので,注文してしまいました.使用感などについては手に入れてから書きたいと思います.

30-31.のiPhoneと紙の手帳の使い分けも気になるトピックです.以前書いたとおり私も紙の手帳を併用していますが,iPhoneでどこでもGoogle Calendar Syncができるようになってからは,スケジュールを手帳に書き写すのが少し面倒に思えてきました.海外出張が少ないことや,フリック入力に慣れてきたことも影響しています.紙が必要でなくなることはないのですが,もっとシンプルなものでも良いのかもしれません.ここらへんは考え中です.

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


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


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


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

以前書いたとおり,個人用のレポジトリはmercurial (hg)で管理しています.基本的な使い方は覚えているのですが,一度コマンドの内容を網羅したいと思い,入門mercurialを読んでみました.

各所にCVS/SVNでいままで管理してきた人向けの内容が書いてあるので,CVS/SVNから移行した人には良い本だと思いました.後,第5部のMercurial以外の世界との連携というトピックが良かったです.基のソースがCVS/SVNなどで管理されているときに手元の変更をどうやってmercurialで管理するかということについて,tipsがまとまっています.

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

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

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はバイト数ではなく文字数になります.逆にバイト単位用の仕様やメソッドも色々追加されています.その他,便利なメソッドが増えているようなので,一度標準ライブラリを確認し直した方が良さそうです.

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

「言語技術」が日本のサッカーを変える

外国語で発想するための日本語レッスン“の関連本です.ここでは”テクストの分析と解釈・批判”を単に”言語技術”としています.言語技術は,言い換えると論理的思考とコミュニケーション力です.欧州では,他の様々な分野でも言語技術が基礎となっていることを,サッカーのエリート教育を例にして紹介しています.

また,日本でどのようにサッカーに言語技術を取り入れていこうとしているかを,S級ライセンスの改革と,JFAアカデミーというエリート教育についての紹介を通して説明しています.

私はこの手のサッカー本は好きなのでたまに読みます.内容は確かに日本に足りないことの一つだと思うので興味深かったです.私も小学生のときはサッカー少年でしたが,一つ一つの動作に対して説明できるほど意味を考えながらプレーをしてはいませんでした.

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

外国語で発想するための日本語レッスン

この本は三森ゆりか氏の”外国語を身につけるための日本語レッスン”の続編です.この人は常に,日本の国語教育と欧米(特にヨーロッパ)の国語教育の差が,日本人が外国語学習する上で問題であるという主張をしています.この本ではその中でも”テクストの分析と解釈・批判 (critical reading)”について取り上げています.”テクストの分析と解釈・批判”とは,テクストに書かれている事実を様々な角度から分析し,それを根拠として客観的・論理的に解釈し,批判的な考察を行うための技術です.

欧米ではこの技術を習得するためのシステムが昔から存在します.最終的に”テクストの分析と解釈・批判”を誰もが行えるようになるために,子供は幼稚園の頃から国語教育として段階的に教わります.さらには,他の言語を学習する際にも同じ段階を踏みます.”テクストの分析と解釈・批判”について学ぶことが,言語学習での約束事になっているのです.それに対し,日本ではこのような技術は教えられていません.良い文学作品をとにかくたくさん読むことが良いという教え方です.また,日本での読解は,感覚的・主観的にテクストを鑑賞することです.例えば登場人物や作者の心情を問うことが多々あります.このような教育の違いが,日本人と欧米人の発想の違いに繋がっており,両者が議論をするときに議論がかみ合わなくなる原因の一つとなっているという主張です.

私もW3Cで働いていたときに,様々な面で外国人と日本人の差異を感じました.例えば外国人は,議論をする上で,常に議事録やメールなどに事実を求めます.過去このような議論があって云々という話をするときには,必ずそれが何時どこの議事録に書かれているのかを問われます.逆に言うと,議事録に書かれていなかったことは議論していないと同義です.それに対し,日本人は議事録に対する意識が薄いように感じます.W3Cで働く前はとある省庁のプロジェクトを2年ほど行っていましたが,過去の議事録がそのような形で活かされたことは一度もありません.なんとなく,議論が進んでいくことが多かったです.

この本の良いところは,ではどうすれば良いかという明確な解を書いていることです.段階的に”テクストの分析と解釈・批判”を学ぶための具体的な方法を提案しています.個人的に興味深かったのは”絵の分析”の部分です.私は絵の作者や何々派というのを覚えるのが苦手でしたし,絵を描くのも苦手でしたので,美術が嫌いでした.しかし,ここで述べられている方法は,絵の背景知識は一切必要ありません.絵に描かれている事実のみから内容を読み取っていくという方法です.例えば標識の色や線の使い方だけから何が読み取れるかなど.私は今まで絵やイラスト,デザインに対して苦手意識があったのですが,このような接し方なら興味が持てそうです.

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

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

プログラマの数学

結城さんは初学者にわかりやすい本を書くのがうまいですね.数学を避けてきた学部1年生が最初に読むには良い本だと思います.私は離散数学はマグロウヒルの本で勉強したのですが,いかにも教科書的なので数学に抵抗がある人にとってはとっつきにくいかもしれません.そういう人が先に読むには良いのではないでしょうか.

マグロウヒルの本が抵抗なく読める人にはあまり必要ないかと思います.

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

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