書籍をつつく135-オブジェクト指向入門 第2版 原則・コンセプト。オブジェクト指向の深遠への案内書。

今日は日記を書いていたらこの名著を紹介するのを忘れていた事に気付いたピヨ♪
オブジェクト指向入門 第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つ目の利点なんだ。 オブジェクト指向のメリットは再利用だとよく言われてるけど、実際に再利用しようと思ったら汎用的なオブジェクトでなければならない。特殊な環境や問題に特化したオブジェクトは再利用しようがないからね。その点、メイヤー氏のオブジェクト指向方法論は、個々にオブジェクト（クラス）に注目し、処理順序に依存することを極力避けるので再利用しやすいオブジェクトが出来上がるピヨ♪
ここまで一生懸命説明したけど、普通はよくわからないよね？その答えは・・・この本を読もう！この本を読んだらオブジェクト指向とは一体何なのかという一つの答えが得られると思う。オブジェクト指向を真面目に学習したい人は絶対に読もう！


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

中の人の徒然草314

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



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

中の人の徒然草313

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

書籍をつつく134－Real World Haskell。関数型言語では珍しいサンプル集。

前から気になっている本があるんだよね。それが・・・
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を通じて関数型言語になじもう！。向上心がある全ての技術者にこの書籍をお勧めするピヨ♪


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

中の人の徒然草312

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

ネタつつき78－インドリ流サンドウィッチ学習法1

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

ネタつつき77－今時の学習法。インドリ流サンドウィッチ学習法♪

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

中の人の徒然草311

毎度どうも♪並列的学習法をしているインドリです♪
最近並列処理について学習していると、並列処理関連の書籍にJavaを使った良書のお蔭でJavaが偉大に見えてきました。JavaのAPIがそこまで考えて作られているとは思わなかったです。
.NET Frameworkにも並列関連があり、.NET4.0でさらに増えるので非常に楽しみです♪
.NETにもAPIの設計思想を書いた本があったらいいのにな・・・
インサイド.NET Frameworkー並列処理編とか出版されたら即買います！
そういえば、意外と設計思想本が少ないですよね。やはり企業秘密なのでしょうか？
特にAPIの思想本が少ないです。設計思想を知らないと真に使いこなせないのでそこは是非とも書いてほしい。 一番理想的なのはMSDNなどのマニュアルに直接書く事ですが、書籍でも一向にかまいません。

それはさておき、身の回り物の設計思想って結構おざなりになっていますよね。
もし、自分が買った髭剃り機に設計思想が書いてあったら私ならばその品に愛着を持ちます。 そうすれば面白い事になると思います。こんな感じで・・・

A「俺が使っているX社のジェットストリームシェーバーEXは剛毛のトーマスが50年も研究して作った一品だぜ！どんな剛毛でもそれるすぐれものだ。こいつに勝てる奴はいねぇ。」
B「いやそれならば、私の使っている男気剃刀三郎をお勧めするよ。これは、鎌倉時代から伝わる秘伝の製法を使った日本の伝統工芸が生み出した至高の品だ。元々名匠と呼ばれた刀職人三郎が作ったものなんだけど、人を殺す道具を作るのに疑問を感じた三郎が悩んだ末、肌は切れないが体毛ならば切れる不殺の刀を目指して作った究極の剃刀なんだ。」

物を大切にする心が失われている昨今に於いて、これはいいと思います。

書籍をつつく133－継続的インテグレーション入門。継続的にバグをなくそう♪

今日は開発プロセス系の良書を紹介するピヨ♪
継続的インテグレーション入門 開発プロセスを自動化する47の作法
この書籍はいいよ♪先ずは目次を見てみよう。


【目次】

まえがき マーチン・ファウラー
まえがき ポール・ジュリアス

第１部 CIの背景─原則とプラクティス
第１章 始めよう 
変更を起点としてビルドを実行する
CIの機能 

第２章 継続的インテグレーションの紹介
CIのある１日 
CIの価値とは?
CI導入を妨げるものは何か?
「継続的」なインテグレーションに必要なものは?
CI導入の時期と方法は? 
CIと他の開発プラクティスの関係は?
CI環境のセットアップにどれぐらい時間がかかるのか?
頻繁にコードをコミットする
ビルドが失敗したコードをコミットしない
失敗したビルドをすみやかに修復する
開発者テストを自動化する
すべてのテストとインスペクションを合格させる
プライベートビルドを実行する
ビルドが失敗したコードを取得しない

第３章 CI によるリスクの軽減 
リスク:デプロイできないソフトウエア
リスク:欠陥検出の遅れ
リスク:プロジェクトの「見える化」不足
リスク:低品質なソフトウエア

第４章 変更を起点としたビルドの実行
ビルドを自動化する
コマンド１つでビルドを実行する
ビルドスクリプトをIDEから分離する
ソフトウエア資産を集中化する
一貫したディレクトリ構造を作る 
失敗しやすいビルドプロセスから始める
複数環境へのデプロイに対応する
ビルドの種類とその起動方法
インテグレーションビルドマシンを使用する
CIサーバーを使う
手動インテグレーションビルドを実行する

第２部 CIシステムの構築
第５章 継続的データベースインテグレーション
データベースインテグレーションを自動化する
ローカル環境でデータベースサンドボックスを使う
バージョン管理リポジトリを使ってデータベース資産を共有する
開発者にデータベースを変更する権限を与える
失敗したビルドをチームで修復する

第６章 継続的テスト
単体テストを自動化する
結合テストを自動化する
システムテストを自動化する
機能テストを自動化する
開発者テストを分類する
実行時間が短いテストを先に実行する
不具合に対してテストを書く 
結合テストを再実行可能にする
1テストケースに1つのアサーション

第７章 継続的インスペクション
テストとインスペクションの違い
インスペクションツール実行の頻度
コードの複雑度を下げる
継続的なデザインレビューの実施
コードの複製を減らす 
コード網羅率を評価する
継続的にコード品質を評価する

第８章 継続的デプロイ
動作するソフトウエアを常にリリースできるようにする
ビルドフィードバックレポートを作成する
リリースのロールバックを可能にする

第９章 継続的フィードバック
適切なフィードバックとは何か
継続的フィードバック手段を利用する

付録A CIリソース
付録B CIツールの評価

どう？面白そうだよね♪この本はアジャイル開発における継続的インテグレーションについて書いてある本ピヨ♪みんな、継続的インテグレーションを知っているかな？継続的インテグレーションとは、簡単に言うとチーム開発における、コードのチェックアウト、ビルド、テストなどの一連の作業を継続的に行う事なんだ。
これを読んだ人の中には、そんなの当たり前じゃんって思う人が居ると思う。でも実際の開発現場では違うんだ。というのも開発チームで作業するとインテグレーションが意外と難しいからなんだ。ある程度以上の規模のシステムを開発する時には、複数の人がそれぞれの部分を担当して開発を進めている。その時、全てのコードをコンパイルしてテストを実行するのは意外と難しいピヨぉ。何故ならば、全員が正しいコードをコンパイルして、それを同時に統合するのが難しいからなんだ。複数の人が作業していると、例えば「ちょっと待って。今メソッドAが実装しきれていないの。」だとか「今バグ退治している最中だからコンパイルできないぜ」なんて事が起こる。それでもインテグレーションするには、全員の予定を聞いて、作業を常に同期しなくてはならない。これは疲れるし、生産効率が落ちるピヨぉ。
だけど、アジャイル開発では継続的にインテグレーションする事を推奨しているピヨ。その理由は、システムの不都合を早期に発見してバグが無いシステムを素早く作るためなんだ。でも、先ほど言った様に集団で作業するとインテグレーションは難しい。それをどうやって実現するのかと言う事と、継続的インテグレーションの考え方がこの本に書かれているんだ。
だけど注意しておくべき事が一つあるピヨ。それは、この本にはインテグレーションツールについての詳細な情報は書いていないピヨ。残念だけどインテグレーションツールそのものについては他書を当たる必要があるピヨ。でもツールの使い方だけでは使いこなせないと思うから、この本をお勧めするピヨ♪
昨今、素早くバグが無いシステムを作る事が求められているから開発チーム必携の本だとボクは思う。アジャイル開発を実践している人、いまいちアジャイル開発の効果が実感できない人、アジャイル開発に興味がある人、バグが無いシステムを作りたい人・・・などはこの本を読もう♪得るものは大きいと思う。


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

中の人の徒然草310

こんにちは。ちょっと疲れているインドリです。
並列処理を調べるのは楽しいのですが、同時に遊び疲れるんですよね。
並列処理をちゃんと理解するためには、ハードウェアの事も調べなくてはならないし、プログラミング言語をまたがって調べなくちゃならない。複数の言語を学習しておいてよかったなと改めて思いました。
複数のプログラミング言語を学習しておくと、資料が分散している状況で便利ですよね♪
C／C++言語の資料が無ければJava,それも無ければ関数型言語・・・っていう風に、無差別に資料を読み漁っています。
あと英語が出来れば理想的なんだけどなぁ・・・只今修行中で単語を覚える日々を送っていますorz
疲れている理由の半分以上は英語の学習が原因な気がする（笑）
なにはともあれ、複数のプログラミング言語を学習しておくと便利ですよ。
それから話しは変わりますが、最近気になっている本があります。



た、高い！！！凄く魅力的なのですが、とにかく高い！直ぐには手が出せませんね・・・
アルゴリズムは奥が深いですよね。私もある程度は学習したのですが、まだThe Art of Computer Programmingには手を出せない状態です（積読中）この本は、高校数学以上の知識が前提とされており、一部離散数学の知識も必要とされるようです。うむぅ・・・
そういった事もあって数学をちびちび学習しているのですが何時になる事やら。
まぁ、地道に楽修していきます。学問に王道はありませんからね♪
と言う事で、数学と情報処理技術を結びつけながら学習しています。その際に数学系アルゴリズムを思い出し、アルゴリズムデザインが欲しくなったと言う訳です。昔アルゴリズムの学習をした時に数学系は飛ばしたのですが、今はその部分に強く惹きつけられています。人生とは不思議なものです。