無差別に技術をついばむ鳥

こんにちは。何も書くことがなくて困っているインドリです♪
今日は各ネタがないなー。ということで、今考えている事を取り留めもなく書いてみます。
Java7はいつ出るんだろう。私が聞いた噂では今年らしいけど・・・
ただ、Java7にあんまり期待していなかったりします。だってクロージャさえないらしいからね。
そうなれば、別にScalaでもいいような気がします。
ただし、念のために書いておきますが、私はJavaを馬鹿にしているのではありません。
Java仮想マシン仕様を読んだことがあるのですが、非常によくできています。
それ故に、Java仮想マシンを実装したい欲求にかられます。
その証拠に、Java仮想マシン上で動く言語が沢山開発されています。
もしJava仮想マシンに魅力がなければ誰も作らないでしょう。
ということは、もしかしてJavaはある意味完成してしまったのかな？

それはそうと、Perl6はどうなったんだろう？
Java7よりもこちらの方が見えてこない・・・
Perlはうだいぶ触っていないので忘れたのですが、Perl6が登場したらまた触りたくなるかも知れない。

それにしても、最近の言語はみんな仮想マシン上で動きますね。
個人的にはネイティブなシステム言語も頑張ってほしいものです。
システムソフトを作る時Cばかりじゃあ面白くありません。
まぁ、SchemeでOSを実装した兵がいるそうだから、別にC言語でなくても実装できるようだけど・・・
これは凄過ぎます。OSのメモリ管理機構はどうしたのでしょうか？
GC上でメモリ管理機構が動いているのでしょうか？まさかOSにメモリ管理機能がないということはないよね？
うーん、実に興味深いです。今後OSとGCについて調べてみます。

おっと、気が付いたら意外と書けていました。
これぐらいでいいと思いますのでそろそろ終わります。
ではまた明日会いましょう。

テーマ : 裏事情
ジャンル : 謎

こんにちは。本を無差別に読むインドリだよ♪
ここ最近ようやく気付いたのですが、専門書以外にも読むべき本ってありますね。
私は貧乏だから情報処理技術に特化して投資するつもりで専門書だけを読み、他の書籍ははっきりいって軽視していましたが、 学習法やビジネス書を読む必要があると考えなおしました。
というのも、学習法は自分というハードウェアを如何にしてバージョンアップさせるかを示すアルゴリズムですし、 ビジネス書には他の業種の人が考えた知恵が詰まっている事に気付いたからです。
私は自分が不器用で頭が悪いと考えていたから他の事をやるスペックはないと判断しておりましたが、今から考えてみればスペックが悪いからこそ学習法とビジネス本は読むべきでした。
それに、背門書しか見ていなかったからわからなかったけど、案外本って安いですね。学習法とビジネス本は大概1000円以内で買えます。金銭感覚が変になって、本は4000円ぐらいが相場だと思っていました（笑）
それで、ここ数日は散歩のついでに本屋に行って速読しています。今まで注意を払っていなかったから知らなかったけども、本当に色々な本がありますね。胡散臭い本、本当によさそうな本、題名でインパクトを与える本、面白本・・・ 私は元々本そのものが好きなので、色々な本があって本当に楽しいです♪
そういえば、最近は本離れが叫ばれているけど、なんであんな面白いもの読まないんだろう？ 興味は人それぞれだろうけど、本はかなりの数のジャンルがあるから気に入る本は絶対にあると思うんだけどなぁ・・・
インターネットに依存して、それだけが全てな人もたまにいるけども、情報はインターネットだけにあるのではなく、本にしかない情報も多々あります。
それにも関らず、最近ウイキペディアが全ての人が居るから不思議です。専門書を読めば記述が不十分だと気づく筈です。だから、他分野の情報も不十分だと容易に推測できます。そういった人はもしかして本を読んでいないのかな？
なにはともあれ、みんなもっと本を読んでほしいな。出版業界が不景気だとよく耳にしますが、こんなためになる面白いものを絶やしてはなりません。出版社がなくなり、本がなくなったら困るのは目に見えています。
もっと本を読もう！

テーマ : 裏事情
ジャンル : 謎

どうもこんにちは♪読みたい本が多すぎて困っているインドリです♪
この本が読みたいんだけど、仕事に必要な分野と英語と数学の学習で忙しくて読めないorz



まだ、ちょっとしか読んでいないし、文体が堅いから読み辛い本だけど内容そのものはすごくいいと思います。
タイプ的には私が大好きなこの本



と似ています。どちらの本も本当に名著だから未読のひとは、一刻も早く読んだ方がいいと思います。
もう一層のこと英語と数学の学習を一旦休んで、読んじゃおうかな♪計算機プログラムの構造と解釈を本格的に読む日が非常に楽しみです♪この本を読めば、きっと技術力がアップするに違いない！
それはさておき、社会人になるとどうしても学習時間が足りなくなりますよね。特にこの業界では変化が早いので、それらを徹底的にマスターしようとすればいくら時間があっても足りません。そこは、学習法を工夫したり、己の頭を鍛えるしかないですよね。 大変といえば大変なのですが、これがまた情報処理技術の魅力でもあるので楽しいです♪
それにしても、OZは凄過ぎます！これほどの言語を設計＆実装する技術力が欲しいです。 OZを設計＆実装できるレベルに到達するべく自信を鍛えあげます。私は凡人だからとにかく努力するしかないからね♪

テーマ : 裏事情
ジャンル : 謎

今日は日記を書いていたらこの名著を紹介するのを忘れていた事に気付いたピヨ♪
オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)
オブジェクト指向を知りたい時、この書籍は必読ピヨ♪

【目次】
パートA　諸問題
第1章　ソフトウェアの品質
1.1　外的品質要因と内的品質要因
1.2　外的品質要因
1.3　ソフトウェアの保守について
1.4　本章のまとめ
1.5　参考文献
第2章　オブジェクト指向の基準
2.1　基準について
2.2　方法論と言語
2.3　実装と環境
2.4　ライブラリ
2.5　もっと詳しい予告編
2.6　参考文献とオブジェクトのリソース
パートB　オブジェクト指向への道
第3章　モジュール性
3.1　5つの基準
3.2　5つの規則
3.3　5つの原則
3.4　本章のまとめ
3.5　参考文献
3.6　演習問題
第4章　再利用性へのアプローチ
4.1　再利用性の目標
4.2　何を再利用すべきか？
4.3　ソフトウェア開発における繰り返し
4.4　「非」技術的障害
4.5　技術的な問題
4.6　モジュール構造の5つの要件
4.7　伝統的なモジュール構造
4.8　多重定義と総称性
4.9　本章のまとめ
4.10　参考文献
第5章　オブジェクト技術への道
5.1　コンピュータ処理の中身
5.2　機能による分解
5.3　オブジェクトによる分解
5.4　オブジェクト指向によるソフトウェア構築
5.5　課題
5.6　本章のまとめ
5.7　参考文献
第6章　抽象データ型
6.1　基準
6.2　実装のバリエーション
6.3　オブジェクトを抽象的に見るには
6.4　仕様記述を形式化する
6.5　抽象データ型からクラスへ
6.6　ソフトウェアを越えて
6.7　補助的な話題
6.8　本章のまとめ
6.9　参考文献
6.10　演習問題
パートC　オブジェクト指向の技法
第7章　静的な構造：クラス
7.1　オブジェクトは主体ではない
7.2　ありがちな混乱を避けるために
7.3　クラスの役割
7.4　一様な型体系
7.5　単純なクラス
7.6　基本的な構文規約
7.7　オブジェクト指向的なスタイル
7.8　選択的エクスポートと情報隠蔽
7.9　すべてを1つにする
7.10　検討
7.11　本章のまとめ
7.12　参考文献
7.13　演習問題
第8章　実行時の構造：オブジェクト
8.1　オブジェクト
8.2　モデリングツールとしてのオブジェクト
8.3　オブジェクトと参照を操作する
8.4　生成プロシージャ
8.5　さらに参照について
8.6　参照に対する操作
8.7　複合オブジェクトと拡張型
8.8　アタッチメント：参照と値の意味
8.9　参照を扱うということ：利点と危険
8.10　検討
8.11　本章のまとめ
8.12　参考文献
8.13　演習問題
第9章　メモリ管理
9.1　オブジェクトに何が起きるのか
9.2　呑気なアプローチ
9.3　メモリの回収に関する諸問題
9.4　プログラマ制御による開放（デアロケーション）
9.5　部品レベルのアプローチ
9.6　自動領域管理
9.7　参照カウント
9.8　ガーベジコレクション
9.9　ガーベジコレクションの実用上の諸問題
9.10　領域管理を備えた環境
9.11　本章のまとめ
9.12　参考文献
9.13　演習問題
第10章　総称性
10.1　水平方向と垂直方向の型の汎化
10.2　型のパラメータ化の必要性
10.3　総称クラス
10.4　配列
10.5　総称性のコスト
10.6　議論：これで終わりではない
10.7　本章のまとめ
10.8　参考文献
10.9　演習問題
第11章　契約による設計：信頼性の高いソフトウェアを構築する
11.1　基本的な信頼性のメカニズム
11.2　ソフトウェアの正しさについて
11.3　仕様を書く
11.4　ソフトウェアテキストに表明を導入する
11.5　事前条件と事後条件
11.6　ソフトウェア信頼性のための契約
11.7　表明を用いた作業
11.8　クラス不変表明
11.9　クラスが正しいのはいつか？
11.10　ADTとの関係
11.11　表明命令
11.12　ループ不変表明と変化表明
11.13　表明を使う
11.14　検討
11.15　本章のまとめ
11.16　参考文献
11.17　演習問題
第12章　契約が破られるとき：例外処理
12.1　例外処理の基本概念
12.2　例外処理
12.3　例外メカニズム
12.4　例外処理例
12.5　rescue句の仕事
12.6　高度な例外処理
12.7　検討
12.8　本章のまとめ
12.9　参考文献
12.10　演習問題
第13章　支援メカニズム
13.1　非オブジェクト指向ソフトウェアへのインタフェース
13.2　引数渡し
13.3　命令
13.4　式
13.5　文字列
13.6　入出力
13.7　識別子に関する語彙的慣例
13.8　本章のまとめ
13.9　演習問題
第14章　継承入門
14.1　多角形と長方形
14.2　多相性
14.3　継承のための型付け
14.4　動的束縛
14.5　暫定特性と暫定クラス
14.6　再宣言の方法
14.7　継承の意味
14.8　暫定クラスの役割
14.9　検討
14.10　本章のまとめ
14.11　参考文献
14.12　演習問題
第15章　多重継承
15.1　多重継承の例
15.2　特性の改名
15.3　構造をフラットにする
15.4　反復継承
15.5　検討
15.6　本章のまとめ
15.7　参考文献
15.8　演習問題
第16章　継承のテクニック
16.1　継承と表明
16.2　グローバルな継承構造
16.3　凍結型特性
16.4　制約付き総称性
16.5　試行代入
16.6　型付けと再宣言
16.7　アンカー宣言
16.8　継承と情報隠蔽
16.9　本章のまとめ
16.10　参考文献
16.11　演習問題
第17章　型付け
17.1　型付けの問題
17.2　静的型付け：「なぜ」と「どうして」
17.3　共変性と子孫隠蔽
17.4　システム妥当性への最初のアプローチ
17.5　アンカー型に任せる
17.6　グローバル分析
17.7　多相的catcallに気づく
17.8　評価
17.9　完全な適合
17.10　本章のまとめ
17.11　参考文献
第18章　グローバルオブジェクトとグローバル定数
18.1　基本型の定数
18.2　定数の利用
18.3　クラス型定数
18.4　onceルーチンの応用
18.5　文字列型定数
18.6　ユニーク値
18.7　検討
18.8　本章のまとめ
18.9　参考文献
18.10　演習問題
オブジェクト技術用語集
参考文献
E.1　筆者以外の人の著作
E.2　筆者の著作 

目次を見たらこの書籍の濃さは伝わると思うピヨ♪濃い本が大好きなボクは喜んで買ったピヨ♪それで、この本はどういった本なのかというとバーランド・メイヤー氏が考えだしたオブジェクト指向方法論をみっちり解説した本だっピヨッ♪勘違いして欲しくないんだけど、これはあくまでも数あるオブジェクト指向方法論の内の一つ本だっピヨ。でもボクはこの本を読むことを強くお勧めするピヨ♪
これからその理由を話すピヨ。それは、契約指向なオブジェクト指向を学べるからなんだ。契約指向とは何かというと、オブジェクトが果たすべき役割と責任をきっちり決めて、各メソッドの事前契約（メソッドが実行する前の契約）・事後契約（メソッドを実行した後の契約）・不変表明（どのような状態を保証するのかを定めた契約）を定めていく考え方の事を指して言っているピヨ。Windows系開発者の方は攻撃的デバッグを知っていると思う。そうこの有名な本（.NET&Windowsプログラマのためのデバッグテクニック徹底解説）で紹介されている事ピヨ。
それで、契約指向の何が美味しいのかというと、先ずはユニットテストが行いやすくなる点が挙げられるピヨ。実務でオブジェクト指向でシステム設計した時、何が問題になると思う？それは、要求仕様が変化しても品質を保つことなんだ。開発現場に居る人にとって常識だと思うけど、お客様の要求は常に変わるピヨ。時は全てを帰るからそれも当然だよね。だけど、従来開発方法（プロセス指向・データ指向）ではその変化に対応し辛いんだ。だけど、その中で品質を保つ事はプロとして当然要求される。じゃあどうしたらいいのかというと、オブジェクト指向になるんだけど、でもオブジェクト指向は実のところ一意な概念ではないピヨ。
オブジェクト指向をしたら、要求分析は具体的にどうすればいいの？設計は具体的にどうすればいいの？開発作業はどうやって進めればいいの？・・・といった点が問題になってくるピヨ。その時、ただ無闇に「オブジェクトで考えろ」といっても何も解決しないピヨ。そこで、バーランド・メイヤー氏は個々のオブジェクトが果たすべき役割と責任に注目してオブジェクト指向開発をすると提唱しているんだ。 ここがポイントで、オブジェクトを契約指向で考えたらどうして品質が上がるのかの答えがここにあるピヨ。彼が個々のオブジェクト（クラス）に拘っている点に注意しよう。システム全体で常にテストをするのは難しいけど、個々のオブジェクトだとテストするのは簡単だよね♪
おまけに、単体で考えるから再利用しやすいクラスが作れる可能性が高いピヨ♪これが契約指向する2つ目の利点なんだ。 オブジェクト指向のメリットは再利用だとよく言われてるけど、実際に再利用しようと思ったら汎用的なオブジェクトでなければならない。特殊な環境や問題に特化したオブジェクトは再利用しようがないからね。その点、メイヤー氏のオブジェクト指向方法論は、個々にオブジェクト（クラス）に注目し、処理順序に依存することを極力避けるので再利用しやすいオブジェクトが出来上がるピヨ♪
ここまで一生懸命説明したけど、普通はよくわからないよね？その答えは・・・この本を読もう！この本を読んだらオブジェクト指向とは一体何なのかという一つの答えが得られると思う。オブジェクト指向を真面目に学習したい人は絶対に読もう！


【補足】
他の本も知りたいという人は、書籍レビュー目次と書籍レビューを見ると良いピヨ♪

テーマ : 情報処理技術
ジャンル : コンピュータ

皆様おはようございます♪専門書を愛するインドリです♪
昨日、また読みたくなって、この本を読んでいました♪



バートランド・メイヤー氏はすごいですよね。オブジェクト指向方法論は数あれど、有名でなおかつ分析・設計・実装の全てを持論内にきっとり納めているオブジェクト指向方法論は彼だけだと思います。
また、その思想もすごいです。彼の契約による設計は攻撃的デバッグとの相性がいい事ですし、契約は他の方法論を採用したとしても使いたいです。流石コンパイラの作者だけあります。
オブジェクト指向は一意だと誤解している人が多いけども、抽象的でもあるので多くの方法論が存在します。 その方法論をどのように実践するのかが分析者や設計者の腕の見せ所です。
スリーアミーゴスも各々優れた理論を提供していますし、UMLは多くの方法論を取り入れたものになっておりますので、その状況に応じて各方法論の優れた部分を取り入れるのが実践的です。実際私はそうしておりますし、オブジェクト指向をちゃんと学習しているSEもそうしていることでしょう。
そういったオブジェクト指向の柔軟性が利点であり、同時に弱点でもあるとよく私は感じます。オブジェクト指向って実のところ実態があるようでない。ないようである非常に抽象的な理論です。その抽象さもしくは柔軟さが学習する人を困らせているのは確かです。
とはいえ、オブジェクト指向はプロの理論ですから、初心者にこびるのではなく、実践的でなければなりません。 実践的であるにはこうなるのは当然のことなのですが、万人に習得しやすい理論は構築不可能なのです。しかし、教育面に問題があると私は考えております。
私は日本のオブジェクト指向がそれほど普及しているとは思えませんし、ちゃんとした教育がなされているとは思えません。初期のオブジェクト指向の宣伝が過剰で、実態を表したものではなかったし、あまりにも分析と設計がおざなりになっております。それ故、プログラミングが出来なくとも設計が出来ると誤解されているのでしょう。 ちゃんと学習していれば、そんな誤解をする筈がありません。
さらに、スリーアミーゴズの書籍は軒並み絶版ですし、今から分析と設計を学習する人は、メイヤー氏の本を読むしかないでしょう。でも、オブジェクト指向が一意だと誤解するのは非常に問題です。どうにかならないものかな・・・

テーマ : 裏事情
ジャンル : 謎

おっはー♪今日も元気なインドリです♪
ここ数日間は特に何もありませんでした。普通に仕事をこなし、普通に学習して寝る。そんな感じの平和な日々です。
なので、私は幸せを噛みしめています♪
そういえば、散歩をして気づいたのですが、私の住む地域はここ最近徐々に暖かくなってきました。
私が子供の頃に比べると、全体的に冬が暖かくなってきたような気がします。これが温暖化ってやつかな？
暖かい日は気持ちがいいけども、でも冬を堪能したい気持ちも同時にあるので残念な気持ちです。
やはり日本は四季があるからこそ美しく楽しい。四季を感じることは幸せなのです。
春は暖かい、夏は暑い、秋はちょっと寒い、冬は寒い、とはっきりとしてほしいものです。
もし日本から四季が消えて、一年中似たような気候だったら面白くありませんよね。
では、そろそろ散歩に行って冬を探してきます♪では、また後であいましょう。

テーマ : 裏事情
ジャンル : 謎

前から気になっている本があるんだよね。それが・・・
Real World Haskell―実戦で学ぶ関数型言語プログラミング
ピヨ♪関数型言語のサンプル集って珍しいよね♪


【目次】

目次
まえがき
1章 始めましょう
2章 型と関数
3章 型を定義し、関数を単純化する
4章 関数プログラミング
5章 ライブラリを書く:JSONデータの操作
6章 型クラスを使う
7章 入出力
8章 効率的なファイル処理、正規表現、ファイル名マッチング
9章 入出力事例研究:ファイルシステム検索ライブラリ
10章 コード事例研究: バイナリデータフォーマットの構文解析
11章 テストと品質保証
12章 バーコード認識
13章 データ構造
14章 モナド
15章 モナドを使ったプログラミング
16章 Parsecを使う
17章 Cとのインタフェース: FFI
18章 モナド変換子
19章 エラー処理
20章 Haskellのシステムプログラミング
21章 データベースを使う
22章 規模の大きい例:ウェブクライアントプログラミング
23章 gtk2hsを使ったGUIプログラミング
24章 並行マルチコアプログラミング
25章 プロファイリングと最適化
26章 高度なライブラリの設計:ブルームフィルタ
27章 ソケットとsyslog
28章 ソフトウェア・トランザクショナル・メモリ
付録A GHCとHaskellライブラリをインストールする
付録B 文字、文字列、エスケープ規則
索引

みんな関数型言語に興味があるかな？ある人が結構いるとボクは思うピヨ♪だって、VS2010からはF#のサポートがUPされるし、大概の言語には関数型言語由来の機能が付加されている。そんな状況だから、意欲的な技術者にとって関数型言語にたいして自然と興味を持つと思う。だけど、最近までは関数型言語についてのサンプルがないものだから、ちょっと触れるようになってもどうやって生かしたらいいのかわからない状況だっとボク派思う。
そんな状況を救う救世主がこの本ピヨ♪本屋さんで見たんだけど、すっごくサンプルが多くて実践的にHaskellを学ぶのに絶対に必要な書籍だと感じたピヨ♪ボクが知る限り、関数型言語でこれほどのサンプル集は発売されていなかったピヨ。だから、純関数型言語であるHaskellを通じて関数型言語になじもう！。向上心がある全ての技術者にこの書籍をお勧めするピヨ♪


もっと本を知りたいという本好きは書籍レビュー目次と書籍レビューを見ると良いピヨ♪

テーマ : プログラミング
ジャンル : コンピュータ

こんばんは♪基礎訓練を行っているインドリです♪
ここ最近は、コンパイラの実装などをしたい欲求をぐっとこらえて、将来のために数学と英語を学習しておりました。
今まで私は、10年かけて情報処理技術全般を学習してきました。もうそろそろその知識をフル活用して、本格的なコンパイラの実装をしたいのですが、やはり数学と英語は必要です。
ですから、将来を見据えて基盤を整えているというわけです。
仕事でもいろいろやっているけど、コンパイラやOSを作る仕事もしくは、そのレベルの知識が必要とされる仕事はこないからストレス溜まるんですよね。
誰でもそうだと思いますが、作りたいものと仕事で要求されるものはやはりギャップがあります。
私の知識がフル活用できるプロジェクトないかな〜。
きっと無いからみんなオープンソースプロジェクトに参加したがるんだろうね。
私も脳を100％使えるプロジェクトを自分で作りたいと思います。
今のところ考えているのは、やはりネタ指向コンパイラ「カオス」（仮名）です。
そのためにも英語と数学が必須なんだけど、あ〜あ早くやりたいな〜♪
でも、必要な事はしないといけないから、欲求を抑えて半年間みっちり英語と数学をやります。
といっても何も考えていないわけではなく、ちびちび計画しております。
ひとまず、考え付く限りの全機能を実装して、仮想マシンでもネイティブでも動き、コンパイラとインタプリタの両方の方式がOKな言語にする事が決まっています。
そうするには、まずやるべきことは分析＆設計です。
趣味だから全力を出して（笑）オブジェクト指向でアジャイル開発します。
※おっと、アスペクト指向も必要ですね。
私が知っている限り、コンパイラをアジャイル開発する方法が載っている本が無いから非常に楽しみです♪
こういった未知の冒険こそ技術者魂を燃えさせます！
皆様も仕事でストレスが待っているときは、自分が好きなプロジェクトを立ち上げるといいと思います。

テーマ : 裏事情
ジャンル : 謎

前回に引き続き学習法を書きます。今回は具体的にどうするのかを書きます。
前回では学ぶための基本的姿勢を解説しました。この学習姿勢を保つと、変化に惑わされる事が無くなります。では、具体的にどの様に学習していくのかといいますと、先ずはアンテナを立てる事です。常にアンテナを立てておかないと、変化に対応できませんのでこれは重要です。それで、何を受信するのかといいますと、前回に書いているように、低レイヤの技術についての情報と、自分が必要としている高レイヤの技術についての情報です。
こうしてアンテナを常に立てておくと、自ずと自分が今学ぶべき事が分かってきます。学ぶべきことが分かったら、どうやってその情報を手に入れるのかを考えます。これには色々考えられますが、私のお勧めはネットで概要を知り複数の書籍で詳細な情報を得る方法です。学習するためには、対象にしっかり狙いを定める必要があります。そうしないと、役に立つ情報は入手できないか、出来ても役立てる事が出来ません。そこで私は、ネットで概要を知り、どういう書籍が売りだされているのかを把握してから購入します。購入する際には、目次・まえがき・書評が参考になります。それらの情報でその本が対象としている情報が分かりますので、目的としている情報が手に入るのかがこれで分かります。
本を購入したら、複数の本を平行して読みましょう。そうする事により、多角的にその対象を知る事が出来ます。平行に読むと言っても慣れないと難しいので方法が必要です。私の場合は、買った本の目次を把握する事から始めます。理由は全体像をつかむためです。全体像を積んでおかないと、本を読む順番と今読んでいる情報が何を意味するのかが把握し辛くなります。技術の書の場合、1冊700ページの分厚い本を3・4冊同人に読む事なんてざらにあります。その大量の情報を理解しつつ読み進めるには、今読んでいる情報が全体像のどこにあるのかを把握しておかないと、迷子になる可能性が十二分にあるのです。それを防ぐために、先ずは自分なりの読書マップを描くと言うわけです。
例えば、プログラミング言語の解説書・ネットワークプログラミングの解説書・データベースプログラミングの解説書の三冊を同時に読むとします。この場合、言語の解説書は言語の機能を全体に把握するのに向いていますが、個々のプログラミングテクニックの情報は少ないという弱点があります。そこで、言語解説書を読んで、データベースプログラミングの章になったら、データベースプログラミング専用の書を読めば、言語とプログラミングテクニックの情報が同時に手に入ります。
こんな具合に、各書籍がどの様な情報をどの粒度で書いているのかを把握すれば、効率的に情報が手に入るようになります。では何故それらの本を並行的にするのかと言いますと、関連付けを行った方が記憶しやすいからです。人間の脳は、バラバラに覚えるよりも物事を関連付けた方が記憶に残りやすいという性質を持っています。ですから並行的に書籍を読む事により、効率的に覚えられるのです。
並行的に読めば記憶力は高まりますが、これだけではまだ不十分です。脳をフル活用して五感と喜怒哀楽をその情報に結び付けて覚えましょう。ここが非常に大事です。人間の脳は五感を刺激するほど忘れにくい性質を持っております。ですから、ただ無味乾燥に本を読むのではなく、感情豊かに面白おかしく本の内容を脳内でイメージしつつ覚えましょう。誰しも面白みのない事を永遠と暗記するのは嫌気がさし長続きしませんし、嫌々勉強しても記憶に残りません。ですから、映画が小説を読んでいるように専門書を読めばいいのです。そうすれば、記憶しやすくなります。
ここまでの話しはインプットの方法です。でも人間は使わない事は忘れてしまいます。インプットしたらアウトプットしなくてはなりません。アウトプットする方法は情報処理技術に於いて一つしかありません。それは実装する事です。実装すればそれ以上の情報が得られますので非常に効率が良い学習法となります。
私はこの学習法を思考錯誤しつつ10年間続けました。その結果、何処に何が書いてあるのか分かりますし、幅広く使える知識が増えました。こうなると仕事上においても非常に便利です。お客様と会話するのと同時にシステムの設計と実装ができ、運営する姿も思い浮かびます。さらに、そのシステムを実現するためにどの書籍の何処の部分が必要なのかも正確にわかります。また、情報が足りない場合も、足りない情報が明確に分かります。
この体験を通じて私が思うに、学習とは自分と言うハードウェアを操作するメタプログラミングに他ならないのです。どれだけ速く・正確に自分の脳に役に立つ情報を保存できるのか、どうやって脳から情報を素早く取り出すのかをプログラミングしているわけです。私は勉強は大嫌いなのですが、プログラミングは好きです。それで、自分と言うハードウェアを如何にして効率よく使うのかを夢中でプログラミングしているのです。自分をメタプログラミングするのは非常に刺激的で止められません。
このブログを読む人達はきっとプログラミングが好きな人だと思います。ですから、自分と言うハードウェアを効率よく使うためのプログラミングをする事をお勧めします。ここで紹介した学習法はあくまでも私に最適化したものです。これを参考に自分ならではの学習法をプログラミングして欲しいと私は思います。

テーマ : プログラミング
ジャンル : コンピュータ

今回は学習方法についてのネタです。皆様は如何にして学習しているのでしょうか？真面目な技術者は、皆それぞれに自分流の学習法を確立していると思います。そういった学習法を互いに教え合うのがよい結果を生むと思いますので、私流の学習法を書きます。
情報処理技術は生まれて日が浅い分野ですが、進化が早く既に広大な範囲になっております。昨今はその変化も早く、新しい技術が日進月歩どころか時進日歩と呼びたくなるほどのスピードで生まれています。こうした変化に対応し、技術者と呼ばれるのに相応しい技術力を維持するにはどうしたらよいのでしょうか？
この疑問は情報処理技術者に共通したものでしょう。変化のスピードが速すぎて眩暈を起こす人、迷子になる人、諦めてしまう人、何から学習したらいいのか分からない新人達・・・などが沢山いるかと思います。かくいう私も模索中です。だからと言って何もしないわけにはいきません。暗中模索しつつ、学習方法を作り上げ変化に対応する術を身につけるしかないのです。私はその答えを新人時代から追い求め、サンドウィッチ的学習法が良いと考えるに至りました。これからその学習法を説明します。
先ず考えなくてはならないのは、プロとして必要な知識は何かという事です。趣味で情報処理技術を楽しむのであれば、自分が好きな技術を学習すれば十分です。しかしながら、プロになるにはそれでは駄目なのです。その理由は、サービスを提供する相手が居ないと職業として成立しないからです。
従って、一番最初に学習するべき技術は今必要とされているものです。例えば、VBがメインの会社で、VBが嫌いだからと言ってC#を学習してはなりません。ひとまずVBを学習しておかないとクビになるでしょう。しかしだからと言って、自分が属する組織に要求される技術だけを学習していればいいのかと言いますと、それは否で、それ程世間は甘くありません。その会社が倒産したり、リストラされたらこの変化が激しいIT業界に於いて、その範囲が限定された技術力では転職するのは難しいでしょう。その先の学習が必要です。
次の段階として、なるべく低レイヤな本質的技術を学習します。ここが変化に対応するためのポイントです。情報処理技術は変化が激しいと感じる人が多いでしょうが、実のところ低レイヤになるにつれて変化が緩くなっていきます。例えば、OSやコンパイラなどと言った技術は、それ程変化が激しくなく、何十年前に考えだされた考え方が未だに通用します。こういった基礎技術は中々変化しないものなのです。実際私は十年ほどこの業界にいますが、OSやコンパイラといった低レイヤの知識は殆ど変化しておらず、この知識を用いる事により、変化もある程度予測できるようになりました。少なくとも私はこの十年間予想外の技術が登場してあわてた事はありません。これでもまだ不十分なので次の段階へ進みます。
これまでの段階を経て、高レイヤの知識と低レイヤの知識を身につけたとします。しかしそれだけではまだ足りません。足りない知識はメタ知識です。前の2つの段階を経ると技術に精通しても仕事が出来なければプロと呼べません。プロと呼ばれる為には、優れた人の開発思想といったメタな知識が必要となってきます。ソフトウェア工学を学習し、達人プログラマー―システム開発の職人から名匠への道 ・ビューティフルコード ・ビューティフルアーキテクチャの様な開発思想が書かれた名著を読む事により、メタな知識を身につけましょう。後はどんどん上下から攻めていくだけです。中身はいずれパクッと食べるようになるでしょう。
これが私の基本的な学習法です。誰かのお役に立てれば幸いです。

テーマ : プログラミング
ジャンル : コンピュータ